Add OTLP logs signal to the Rust observability SDK

[brentrager]

Problem

The SmooAI observability SDK emits traces + metrics into the product's OTLP endpoints, but not logs — so we can't join a service's log lines to the traces they belong to. This is the Rust/flagship dogfood reference for the SDK logs signal (pearls th-5dca7d / th-de3805, ADR-100); the other four languages follow this pattern.

Solution

Add the LOGS signal, sending into /v1/logs correlated to traces, reusing the existing traces/metrics OTLP setup as the template:

• Same wiring, no new config keys — same endpoint (SMOOAI_OBSERVABILITY_ENDPOINT → /v1/logs), same auth (static _TOKEN or M2M _AUTH_URL/_CLIENT_ID/_CLIENT_SECRET via the per-request AuthInjectingHttpClient), same enable/init path. Per-signal override honored via OTEL_EXPORTER_OTLP_LOGS_ENDPOINT.
• Standard OTel appender — opentelemetry-appender-tracing (tracing→OTel log bridge) + opentelemetry-otlp LogExporter (HTTP/JSON, matching the traces exporter's transport) + opentelemetry_sdk SdkLoggerProvider. Matched the exact 0.32 versions already pinned; the only new crate is opentelemetry-appender-tracing 0.32.
• Async-runtime BatchLogProcessor — same reactor-panic rationale as traces/metrics (SMOODEV-2045): the default thread-based processor block_ons on a bare OS thread where our reqwest-backed exporter has no Tokio reactor and aborts under panic = "abort".
• Graceful no-op when disabled — no logs endpoint → no logger provider → tracing_appender_layer() returns None; traces/metrics behavior unchanged.

Trace/span correlation (the whole point)

severity←tracing level, body←message, resource service.name→service_name, event fields→attributes. For trace_id/span_id: the SDK logger enriches each record from the active opentelemetry::Context at emit time — which is the OTel-native context this crate's tower/gen_ai/reqwest spans already make current. So a log fired inside one of those spans carries its real W3C ids, automatically. Hosts install the bridge via the new OtelSdkHandle::tracing_appender_layer().

Verification

cargo build, cargo clippy --all-targets (clean), cargo fmt --check (clean), cargo test — 60 passed. New tests/logs_signal.rs:

• log_within_active_span_carries_trace_and_span_id — asserts the emitted record's trace_id/span_id equal the active span's real ids. Correlation was actually verified, not just compiled: mutating the expected trace_id fails the test (real captured id 1732c136… vs the injected wrong value), confirming the assertion bites.
• log_without_active_span_has_no_trace_context — no active span → no fabricated trace context.
• Disabled-pipeline no-op covered by otel.rs unit tests (build_log_exporter is None; a fully-disabled handle yields no appender layer).

Wire format is OTLP/HTTP/JSON, matching the traces/metrics bytes the product already ingests, but the end-to-end product ingest was not exercised here (offline). No deploy.

Follow-up (now unblocked)

Dogfood wiring — api-prime / workers installing the appender layer and emitting logs through this pipeline.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: dd72e7a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR