open-telemetry/semantic-conventions

The spec currently says: "Events SHOULD NOT use body except to represent a string display message of the event." I think there should be more guidance for instrumentations - should it be optional, recommended, or required? Should the description be defined as part of every event's sem conventions, similar to span names? Related issues: #3343 open-telemetry/opentelemetry-browser#282

Forked from #3627 (comment) In #3627, I want users to be able to opt-in to more detailed label values. This primarily because the "detailed" values are not a stable API provided by the Go runtime, and I would like to avoid exposing the detailed values to users by default. The solution i've come up with is to have two labels: go.memory.type, and go.memory.detailed_type, where the detailed_type label is opt-in. Questions: Is this an acceptable pattern to use? Is there an alternative I should consider instead? Is this something we should codify in the semantic conventions guidelines? cc @kamphaus

Problem There are two related problems that stem from the same root cause: the aggregation interval is not part of the metric's schema. Metric name proliferation Some metrics are already aggregated at the source over a fixed time window. Without a dedicated field for the interval, the current option is to encode it in the metric name. For example, the hostmetrics CPU load average is reported as three separate metrics: system.cpu.load_average.1m system.cpu.load_average.5m system.cpu.load_average.15m The same pattern appears in the JVM conventions with jvm.system.cpu.load_1m. For load averages this is manageable since the OS only provides three fixed windows (1, 5, and 15 minutes). But for other sources like Linux PSI metrics, which have pressure values at 10s, 1m, and 5m windows across four resource types (CPU, memory, IO, IRQ) and two stall types (some, full), this pattern produces 24 nearly identical metrics differentiated only by a name suffix: system.cpu.linux.pressure.10s syst