Beyond Collection: Rethinking OTEL Normalization as a Community Standard
summary
OpenTelemetry fixes collection but not meaning: 12 teams across Java Go and Python turn ~40 semantic concepts into >200 attribute keys (5x bloat), so five services store the same user ID under five different fields. Proposal is a normalization layer as an OpenTelemetry collector processor that applies declarative YAML rule packs from a shared registry (like npm), runs conformance tests, and emits canonical fields so OpenSearch gets stable index mappings. AI assists mapping for ambiguous names but deterministic rules and human review ship final mappings.
AI-written summary · about
chapters (11)
- 0:00Telemetry normalization challenge
- 1:04OTEL collection vs meaning gap
- 3:17Inconsistent telemetry naming example
- 5:05Normalization for AI observability
- 6:53Limitations of current approaches
- 8:18Normalization layer workflow
- 10:11AI mapping and human review
- 11:59Benefits for OpenSearch and AI data
- 12:43Shared rule registry spec
- 13:51Call to action and collaboration
- 15:02Q&A on query normalization
related talks
34mKubernetes Observability with OpenTelemetry
07mSponsored Keynote: Why Semantic Conventions are OpenTelemetry’s Most Important Con...
09mOpenTelemetry or OpenTeleMessy?
32mOpenTelemetry Semantic Conventions and How to Avoid Broken Observability
47mWhat Is This OpenTelemetry Thing?
43mWhat is this OpenTelemetry thing?
38mThe Hater's Guide To OpenTelemetry
19mOpenTelemetry's Path to Observability's Future