What

Opt-in OpenTelemetry logs export for the sensing server, with a curated set of sensing events under a ruview.* namespace whose names and attribute keys are defined in a semantic-conventions registry and enforced in CI:

• semconv/registry/ — a weaver-validated (0.23, registry check --future) OTel semantic-conventions registry: 13 attributes and 8 log event names, all stability: development, with requirement levels on the event attribute refs and enums mirroring the code's actual value sets (the adaptive classifier's class list, the sensing source labels).

• src/semconv.rs — Rust constants generated from the registry (weaver registry generate, template under templates/registry/rust/). The new semconv workflow pins weaver v0.23.0 by sha256, validates the registry, regenerates the module, and fails on drift (codegen no-diff).

• src/telemetry.rs — tracing bootstrap with optional OTLP export, doubly gated:

  1. build: a new otel cargo feature (same gating principle as mqtt) keeps the opentelemetry 0.32 stack out of the default binary;
  2. runtime: even with the feature, export only activates when OTEL_EXPORTER_OTLP_ENDPOINT is set.

  Unset ⇒ the OTLP pipeline is never constructed and behavior is byte-identical to today's stderr fmt subscriber. When enabled, every tracing event exports as an OTel log record (service.name = "ruview") with a telemetry-induced-telemetry loop guard muting the exporter's own crates.

• docker/otel-compose.yml + docs/observability.md — a one-command demo pipeline (sensing server on synthetic CSI → OTel Collector → an OTLP log backend) and the guide.

Why

The sensing server already narrates the interesting moments (presence flips, vitals, node churn, falls, MQTT failures) as free-text log lines. Giving the highest-value ones stable, registry-backed event names and attributes makes them consumable by any OTLP collector/backend — dashboards, alerting on ruview.fall.detected, per-node filtering — without scraping stderr, and the weaver CI gate keeps the schema from drifting silently.

The events

Rate discipline: nothing new logs at frame rate — transitions and the 100-tick cadence only.

Deliberate omissions: ruview.room and ruview.mesh.channel were considered but not added — the registry only defines attributes for data this crate actually has (rooms live in the calibration crate; channel isn't in the frame structs).

Verification

• cargo check -p wifi-densepose-sensing-server — default features, --features otel,mqtt, and --all-targets: clean (only pre-existing warnings, verified against the base commit). Each commit in this PR builds independently (default features checked at every commit boundary).
• weaver registry check --future: pass; the generate + rustfmt cycle is hash-stable, so the CI no-diff gate is sound.
• Runtime smoke: with the endpoint unset the binary behaves identically; with the endpoint set and no backend listening it runs without panic (export retries in the background).
• End-to-end: ran the instrumented server (--source simulated) against a real OTLP logs backend — we dogfood with Ourios, but the export is backend-neutral and works with any OTLP collector/backend. Logs arrived under service.name = ruview, the curated events came through with their registry names/attributes, and template-level queries (event frequency by mined log template, severity >= warn filtering, log-template drift between time windows) answered correctly.

Caveats (honest limits)

• The sensing server has no graceful-shutdown path, so the final OTLP batch flush on kill is best-effort (the guard's Drop never runs on SIGKILL/SIGTERM); the periodic batch export bounds the loss to the last export interval.
• docker/otel-compose.yml and docker/otel-collector.yaml are parser-validated only (no docker CLI on the dev machine); the same env/feature path was verified end-to-end outside compose as described above.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WQY9wfrfRggqSpMLH8Xj3Y