Streamlining Observability: Adobe's OpenTelemetry Pipeline Unpacked

In today's complex microservices environments, observability is crucial for maintaining application performance and reliability. Adobe's OpenTelemetry pipeline addresses this need by providing a streamlined approach to instrumentation and telemetry collection. It simplifies the process for service teams, allowing them to focus on building features rather than managing observability intricacies.

At the core of Adobe's architecture is a three-tier design. The OpenTelemetry Operator is deployed in every cluster, enabling service teams to activate instrumentation by simply adding two annotations to their Kubernetes deployment manifests. These annotations are instrumentation.opentelemetry.io/inject-java: 'true' for Java instrumentation and sidecar.opentelemetry.io/inject: 'true' for sidecar injection. The Sidecar Collector runs alongside the application container, locked down to prevent configuration changes, while the Deployment Collector receives telemetry from the sidecar and is configurable via Helm values. This setup allows for efficient routing and export of telemetry data to a centralized managed namespace, where the observability team manages separate collector deployments for each telemetry type.

In production, this architecture simplifies observability management significantly. Service teams can deploy the provided Helm chart into their namespaces, which automatically sets up the necessary collectors. However, be mindful that the Sidecar Collector is intentionally locked down, meaning you cannot modify its configuration. This design choice enhances security and stability but may limit flexibility in some scenarios. Keep an eye on the versioning; as of April 8, 2026, this architecture is actively maintained, ensuring you have the latest features and fixes at your disposal.