OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Ju... Tyler Helmuth & Evan Bradley

OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better - Tyler Helmuth, Honeycomb & Evan Bradley, Dynatrace
As the observability ecosystem rapidly grows in size, choices, and maturity, it's not uncommon to find yourself in situations where your data doesn't look how you expect: it's too large, the wrong shape, or doesn't have everything you want. Enter the OpenTelemetry Collector, an observability pipeline that can receive, process, and export telemetry data at scale. In order to facilitate processing telemetry in a standard way, the Collector uses the OpenTelemetry Transformation Language (OTTL). OTTL enables telemetry transformations based on any field of the payload, utilizing functions to execute the changes. In this session we’ll dive deeper into OTTL, how it solves problems, and how it sets users up for success. We will start with an overview of OTTL, then review common use cases, best practices, and common mistakes. Finally, we’ll look at what's coming up next for OTTL. By the end of this session, you'll know how to transform, filter, sample, and route data based on OTTL statements.

[@johnbradford9541]

OTTL looks like it could be a terrific tool for dynamically instrumenting an app without having to engage the developer. My challenge with it is that the behavior of the where clause in a set statement seems to be inconsistent when matching certain attributes. For example, if the where clause of my set statement looks like this 'attributes["thread.name"] == "ApplicationThread"', the set statement works. If I use the condition attributes["span.kind"] == "client", the set statement never runs. Looking at the data in Jaeger and Splunk APM shows the span.kind attribute set to "client".

[@RonyPlayer]

You should problably enable the debug exporter to double check what you are matching against. Also ask help on the slack channel for CNCF, people are generally helpful there