Vendor-neutral instrumentation.
Datadog-grade correlation.
OpenTelemetry gives you SDKs and a collector that belong to nobody. Datadog gives you the place where the trace, the log and the host line up. We implement the two together, through the OpenTelemetry Collector that runs inside the Datadog Agent, and keep the correlation intact. Then we run it every month, so the custom metric bill does not become the first anyone hears about an attribute.
Quick facts
Related
- APM, where the OTel traces end up
- Log Management, the logs the traces need to join
- Infrastructure Monitoring, the host under the service
Instrumentation you could take elsewhere, in a backend you would not want to leave
The platform team chose OpenTelemetry two years ago so that no vendor could hold the instrumentation hostage. Then the traces arrived in Datadog and did not join the logs, and the host under the service was a mystery. Both things are true at once: the instrumentation is portable, and the correlation has to be built.
The Collector you already run, inside the Agent. The Datadog Distribution of the OpenTelemetry Collector bundles the standard receivers, processors and exporters with the Datadog Agent. One rollout, managed through Fleet Automation, with the Agent's own host, container and Kubernetes views kept.
Correlation without re-instrumenting. OTel resource attributes are mapped to Datadog's env, service and version tags on the way in. A span, the log it wrote and the pod it ran on meet in the same view, which is the reason to send OTel data to Datadog rather than anywhere else.
The OTel API on the Datadog SDK, where you want both. For services that need Continuous Profiler or App and API Protection, the Datadog SDK accepts the OpenTelemetry API, so the instrumentation stays portable and the Datadog-only features still work.
Four routes in, chosen per workload. DDOT for most hosts and clusters. The upstream Collector where a neutral pipeline is a requirement. Direct OTLP for serverless and managed platforms with no Agent. Each route keeps a different set of features, and the choice is made deliberately.
Two names for one service, a histogram with eleven attributes, and two collectors on the same host
How it bills. There is no OpenTelemetry meter. OTel data lands on the meters that already exist. A host sending OTel traces is an APM host, counted on the hourly high-water mark of the lower 99 per cent of usage, and its spans are ingested and indexed spans. OTel logs are ingested and indexed logs. OTel application metrics are custom metrics, because Datadog counts any metric that does not come from one of its own integrations as custom, and a histogram becomes several metrics for every combination of attributes it carries. The Agent running the DDOT Collector is an infrastructure host. Datadog publishes the rates. The configuration that decides the number is the attribute set on the metrics and the sampling on the traces, and both are set in code that the platform team owns.
The configuration traps. The SDK sets service.name to one value, the Agent on the host sets the service tag to another, and the log pipeline sets a third, so the service map draws three half-services. Default SDK attributes left on a histogram, so a metric meant to have four series has four hundred. An upstream Collector and a Datadog Agent both running on the same hosts, each exporting a share, so traces arrive twice or metrics arrive as two series with different tags. Tail sampling configured in a Collector by someone no longer on the team, with no record of what it drops.
Field noteThe most common gap we see is the attribute mismatch. service.name in the SDK, the service tag on the Agent and the service field in the log pipeline were each set by a different team in a different quarter, and the trace never finds its log.
Field noteAn instrumentation upgrade moves to a newer semantic convention and adds attributes to the default HTTP metrics, nothing in the application changes, and the custom metric count climbs the following week. Every histogram now carries attributes nobody queries, each one multiplying the series.
Field noteThe pattern we keep finding is two collectors. The upstream OpenTelemetry Collector was deployed first, the Datadog Agent came later for infrastructure, and both export the same metrics with slightly different tags. Every graph that sums the metric reads double, and the ones that average it hide the problem.
Field noteTail sampling in the Collector drops the slow traces because the policy was tuned to keep the bill down during a trial. Error traces are kept, slow ones are not, and the latency investigation finds a service map with no evidence in it.
One route per workload. One name per service. Attributes decided before the metrics arrive.
OpenTelemetry on Datadog is a platform decision that touches the SDKs, the collectors and the Agent fleet, so it is delivered as a LaunchPad project rather than a tuning exercise. If OTel data is already arriving and nothing joins up, a Datadog HealthScan reports the attribute and collector state first, read-only and fully automated. The sequence is the same either way.
- Map the workloads to routes. Hosts and clusters get the DDOT Collector in the Agent. Serverless and managed platforms get direct OTLP. The upstream Collector stays only where a vendor-neutral pipeline is a stated requirement, and then with one exporter.
- Fix the names. service.name, deployment.environment and service.version set once per service in the SDK configuration, carried through the Collector, and matched by the log pipeline. This step is boring and it decides whether anything else works.
- Decide which services need the Datadog SDK. The ones that want Continuous Profiler, App and API Protection or Data Streams Monitoring use the OpenTelemetry API on the Datadog SDK. The rest keep the OTel SDK.
- Set the attribute allowlist on the metrics. Which attributes each metric keeps, which are dropped in the Collector, and which histograms need percentiles. Checked against the custom metric allotment before the first week of data.
- Set sampling with a written reason. Head sampling in the SDK or tail sampling in the Collector, per service, keeping errors and slow traces by policy. The policy is recorded, so the next person knows what is being dropped.
- Roll out through Fleet Automation and hand over, in writing. Collector configurations managed centrally, versions pinned. The handover lists each workload's route, the attribute allowlists, the sampling policy and the final span and metric volumes.
Access is admin on the Datadog organisation and collector rollout through your deployment tooling. SDK attribute changes are pull requests into your repositories, reviewed by your engineers. We do not need production shell access, and we do not ask for it.
Every SDK upgrade is a chance for the attributes to change without asking
A new service ships with the template's default service name. An SDK release adds attributes. A team adds a histogram with a user ID on it, for a good reason, for a week. Managed Observability is the monthly service that keeps the OTel pipeline matching the applications and the allotment.
Every month, cardinality and volume are reviewed. Custom metrics from OTel against the allotment, span volumes per service against the sampling policy, and the metrics that grew a new attribute since last month. Anything that moved gets a reason or a fix.
Coverage follows the deployments. A new service with the wrong attributes or none is found in the service map review and corrected before it is the service everyone is looking for. New clusters get the DDOT Collector through Fleet Automation.
Correlation is kept honest. Traces that do not find their logs, logs without a trace ID and services that split in two are the first items on the monthly list, because every other investigation depends on them.
The collectors are kept current. Versions pinned, upgrades tested on one cluster first, configurations managed in one place. When an OpenTelemetry release changes a default, the estate finds out from us rather than from the invoice.
We operate the stack. You own the product.
Choosing OpenTelemetry is a choice to own the instrumentation. We respect that, and we do not undo it. The SDK configuration, the collector pipelines and the attribute decisions stay in your repositories, in your deployment tooling, documented, and portable to any backend you choose later. What we add is a team that has run both the Datadog Agent and the OpenTelemetry Collector in production for years and knows where the two disagree.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog OpenTelemetry, answered plainly
How does OpenTelemetry data get into Datadog?
Four ways. The DDOT Collector, which is the Datadog Distribution of the OpenTelemetry Collector running inside the Datadog Agent, is the one Datadog recommends and the one we implement by default. A standard OpenTelemetry Collector with the Datadog exporter works where a vendor-neutral pipeline is a requirement. The Agent can also receive OTLP directly from an SDK. And OTLP can be sent straight to Datadog with no Agent or Collector at all, which suits serverless and managed platforms. The choice decides which Datadog features still work, and that is the implementation decision.
How is OpenTelemetry billed in Datadog?
There is no OpenTelemetry meter. OTel data lands on the same meters as everything else. A host sending OTel traces counts as an APM host, and its spans count as ingested and indexed spans. OTel logs count as ingested and indexed logs. OTel application metrics are custom metrics, because Datadog counts any metric that does not come from one of its own integrations as custom, and a histogram becomes several metrics per attribute combination. The Agent running the DDOT Collector counts as an infrastructure host. Datadog publishes the rates. We do not publish prices. What we tune is the attribute cardinality and the sampling, because those decide the bill.
Do we lose Datadog features by using OpenTelemetry?
Some, and which ones depends on the setup. With the OTel SDK and the DDOT Collector you keep distributed tracing, correlated traces, logs and metrics, the infrastructure host list, Kubernetes monitoring, Database Monitoring correlation, Universal Service Monitoring and Live Containers. Continuous Profiler, App and API Protection and Data Streams Monitoring need the Datadog SDK, which can be used alongside the OpenTelemetry API so the instrumentation stays portable. Direct OTLP ingest with no Agent loses the host and Kubernetes views. We lay this out per service before anything is instrumented.
Why do our OpenTelemetry traces not join up with our logs in Datadog?
Because the names differ. Datadog joins traces, logs and metrics on the env, service and version tags. OpenTelemetry carries them as the resource attributes service.name, deployment.environment and service.version. The DDOT Collector maps one to the other automatically, but a service whose SDK says one name while its Agent or its log pipeline says another appears as two half-services that never meet. The fix is one value per attribute, set in the SDK, and a log pipeline that carries the trace ID and the same service name.
What does Critical Cloud do with OpenTelemetry every month?
Managed Observability reviews the OTel metric cardinality against the custom metric allotment, the span volumes against the sampling in force, and the service map for services that appeared with the wrong attributes or none. Collector versions and configurations are managed through Fleet Automation. New services instrumented with OTel are checked for correlation before they are the service everyone is looking for. What changed, and why, is reported.
- Datadog products: every product, and how we implement and run each one
- APM and Log Management: where the OTel traces and logs end up, and the sampling and indexing that bill them
- Datadog custom metrics cost optimisation: the meter every OTel metric lands on
- LaunchPad: the project-managed rollout for the collectors, the attributes and the Agent fleet
Portable instrumentation. Correlation that holds. A bill that does not surprise.
Tell us which SDKs the services use and whether a collector is already running. We will tell you which route each workload should take, what the attributes are costing today, and what it takes to make the trace find its log.