OpenTelemetry Collector in Kubernetes | Datadog
Back to Architecture Center
Architecture Center OpenTelemetry Collector in Kubernetes

OpenTelemetry Collector in Kubernetes

August 7, 2025

Introduction

Kubernetes has become the de facto standard for container orchestration, and teams need robust observability within these dynamic environments. OpenTelemetry (OTel), with its vendor-agnostic approach, is one of the most popular choices for generating and managing observability data. However, deploying and configuring OTel in Kubernetes environments can be complex, and for many organizations, it can be particularly challenging to integrate OTel deployments in Kubernetes with backend platforms such as Datadog.

OpenTelemetry Collector in Kubernetes

Explanation of the architecture

This design utilizes the OpenTelemetry Collector within a Kubernetes environment to gather telemetry data and transmit it to Datadog via the Datadog exporter. This strategy is ideal for users who value a vendor-agnostic solution and want to adhere to open source standards, while still using Datadog for data analysis and visualization. In addition, this approach is particularly beneficial for those with unique data processing or routing needs, which require significant customization of telemetry pipelines.

  • Step 1 - Instrumentation

    OpenTelemetry instrumentation allows applications to generate detailed telemetry data—such as traces, metrics, and logs—in a standardized format, providing deep visibility into performance and behavior. It supports both manual and automatic instrumentation, letting developers choose the level of control and customization needed to monitor distributed systems effectively. By default, the applications then emit this data using the OpenTelemetry Protocol (OTLP) over HTTP on port 4317 or gRPC on port 4318.

  • Step 2 - OTel Collector Daemonset

    The OTel Collector is deployed as a DaemonSet to collect logs, metrics, and traces from every node within a cluster. It is configured to receive OTLP data from the instrumented applications. The DaemonSet collectors utilize presets for log collection, host metrics, Kubernetes attributes, and kubelet metrics. This enables the collection of telemetry data and enrichment of metadata from both the Kubernetes node itself and the workloads running on that node. This method avoids data duplication, which would occur if multiple collectors (as in a DaemonSet or a multi-replica deployment) were to gather the same cluster-level information.

  • Step 3 - OTel Collector Deployment

    A deployment of the OTel Collector gathers cluster-scoped metrics, with only one replica to prevent duplicate data. This collector is configured with cluster metrics, Kubernetes events, and Kubernetes attributes presets.

  • Step 4 - OTel Collector Processing

    The OTel Collector uses processors for tasks like batching, filtering, adding attributes, and sampling on the telemetry data it receives. In a Kubernetes environment, Helm chart presets simplify setup by pre-defining configurations for common use cases. For example, the Kubernetes attributes processor adds Kubernetes metadata to logs, metrics, and traces. Additionally, the Collector can be configured to collect logs from Kubernetes containers and cluster-level metrics from the Kubernetes API server.

  • Step 5 - Datadog Exporter

    The OTel Collector uses the Datadog Exporter to send processed data to Datadog. The Collector can be configured to send data to other destinations at the same time by using additional exporters.

  • Step 6 - Analysis and Monitoring

    Datadog provides a suite of tools—including dashboards, metrics, logs, APM, and the Trace Explorer—that help you visualize and analyze telemetry data collected with OTel. It also offers out-of-the-box dashboards specifically for OTel data. Metrics sent from the Datadog Exporter are stored for up to 15 months, allowing for longer-term trend analysis.

Challenges

Organizations encounter a few common challenges when using the OTel Collector to send telemetry to Datadog in Kubernetes environments: - Configuration can be complex, as deploying and managing a standalone collector requires a deep understanding of its various configuration options. This contrasts with more streamlined approaches that rely on the Datadog Agent. - Operational overhead is also greater, demanding more effort to maintain the collector compared to using Datadog’s Agent with Embedded OTel Collector. It also necessitates a higher degree of OpenTelemetry expertise to effectively optimize the collector’s performance and configuration, as the user must handle all aspects of the collector’s maintenance. - User experience in Datadog when using a standalone collector may not be as seamless as it is when using the Datadog Agent.

This solution for using the OTel Collector with Datadog in Kubernetes environments reduces complexity and operational overhead, while still allowing users to enjoy the flexibility and vendor-neutrality of the OpenTelemetry ecosystem and providing full observability at the node and cluster levels. To simplify deployment, it is recommended to use the community-supported OpenTelemetry Helm chart, which provides a foundation for managing the OTel Collector and allowing for customization including the use of the Datadog Exporter.

Authors

Kennon Kwok - Senior Product Solutions Architect