Enhancing Observability at Scale: Adobe's Utilization of OpenTelemetry Collector

In a recent talk at Open Source Summit North America, Chris Featherstone and Shubhanshu Surana from Adobe highlighted the pivotal role played by the Opentelemetry Collector in their observability practices. Acting as a versatile tool within their open-source observability stack, the collector serves as a central hub, managing and processing vast amounts of trace and metrics data while alleviating developer friction.

Featherstone, a senior manager for software development at Adobe, explained how distributed tracing led them to embrace OpenTelemetry. Given Adobe's composition of multiple acquisitions, each with their own preferences for cloud providers, tools, and frameworks, tracing activities across various platforms became a considerable challenge. This prompted their transition to the Opentelemetry Collector, replacing their existing Jaeger agents in 2020.

Initially designed for trace ingestion, the collector expanded its capabilities to include metrics in September 2021, with plans to incorporate logs as well. Adobe's team leverages OpenTelemetry libraries, focusing on auto-instrumentation, primarily in Java. They enhance applications by incorporating Adobe-specific data and enriching data pipelines as it flows into the collector. Custom extensions and processors further facilitate their configuration management through GitOps.

Featherstone emphasized that the collector's dynamic nature allows data to be sent to multiple destinations, turning it into the "Swiss Army knife" of observability. This flexibility enables the team to process collector data further, even routing it to other collectors for additional processing. This adaptability empowers digital professionals at Adobe to leverage the full potential of observability.

The article also touched upon how Adobe manages their observability data. Surana, an observability engineer at Adobe, explained their data enrichment practices, ensuring no sensitive information is transmitted while improving search capabilities. To prevent service name collisions, Adobe employs an Adobe-specific service registry, allowing engineers to uniquely identify services within their tracing backend. By sending data to multiple export destinations, they enable engineering teams to continue using their preferred backend tools with minimal changes.

Featherstone outlined their future plans, focusing on improving data quality and rate limiting spans at the edge. The collector's configurability and extensibility allow them to eliminate unnecessary data and set up rules for rate limiting, ensuring efficient data management. Additionally, they aim to shift towards trace-first troubleshooting, leveraging complete and comprehensive traces to enhance their troubleshooting process.

Looking ahead, Adobe plans to integrate OpenTelemetry logging libraries with core application libraries, utilizing OTel collectors as sidecars for sending metrics, traces, and logs. They also aim to explore the new connector component and develop a trace sampling extension at the edge to enhance data quality.

Featherstone praised the plug-in-based architecture of OpenTelemetry and the collector's ability to send data to various destinations using a single binary. The project's vibrant community and rapid growth make OpenTelemetry an essential tool for organizations seeking to improve their observability capabilities.

In conclusion, Featherstone encouraged readers to explore OpenTelemetry Collector, emphasizing its potential for revolutionizing observability practices. With its versatility, extensibility, and strong community support, OpenTelemetry represents a promising solution for advancing observability initiatives.