Observability guide · OpenTelemetry
OpenTelemetry: what it standardises, what it leaves to your platform, and how to adopt it
OpenTelemetry (OTel) is an open-source framework that defines how applications produce and send traces, metrics and logs: one set of APIs, one data format and one protocol, whatever language a service is written in. It does not store data, draw dashboards or raise alerts; an observability platform such as Datadog does that. This guide explains what OpenTelemetry covers, where it stops, and how an organisation with services in several languages can adopt it without instrumenting twice.
Published 11 min read
In short
- What it is: an open standard governed by the Cloud Native Computing Foundation (CNCF), which moved it to Graduated status on 11 May 2026. It provides APIs, language SDKs, automatic instrumentation, naming conventions, a wire protocol (OTLP) and a Collector.
- What it standardises: how telemetry is generated, labelled and transported.
- What it leaves to your platform: storage, search, dashboards, alerting and analysis.
- Why organisations adopt it: instrumentation written once keeps working if the analysis platform changes, and one pipeline can apply masking, sampling and routing to every language in the same way.
The problem OpenTelemetry solves
In an estate built by different teams over many years, services are often written in several languages and monitored differently: one uses a vendor agent, another writes logs to files, a third has nothing. When a customer-facing incident happens, engineers lose time stitching evidence together from tools that do not share identifiers or naming.
OpenTelemetry replaces those per-team habits with one standard. Every service, in every language, produces the same kinds of data with the same names and sends it over the same protocol. That is what makes a request traceable from a Python checkout service into a Java payments service and back, in one view.
Read more
A useful way to explain it to non-engineers is the shipping container:
| Shipping | Software |
|---|---|
| Goods of every kind | Telemetry: traces (the journey of a request), metrics (numbers over time), logs (event records) |
| The standard container | The OpenTelemetry data format and protocol (OTLP) |
| Factories packing containers | Applications in .NET, Java and Python packing telemetry with OpenTelemetry SDKs |
| Ports and sorting yards | The OpenTelemetry Collector, which receives, inspects, cleans and routes data |
| The destination warehouse | The observability platform, for example Datadog, which stores, analyses and alerts |
Because every application packs its data the same way, the destination can change, or a second one can be added, without touching application code.
What OpenTelemetry is made of
OpenTelemetry is a set of parts, and different people in your organisation touch different ones.
| Part | What it does | Who works with it |
|---|---|---|
| API | The interfaces code calls to create spans, metrics and log records | Application developers |
| SDK (one per language) | Implements the API: processing, sampling and export | Developers and the platform team |
| Automatic instrumentation | Captures common frameworks and libraries, such as incoming HTTP requests and database calls, without code changes | Platform team |
| Semantic conventions | Standard attribute names, such as service.name and http.route, so data from different teams means the same thing | Everyone |
| OTLP | The wire protocol, over gRPC (port 4317) or HTTP (port 4318) | Platform and network/security teams |
| Collector | A service you run that receives, processes and forwards telemetry | Platform or SRE team |
How the three signals connect. Each request carries a trace context from service to service (the W3C traceparent header). Spans created along the way share one trace ID, and log records written during the request can carry the same trace and span IDs. That shared context is what lets a platform jump from a slow request to its logs and the metrics of the services it touched.
What OpenTelemetry does not do
OpenTelemetry deliberately stops at collection and transport. Everything after that is the job of the platform you send the data to.
| Capability | OpenTelemetry | Your observability platform (for example Datadog) |
|---|---|---|
| Instrumentation libraries for .NET, Java, Python and other languages | Yes | — |
| Standard data format and protocol (OTLP) | Yes | Accepts it |
| Vendor-neutral pipeline (the Collector) | Yes | Receives from it |
| Long-term storage and fast querying | — | Yes |
| Service maps, distributed trace views, application performance monitoring | — | Yes |
| Log management correlated with traces | — | Yes |
| Alerting, service level objectives, anomaly detection | — | Yes |
| Dashboards for engineers and executives | — | Yes |
This split matters when you budget: adopting OpenTelemetry does not remove the need for a platform, and choosing a platform does not have to lock your code to it.
Three decisions to make before anyone instruments a service
These three decisions are hard to change once dozens of services depend on them, so settle them centrally rather than leaving them to each team.
1. A naming and tagging standard. Decide, once, how services and environments are named, because these attributes become the filters everyone uses. A workable standard:
| Attribute | Required | Rule |
|---|---|---|
service.name | Yes | Lowercase, hyphen-separated, unique across the organisation: domain-component, for example payments-gateway |
deployment.environment.name | Yes | One of: dev, test, uat, staging, prod |
service.version | Yes | Semantic version or Git commit SHA injected by the CI/CD pipeline, never hard-coded |
service.namespace | Recommended | Business domain or product line, for example retail |
team | Recommended | Owning team, used for routing and ownership, for example checkout |
Read more
Datadog reads service.name as its service tag, service.version as version and deployment.environment.name as env. Datadog supports deployment.environment.name from Agent 7.58.0 and Datadog Exporter v0.110.0; older versions read the earlier key, deployment.environment. While both generations are running, setting both keys to the same value avoids services appearing without an environment.
2. Where telemetry is processed. Applications can send data to a central Collector gateway that you operate, to an agent on each host, or directly to the platform. The choice decides where masking and sampling happen and how many components your team runs. If Datadog is the destination, Datadog's own options and how to choose between them are compared in Sending OpenTelemetry data to Datadog.
3. Who owns the policies. Three policies cut across every team: what personal data must never leave your network, how much trace data is kept, and what the ingest budget is. Name an owner for each, typically security or the data protection officer for masking, the platform team for sampling, and platform with finance for cost, before the first service goes live.
A four-phase adoption plan
OpenTelemetry is adopted service by service, not in one switch-over. Each phase below ends with something you can check.
- Foundation. Deploy the Collector gateway, agree the tagging standard and instrument one pilot service per language. Done when: data from every pilot reaches the platform with correct service, environment and version, and one request can be followed end to end across two languages.
- Rollout. Apply automatic instrumentation to the remaining services, connect logs to traces and build a dashboard per service. Done when: end-to-end traces cross every language in the estate.
- Governance. Put personal-data masking rules, sampling policies, service level objectives and cost dashboards in place. Done when: masking rules have been reviewed with security and the data protection officer, and ingest volume is measured and predictable.
- Optimisation. Add custom spans and metrics for the business steps that matter, such as orders, payments and sign-ups. Done when: telemetry answers business questions ("which release slowed checkout?"), not only technical ones.
How long each phase takes depends on the number of services, languages and release cadence; we size it after an assessment of your estate.
Automatic instrumentation first, manual spans where the business is
Automatic instrumentation gets services producing useful traces with little or no code: none in Python and Java, and a few lines of start-up configuration in .NET if you use the package route. Business context, such as which payment method failed or how large the basket was, needs a few lines of code.
| Language | How automatic instrumentation is enabled | Points to watch |
|---|---|---|
| Python (FastAPI, Flask, requests) | Install the OpenTelemetry distribution and wrap the start command with the opentelemetry-instrument launcher; no code changes | With pre-fork servers such as Gunicorn, start instrumentation after the fork or use Uvicorn workers |
| .NET 8 (ASP.NET Core) | Add the OpenTelemetry hosting extension, the OTLP exporter and instrumentation packages for ASP.NET Core, HttpClient and runtime metrics, and register them in the application's start-up code. A zero-code option, installed with a script, also exists | Keep every OpenTelemetry.* package on the same minor version |
| Java (Spring Boot) | Attach the OpenTelemetry Java agent at JVM start-up | Pin the agent version in your build pipeline; use "latest" only for a first test |
All three honour the same standard environment variables (OTEL_SERVICE_NAME, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_ENDPOINT and others), so the identity and destination of every service can be set once in deployment templates such as Kubernetes manifests or Helm values.
Where manual spans pay off: the few customer journeys that carry the business; we start with the top three. Add spans for steps like "calculate total" or "authorise payment", attach business attributes such as order amount and currency, and never put raw personal data in those attributes.
Common failure points, and their fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Services appear without environment or version | Resource attributes not set | Set OTEL_RESOURCE_ATTRIBUTES with the environment key(s) and service.version |
| One request shows up as separate traces per service | Context propagation mismatch | Use the W3C tracecontext and baggage propagators in every service |
| Logs are not linked to traces | Logs leave the application outside OpenTelemetry, without trace IDs | Export logs over OTLP, or add trace_id and span_id to the log format |
| The Collector refuses data under load | Memory pressure on the Collector | Add replicas, raise the memory limit, or reduce batch size |
| Host metrics are counted twice | Two components collecting host metrics on the same node | Choose one host-metrics source per node |
Is OpenTelemetry the right choice for you?
It usually fits when: services are written in more than one language or owned by several teams; you want to keep the option of changing or adding an analysis platform; or personal data must be masked consistently before telemetry leaves your network.
Check before you commit: the platform features you get can depend on how you instrument. Datadog, for example, states that the features available depend on the OpenTelemetry setup you choose, and that using the OpenTelemetry API with Datadog's own SDK gives access to more Datadog features than the OpenTelemetry SDK alone. Read the platform's feature compatibility table against your must-have features before standardising.
Maturity: the project graduated in the CNCF in May 2026, but individual components and language SDKs move at different speeds. The project publishes the status of each component; check it for the languages you run.
How Interkey works with OpenTelemetry
Interkey is an official Datadog partner and assesses, implements and operates Datadog for organisations in Saudi Arabia, with an implementation team in Riyadh. Our OpenTelemetry reference design covers .NET 8, Java (Spring Boot) and Python (FastAPI and Flask) services sending traces, metrics and logs through a centrally governed Collector to Datadog.
On an OpenTelemetry engagement we work through a fixed checklist with your teams:
Read more
- an approved tagging standard (service, environment, version, team);
- the Collector gateway, with the Datadog API key held in your secret manager;
- one pilot service per language, and one cross-language trace proven end to end;
- personal-data masking rules, reviewed with your security team and data protection officer;
- a sampling policy per environment, with ingest measured;
- a pipeline-health dashboard and monitors;
- business spans and metrics for your top three customer journeys.
The technical detail of the Datadog side, including the ingestion paths Datadog documents and how to verify a pipeline hop by hop, is in Sending OpenTelemetry data to Datadog.
Glossary
- Trace:
- the full journey of one request across services, like a parcel's tracking history.
- Span:
- one step in that journey, such as one service call or one database query.
- Metric:
- a number measured over time, such as requests per second.
- Log:
- a timestamped record of an event.
- OTLP:
- the OpenTelemetry Protocol, the standard format for sending telemetry.
- Collector:
- the service that receives, cleans, samples and forwards telemetry.
- Resource attributes:
- labels describing who produced the data: service, version, environment, host.
- Context propagation:
- passing the trace ID between services so one request stays one trace.
- Sampling:
- keeping a representative subset of traces to control volume and cost.
Questions buyers ask
Is OpenTelemetry free?
The project is open source and governed by the CNCF. The costs are the engineering time to instrument and run the pipeline, and the platform that stores and analyses the data.
Does OpenTelemetry replace Datadog?
No. OpenTelemetry is not an observability backend: it produces and moves telemetry. Datadog accepts OpenTelemetry data and provides the storage, analysis, dashboards and alerting.
Do we have to change application code?
Not to start. Automatic instrumentation captures common frameworks without touching business logic: no code at all in Python and Java, and a few lines of start-up configuration in .NET (or none with its zero-code option). Business context, such as order values or payment outcomes, needs small manual additions.
We already run the Datadog Agent. Do we have to remove it?
No. Datadog's recommended path combines its Agent with an embedded OpenTelemetry Collector, and the Agent can also receive OTLP data directly. The options are compared in Sending OpenTelemetry data to Datadog.
Can OpenTelemetry help keep personal data inside our network?
It gives you a place to enforce it. The Collector runs in your own infrastructure, so masking rules can be applied before telemetry is exported. How to design and test those rules is covered in Keeping personal data out of logs and traces.
Is there a Datadog site in Saudi Arabia?
Not as of November 2026: Datadog's published sites are in the United States, Germany, Japan, Australia and the United Kingdom. What that means for your data is covered in Observability data residency in Saudi Arabia.
Next
Related guides
Next step
Plan an OpenTelemetry rollout
Tell us which languages and platforms your services run on, roughly how many services there are, and where telemetry goes today. A specialist from the Riyadh team replies on Saudi working days, in Arabic or English.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia