ci: add weaver live-check workflow for SDK self-observability metrics

[cijothomas]

Towards #3553.

Adds a weaver registry live-check CI workflow that validates SDK self-observability metrics (otel.sdk.log.created, otel.sdk.processor.log.processed, exporter metrics, etc.) against the upstream semantic conventions registry on every PR that touches the SDK or OTLP exporter.

Changes

• New workflow .github/workflows/sdk-self-observability.yml using the upstream weaver-live-check-{start,stop} composite actions (v0.24.0). Validates against semconv v1.42.0. fail-on: violation.
• New examples/self-obs-live-check/ — purpose-built binary that creates a LoggerProvider with BatchLogProcessor + OTLP gRPC exporter, emits log records, waits for the periodic metric export, and shuts down cleanly. This exercises the SDK's self-obs metrics end-to-end.

Pattern

Follows the same approach as opentelemetry-rust-contrib#613 (tower instrumentation live-check): no in-tree registry, validates directly against the published upstream semconv, uses a dedicated app as the telemetry source.

Not yet a required status check

The workflow runs on PR/push/merge_group but is not in the required checks list. Promote once the gate is proven stable, consistent with the staged rollout used in otel-arrow.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.2%. Comparing base (1b3846c) to head (0c14d96).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3565     +/-   ##
=======================================
+ Coverage   82.9%   83.2%   +0.2%     
=======================================
  Files        130     130             
  Lines      27768   28232    +464     
=======================================
+ Hits       23040   23490    +450     
- Misses      4728    4742     +14     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Thank you for your contribution! This PR has been automatically marked as stale because it has not had activity in the last 14 days. This may be due to a delay in review on our side or awaiting a response from you; either is fine, and we appreciate your patience.

It will be closed in 14 days if no further activity occurs. Pushing a new commit or leaving a comment will remove the stale label and keep the PR open.

[jensholdgaard]

As a downstream data point in favour of this: we run essentially this exact pattern in Ourios (a Parquet + DataFusion log-storage backend built on the OTel stack), and it's been solid enough that we promoted it to a required CI gate.

Our live-check (weaver) job boots the real ourios-server, drives a little traffic, and runs weaver registry live-check --future over the emitted self-observability metrics — the same shape as this PR (dedicated telemetry source → live-check against the registry, no separate assertion harness). Two differences from your setup, neither material to the approach:

• We validate against our own semconv/registry/ (which extends the upstream registry with ourios.* metrics) rather than upstream directly — but it's the same weaver registry live-check mechanism on the same semconv v1.42.0 baseline.
• We emit from the production server binary + real traffic rather than a purpose-built example. Both work fine.

On the "not yet a required check / promote once proven stable" note — it graduates cleanly. It's in our ci-success required set and has been stable (no flakiness). The pairing that's worked well for us is the static weaver registry check (a no-diff gate on the generated constants) plus this runtime live-check — together they keep the declared registry and the actually-emitted telemetry honest with each other, which neither catches alone.

So the staged-rollout endpoint you're describing is reachable in practice. +1 to landing this — self-obs metrics silently drifting from semconv is exactly the failure it prevents, and it's nicer to catch in CI than in a consumer's dashboard. Happy to share our workflow as a reference if useful.