Reference semantic conventions for SDK self-observability metrics - #5087
Conversation
52ce704 to
1221b00
Compare
|
Thanks for discussing this in SIG Call. @tigrannajaryan The PR desc has a "note for reviewers" - Let me know if that address your concern about spec trying to list what sem-conv should be covering. |
lmolkova
left a comment
There was a problem hiding this comment.
LGTM directionally with a small caveat on moving / linking it from current self-diagnostics section
dashpole
left a comment
There was a problem hiding this comment.
Do you want to cover the other SDK components (e.g. simple {signal} processors, or the trace SDK (spans started/live), or log sdk (logs created).
There are also the span/log/metric exporter metrics, which it wold be nice to have on the corresponding OTLP exporters.
Great points — fully agree these all deserve coverage. I'd like to keep this PR scoped as a first step to lock in directional acceptance: spec treats self-observability as a first-class concern and points to semantic conventions as the source of truth for metric names, attributes, and values. Once this PR is merged, I can follow up with rest of the metrics. |
…in CHANGELOG entries
|
@dashpole Given I have refactored significantly after your approval, could you re-review please? |
pellared
left a comment
There was a problem hiding this comment.
How about also adding The Metrics SDK SHOULD support [SDK self-observability](../self-observability.md). for completeness?
Adds a new specification/self-observability.md document defining SDK self-observability at the spec level, and adds a one-line Self-observability section to the Tracing, Metrics, and Logs SDK specs pointing to it. Also references it from error-handling.md and the top-level README.
14fd15e to
146fa38
Compare
Co-authored-by: David Ashpole <dashpole@google.com>
…en-telemetry#5087) Adds an in-development Self-Observability.md document and SDK-level Self-observability sections in the Tracing and Logs SDK specs that point to it. The Self-Observability document defers to the OpenTelemetry semantic conventions for SDK self-observability metric names, attributes, and values. This is step 1 of defining self-observability as part of the spec itself; follow-ups can extend it (e.g., exporter metrics, reader metrics, self-logs, self-events) under the same umbrella. Companion PR in semantic-conventions reserving the `error.type` values (`queue_full`, `already_shutdown`): open-telemetry/semantic-conventions#3710. Resolves open-telemetry#5086. --------- Co-authored-by: David Ashpole <dashpole@google.com>
### Context - Clarify that environment variable propagation carriers normalize requested keys, carrier keys, and returned keys. ([open-telemetry#5102](open-telemetry#5102)) - Specify that environment variable propagation carriers only read and return normalized environment variable names. ([open-telemetry#5144](open-telemetry#5144)) - Specify that an empty environment variable propagation name is non-normalized and normalizes to `_`. ([open-telemetry#5163](open-telemetry#5163)) ### Profiles - Remove duplicate information from and extend Profiles documentation (README.md, pprof.md). ([open-telemetry#4932](open-telemetry#4932)) ### Entities - Add specification for communicating entity information as structured log events. ([open-telemetry#4836](open-telemetry#4836)) ### Common - Add an in-development [SDK self-observability](specification/self-observability.md) section, referenced from the Tracing, Metrics, and Logs SDK specs. ([open-telemetry#5087](open-telemetry#5087)) - Clarify non-OTLP representation guidance for nested `AnyValue` values in arrays and maps. ([open-telemetry#5053](open-telemetry#5053)) - Add in-development guidance recommending a JSON object as the string representation for an attribute in non-OTLP protocols. ([open-telemetry#5028](open-telemetry#5028)) - Add in-development guidance recommending a JSON object as the string representation for an attribute collection in non-OTLP protocols. ([open-telemetry#5110](open-telemetry#5110)) ### Compatibility - Deprecate OpenCensus compatibility requirements in the specification. ([open-telemetry#5138](open-telemetry#5138)) - Stabilize sections of Prometheus Metrics Exporter. - Clarify resource attributes configuration. ([open-telemetry#5084](open-telemetry#5084)) - Stabilize the conversion of OTLP Summaries into Prometheus Summaries. ([open-telemetry#5107](open-telemetry#5107)) - Stabilize client libs section. ([open-telemetry#5106](open-telemetry#5106)) - Stabilize Prometheus Metrics Exporter default aggregation configuration. ([open-telemetry#5113](open-telemetry#5113)) - Stabilize sections of Prometheus and OpenMetrics Compatibility. - Stabilize OpenTelemetry Histogram to Prometheus Histogram transformation. ([open-telemetry#5091](open-telemetry#5091)) - Add optional OpenTelemetry Histogram to Prometheus Native Histogram with Custom Buckets transformation. ([open-telemetry#5091](open-telemetry#5091)) ### SDK Configuration - Add link to declarative config IdGenerator type ([open-telemetry#5133](open-telemetry#5133)) ### OTEPs - Context-scoped Attributes. ([open-telemetry#4931](open-telemetry#4931)) --------- Co-authored-by: Reiley Yang <reyang@microsoft.com>
…ry#5135) Adds non-normative supplementary guidelines covering lifecycle ordering, avoiding telemetry-induced-telemetry loops, and stability handling for SDK self-observability. Towards open-telemetry#5128. Follow-up to open-telemetry#5087. --------- Co-authored-by: Robert Pająk <pellared@hotmail.com> Co-authored-by: Jack Berg <34418638+jack-berg@users.noreply.github.com>
…telemetry#5237) This adds a new `SDK Self-Observability` section to the spec compliance matrix, tracking implementation status of the SDK self-observability metrics across languages. Motivation: self-observability was recently recognized in the spec (open-telemetry#5135 supplementary guidelines, open-telemetry#5087 semconv reference), and the guidelines state self-observability should be treated "like any other SDK feature for stability." The compliance matrix is where per-language SDK feature status already lives, so it's the natural home for tracking this too. The section lists all 17 metrics defined in the [semantic conventions for SDK metrics](https://opentelemetry.io/docs/specs/semconv/otel/sdk-metrics/), one row per metric, grouped by signal (span / log / metric / shared). Per-metric granularity keeps the `+`/`-` values honest, since a language can implement a group only partially and each metric stabilizes independently. As the semantic conventions add more SDK self-observability metrics over time, this section is expected to grow with them. If it eventually becomes too large to sit comfortably inside the main compliance matrix, we can move it into a dedicated document and link to it from here. All cells start as `-`. Filling in actual per-language status is intentionally left to follow-up PRs so each SIG can update its own column. Generated with `make compliance-matrix` from the per-language YAML files.
Adds an in-development Self-Observability.md document and SDK-level Self-observability sections in the Tracing and Logs and Metrics SDK specs that point to it. The Self-Observability document defers to the OpenTelemetry semantic conventions for SDK self-observability metric names, attributes, and values.
This is step 1 of defining self-observability as part of the spec itself; follow-ups can extend it (e.g., exporter metrics, reader metrics, self-logs, self-events) under the same umbrella.
Companion PR in semantic-conventions reserving the
error.typevalues (queue_full,already_shutdown): open-telemetry/semantic-conventions#3710.Resolves #5086.