What Is OpenTelemetry? A Complete Beginner’s Guide

TL;DR

• OpenTelemetry (OTel) is a free, open-source toolkit that generates, collects, and exports traces, metrics, and logs. It stores and charts nothing itself.
• It became the default because one set of instrumentation now feeds any backend, and the CNCF graduated the project on May 21, 2026.
• Traces, metrics, and logs are stable in the core specification. Profiles and the GenAI conventions are still maturing, so check status before you depend on them.

If your app slows down at 2 a.m., you need to know which service caused it, fast. For years, that answer depended on whichever vendor’s agent you had installed. Switch vendors, and you ripped out one agent, installed another, and rebuilt every dashboard.

OpenTelemetry ends that cycle. It gives every language and every backend one shared way to describe what your software is doing. In May 2026, the Cloud Native Computing Foundation graduated the project and called it the de facto observability standard.

OpenTelemetry is a vendor-neutral standard for producing telemetry: the traces, metrics, and logs that show what your software is doing. You add its SDKs or zero-code agents to your apps, send the data over its OTLP protocol, and route it through its Collector to any backend you pick. You change tools by editing config, not code.

I wrote this guide for IT managers, developers, and business owners at small companies who keep hearing “OTel” and want a straight answer. You don’t need a monitoring background to follow it. I define each technical term the first time it appears.

In this guide, you’ll learn:

• What OpenTelemetry includes, and how stable each part is today
• Why it became the default choice in 2026
• How the pieces fit together, with an original architecture diagram
• A five-step path to move off a proprietary agent
• Where OTel still falls short, including AI workloads
• The two pitfalls that cost teams the most: cardinality and sampling
• A starter Collector config you can copy and adapt

What Does OpenTelemetry Actually Include?

OpenTelemetry gives you five working parts: a shared specification, language APIs and SDKs, zero-code instrumentation, the OTLP wire protocol, and the Collector. Together they cover generating, moving, and processing telemetry. Storage and dashboards stay with other tools, by design. That split is the whole idea, and it trips up most first-time readers.

OpenTelemetry is an observability framework and toolkit, and the project states plainly that it is not an observability backend. Observability here means understanding a system’s internal state from the data it emits.

Here is what each part does, in plain words:

• Traces: Record the path of one request across services. Each step is a span, a timed unit of work such as a database call
• Metrics: Numbers measured over time, such as request counts or memory use
• Logs: Timestamped text or structured records of events
• APIs and SDKs: The per-language libraries. The API defines how your code creates telemetry; the SDK implements the API and handles sampling and export
• Zero-code instrumentation: Adds telemetry to common frameworks without editing your source, through agents such as the Java agent
• OTLP: (OpenTelemetry Protocol) is the standard format for sending telemetry between components
• Semantic conventions: Agreed attribute names, such as http.request.method, so every tool reads the data the same way
• The Collector: Is a standalone proxy that receives, processes, and exports telemetry

How Stable is Each Signal in 2026?

Traces, metrics, and logs are stable in the specification; profiles are not.

Signal	API	SDK	Protocol (OTLP)
Traces	Stable	Stable	Stable
Metrics	Stable	Mixed	Stable
Logs	Stable (Bridge API)	Stable	Stable
Profiles	Not stated on the official page	Not stated on the official page	Development

Language support varies more than the spec does. Python and JavaScript list logs as Development, and Go lists logs as Release candidate. The same page rates the Collector as “mixed” because its components sit at different stability levels.

My advice: Check your own language’s row before you plan a logs rollout. 

Why did OpenTelemetry Become the Default in 2026?

Teams adopt OpenTelemetry for two reasons:

• They instrument once instead of once per vendor
• They keep the freedom to switch backends. 

In 2026, the CNCF graduated the project, which removed the last “is it production-ready?” objection for cautious buyers. Graduation is the CNCF’s top maturity level.

• No duplicate instrumentation: Before OTel, each monitoring vendor shipped its own agent and its own code library. If you ran two tools, your app carried two agents. With OTel, one SDK or agent produces the data, and the Collector fans it out to as many destinations as you need.
• Less vendor lock-in: OpenTelemetry has two principles: you own the data you generate, and you learn one set of APIs and conventions. In practice, moving from one backend to another becomes an exporter change in the Collector.
• Industry backing: The CNCF states the community has more than 12,000 contributors from over 2,800 companies. It also says OTel has the second-highest project velocity among 240+ cloud-native projects, behind only Kubernetes. Note that the CNCF hosts the project, so read these figures as the foundation’s own claims.

One line from that announcement sums up the market shift well. Michele Mancioppi, an OTel maintainer and chief architect at Dash0, says vendors now “compete on who does the best with the telemetry everybody has.” I agree with that framing. For a small team, it means you stop paying a switching cost every time a better or cheaper backend appears.

Who should adopt it now? If you run more than one service, or you expect to change monitoring vendors within two years, start with OTel. If you run a single monolith on one vendor’s agent and you’re happy, you can wait, but instrument any new service with OTel from day one.

How Do You Migrate from a Proprietary Agent to OpenTelemetry?

Migrate one service at a time, and put the Collector in the middle before you touch any app. That order lets you run old and new data side by side, compare them, and roll back with a config change. Plan a few weeks per service group, not a single cutover weekend.

1. Inventory what you rely on: List every dashboard, alert, and SLO that reads from the current agent. An SLO (service level objective) is a target such as “99.9% of checkouts succeed.” These are what must still work after the switch.
2. Deploy the Collector first: Run it as an agent (one per host or node) or a gateway (a central pool). The project’s official Deploy the Collector docs cover both patterns. Point its exporter at your current vendor if that vendor accepts OTLP, so nothing changes for your dashboards yet.
3. Swap the agent on one low-risk service: Replace the vendor agent with OTel zero-code instrumentation for that language. Send data to the Collector and dual-export to the old and the new destination.
4. Compare and remap: Check that request counts, error rates, and latency match within your tolerance. Rebuild queries that used vendor-specific field names so they use OTel semantic convention names instead.
5. Cut over and remove the old agent: Once a service passes for a full release cycle, delete the proprietary agent and its config. Repeat for the next service group.

Where Does OpenTelemetry Still Fall Short?

OpenTelemetry’s weakest areas in late 2026 are AI workloads and profiling. Both work today, but neither carries a stable guarantee yet. If your roadmap depends on LLM monitoring or continuous profiling, expect attribute names and data formats to change under you.

• GenAI semantic conventions are still in flux: The conventions for LLM calls, agents, and tool use have moved out of the main docs. The project’s own GenAI observability blog post describes them as in use and under active development. A formal stability label is not stated on the repository’s README. Treat attribute names such as gen_ai.usage.input_tokens as subject to change, and pin your instrumentation versions.
• Profiles are early: Profiles show where code spends CPU time and memory. The CNCF graduation announcement calls profiles alpha, and the specification lists the profiles protocol as Development.
• What to do about it: Use OTel for traces, metrics, and logs now. For LLM monitoring, use the GenAI conventions but keep a translation step in the Collector, so a rename costs you one config edit rather than a code change across services.

What Are The Most Common OpenTelemetry Pitfalls?

The two mistakes that do the most quiet damage are high-cardinality metrics and badly planned sampling. Both look fine in a test environment. Both fail under real traffic, with dashboards that undercount or a backend bill that grows with every new attribute.

High-Cardinality Metrics

Cardinality is the number of unique attribute combinations a metric produces. Put a user ID or a raw URL on a metric, and that number explodes.

The SDK caps each metric stream at 2,000 combinations by default. Past that cap, the SDK folds new combinations into one overflow data point tagged otel.metric.overflow=true. Totals stay correct, but any chart that filters or groups by an attribute starts to undercount, and nothing warns you.

How to avoid it:

• Keep IDs, raw paths, user input, and free-text error messages off metrics. Put them on spans or logs instead
• Use route templates (/orders/{id}), status codes, and HTTP methods as metric attributes
• Alert on any series carrying the overflow attribute

Sampling Mistakes

Sampling means keeping a representative share of traces instead of all of them. 

• Head sampling decides at the start of a trace, usually by trace ID and a fixed percentage. It is simple, but it cannot guarantee you keep every trace that ends in an error.
• Tail sampling decides after it sees most of the trace, so it can keep all errors and slow requests. The page warns that tail samplers are stateful and can need dozens of nodes at scale.

The page suggests sampling once you pass roughly 1,000 traces per second, and skipping it at tens of traces per second. Most small companies sit in the second group. 

My recommendation: Start with no sampling, watch your backend bill, and add head sampling only when volume forces it. Add tail sampling last, because it changes how you deploy the Collector.

What Does a Starter Collector Config Look Like?

A starter Collector config needs three things: an OTLP receiver, a memory guard, and one exporter to your backend. The sample below adds a privacy step for traces. I wrote it for a single host running the Collector next to your apps; adjust the endpoints for containers or Kubernetes.

# otel-collector.yaml - starter agent config for one host

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: localhost:4317   # apps on this host send OTLP/gRPC here

      http:

        endpoint: localhost:4318   # apps on this host send OTLP/HTTP here

processors:

  memory_limiter:                  # refuses data before the Collector runs out of memory

    check_interval: 5s

    limit_mib: 400

    spike_limit_mib: 100

  attributes/scrub:                # removes personal data from spans

    actions:

      - key: user.email

        action: delete

      - key: enduser.id

        action: hash

exporters:

  otlp_grpc:

    endpoint: ${env:OTLP_BACKEND_ENDPOINT}   # your backend, set outside the file

    sending_queue:

      batch:                       # groups data into batches before sending

  debug:

    verbosity: basic               # prints a summary to the Collector log

extensions:

  health_check:

    endpoint: localhost:13133

service:

  extensions: [health_check]

  pipelines:

    traces:

      receivers: [otlp]

      processors: [memory_limiter, attributes/scrub]

      exporters: [otlp_grpc, debug]

    metrics:

      receivers: [otlp]

      processors: [memory_limiter]

      exporters: [otlp_grpc]

    logs:

      receivers: [otlp]

      processors: [memory_limiter]

      exporters: [otlp_grpc]

• Ports 4317 (gRPC) and 4318 (HTTP) are the OTLP ports the docs use throughout.
• The docs note that the Collector binds to localhost by default and warn that 0.0.0.0 exposes it more widely. Keep localhost unless other machines must send data in.
• A component does nothing until a pipeline under service names it. This is the most common reason a new config “silently” drops data.
• memory_limiter goes first in each pipeline, because processors run in the order you list them.
• ${env:NAME} reads an environment variable, so no backend address or token sits in the file.
• Run otelcol validate –config=otel-collector.yaml before you start it.

The limit_mib values are placeholders for a small host. [ADD: run this config against your own backend and record actual Collector memory use, then tune limit_mib.]

Frequently Asked Questions (FAQs)