OTTL: Fixing Telemetry Before It Leaves Your Cluster

Every team running OpenTelemetry eventually hits the same wall: too much data, the wrong attributes on spans, rising backend costs, dashboards nobody can read anymore. Most engineers respond by upgrading their plan or writing cleanup code downstream. The real fix usually sits one layer earlier, inside the Collector, in a language called OTTL.

I maintain code in collector-contrib and contribute to OTTL stabilization work upstream. I'll spend most of the time on configs you can copy, not slides: statements that drop spans you don't need, redact fields before they hit storage, rename attributes for consistency across services, and route data by rule instead of hardcoding separate pipelines per signal. I'll also cover where the syntax breaks in ways the documentation doesn't mention, and what's likely to change as OTTL moves toward a stable release.

If you run a Collector and have never opened the transform processor config, this talk will change how you read that file

• Writing OTTL statements for filtering, renaming, and redacting telemetry

• Where OTTL breaks in practice, and the workarounds collector-contrib maintainers actually use

• Routing telemetry by rule instead of maintaining a separate pipeline per signal

• What's changing as OTTL stabilizes, and what that means for configs you write today