feat: route normalized OTLP signals to project destinations - #5939
Conversation
|
|
Running ultrareview automatically — This large change introduces project-scoped OpenTelemetry exports with new authorization, write-only header secret handling, and a sensitive-data telemetry relay—security and data-integrity bugs here would have broad blast radius.. I'll post findings when complete. |
There was a problem hiding this comment.
Ultrareview completed in 14m 45s
All reported issues were addressed across 119 files
Tip: instead of fixing issues one by one fix them all with cubic
Re-trigger cubic
64b1f9d to
fbfc623
Compare
There was a problem hiding this comment.
All reported issues were addressed across 21 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
e4d954c to
5d60dfd
Compare
3c32c05 to
1769516
Compare
Builds on the data-export management API merged in #5792.
Summary
dataexportsrepository and reuse its project-scoped destination model.invalidand drop them before route lookup or export.Sensitive data policy
This is, for now, a somewhat naive policy, but I think will suffice. Over time we might need to revisit how we do proper redaction.
includepreserves the normalized OTLP payload.excludereplaces classified content and identity values with[REDACTED]across log, metric, and trace containers while preserving attribute keys.Motivation
Normalized telemetry must follow the project-scoped routes managed by the data export API. Resolving destinations at the normalized signal boundary keeps logs, metrics, and traces consistent while preserving project isolation and destination-specific disclosure policy.
NOTE
Once this is merged the old configs will stop working: this is ok. Only one customer has it configured other than us, and it's not working (all datadog logs are showing 403 failures). I have shared this with them so they are aware.