OpenTelemetry integration
OpenTelemetry can provide standardized telemetry and trace context. DRC uses execution-oriented capture, replay, comparison, provenance, and review workflows around the data supplied by an adapter.
Current integration boundary
The Rust ingestion workspace defines normalized source metadata and an optional OTel connector boundary. The connector is feature-gated; verify the selected build and deployment before using it. An OTel span by itself is not necessarily a complete replay artifact.
A replayable execution may also need dependency responses, state writes, timing/order, source metadata, redaction policy, and completeness information that a trace span does not contain.
Correlation fields
When supplied by an API or adapter, DRC preserves:
- resource/service identity;
- trace ID;
- span ID and parent span ID;
- span attributes subject to validation and redaction;
- status and error information as analysis input.
Correlation supports analysis but does not turn incomplete telemetry into complete execution evidence.
Optional build feature
cargo build --manifest-path drc-rust/Cargo.toml \
--features connector-otel -p drc-ingestion
The default workspace build does not enable every optional connector.
Data minimization
Before sending telemetry to DRC:
- remove authorization and credential attributes;
- bound attribute sizes and event counts;
- avoid raw bodies unless required;
- define tenant and retention policy;
- preserve source and schema metadata;
- record whether the incoming data is complete enough for the requested analysis.## Using the adapter safely
OpenTelemetry supplies telemetry and correlation context; the DRC integration is responsible for storage, replay inputs, authorization, evidence access, and result interpretation. Configure those concerns separately and preserve the source and completeness metadata supplied with the incoming data.