OpenTelemetry (OTel) is the open-source, vendor-neutral standard for collecting telemetry: traces, metrics, logs, and now continuous profiles, from cloud-native applications. In May 2026, the Cloud Native Computing Foundation (CNCF) graduated OpenTelemetry, the same status held by Kubernetes and Prometheus, cementing it as the de facto standard for observability data. The project now counts more than 12,000 contributors across 2,800+ companies.
If you’re new to the project, start with our What is OpenTelemetry? guide for the fundamentals. This post focuses on what comes after adoption: the practices that keep OpenTelemetry data useful and your observability bill under control as your instrumentation footprint grows.
Where OpenTelemetry Stands in 2026
Since this post was first published in 2023, OpenTelemetry has moved a long way. A few things worth knowing before you plan your implementation:
- Traces, metrics, and logs are now stable across every major language SDK.
- Continuous profiling has emerged as a fourth signal: it entered public Alpha in March 2026. That’s a real milestone, but OpenTelemetry’s own guidance is not to rely on it for critical production workloads yet. It’s increasingly supported natively in the OpenTelemetry Collector and in SDKs for Go, Java, Python, and .NET.
- Semantic conventions are maturing at different speeds, not uniformly “stable”: database conventions carry a “Mixed” status (core spans and attributes are stable, some newer additions aren’t), while messaging conventions remain in “Development.” OpenTelemetry’s own guidance is to hold off changing convention versions in production until messaging is marked stable. The gen_ai conventions (covering LLM inference spans, via attributes like gen_ai.request.model and gen_ai.usage.input_tokens) are earlier still, also “Development,” and were split into their own dedicated repository in mid-2026. Worth tracking closely if you’re instrumenting AI or agentic workloads, since breaking attribute changes are still expected.
- The community moved its real-time discussion from Gitter to CNCF Slack.
None of this changes the fundamentals below. It just means there’s more surface area to get right, and more ways to waste data volume (and budget) if you don’t.
Best Practices
1. Start with a clear observability strategy
Before instrumenting anything, decide what you’re actually trying to answer: are you troubleshooting performance regressions, tracking user behavior, or monitoring infrastructure health? A clear goal determines which signals, sampling rates, and retention windows you need, and keeps you from instrumenting everything “just in case,” which is the single biggest driver of unnecessary telemetry cost.
2. Standardize on OpenTelemetry’s semantic conventions
OpenTelemetry’s common data model, standard fields for service name, operation name, resource type, and more, is what makes data portable across tools. Lean on the database conventions wherever they apply (core attributes there are stable), but treat messaging and gen_ai conventions as still evolving: if you’re working with LLM or agent workloads, adopt the gen_ai conventions anyway, since waiting for “Development” status to resolve means waiting indefinitely, but pin the semantic-conventions version you target so a future spec change doesn’t silently break your dashboards. This matters more than usual right now: the gen_ai conventions moved into their own repository in mid-2026 and are still seeing breaking renames.
3. Combine automatic and manual instrumentation
Auto-instrumentation gets you baseline visibility into common libraries and frameworks (HTTP servers, databases, message brokers) with no code changes, and it’s the fastest way to get started. But production teams rarely rely on it alone: they layer manual instrumentation on top for business-critical operations and custom logic that auto-instrumentation can’t see. Start broad with automatic instrumentation, then add manual spans and attributes where the business logic actually demands it.
4. Control cost with sampling and filtering at the collector
This is the practice most teams skip, and it’s the one with the biggest cost impact. Use tail-based sampling in the OpenTelemetry Collector: keep 100% of error traces and unusually slow traces, and sample a small percentage (roughly 5 to 10%) of everything else. Filter out low-value, high-volume noise (health check pings, routine filesystem or DNS calls) as close to the source as possible, before it’s shipped and paid for downstream.
5. Choose the right collector deployment and exporter
Collector topology matters as much as which exporter you pick. Consider an agent-plus-gateway deployment: lightweight agents run alongside your services, forwarding to a central gateway collector that handles batching, filtering, and routing to your backend(s). When evaluating exporters, weigh compatibility, scalability, and how much processing you want to push to the edge versus centrally.
6. Plan for the fourth signal: continuous profiling
Profiling surfaces resource-usage issues (CPU, memory) that traces, metrics, and logs alone often miss. It reached public Alpha in March 2026, a genuine step forward, though OpenTelemetry cautions against relying on it for critical production workloads just yet. Start evaluating it now in a non-critical service, and make sure any profiling data you collect can be linked back to related traces, metrics, and logs through shared resource context. That’s what makes profiling additive rather than one more disconnected data silo. For a closer look at when each one is the right tool, see Profiling vs Tracing in OpenTelemetry.
Implementation Fundamentals
A handful of practical guidelines make day-to-day OpenTelemetry work smoother, regardless of which language or framework you’re using.
Separate initialization from instrumentation
OpenTelemetry’s API is vendor-agnostic by design: every telemetry call inside your application goes through the OpenTelemetry API itself, with no hard dependency on a specific backend. Keep provider configuration at your application’s entry point, decoupled from the instrumentation calls scattered through your code. Done right, you can switch providers or backends via configuration alone, with no code changes required.
Understand your span processors
OpenTelemetry offers two ways to export spans: a SimpleSpanProcessor, which exports each span as soon as it completes, and a BatchSpanProcessor, which buffers spans and flushes them together when the buffer fills or a timeout is reached. Simple processing is easier to reason about for debugging; batch processing is what you want in production, since it reduces the number of export calls and network overhead.
Use auto-instrumentation deliberately
Auto-instrumentation (available for Java, Python, JavaScript, .NET, and more) meaningfully lowers the barrier to adopting OpenTelemetry, but it isn’t free. Every additional wrapped function adds some overhead, and it’s easy to end up capturing far more spans than you’ll ever look at. Pair it with the filtering practice above so auto-instrumentation gives you coverage without becoming its own cost problem.
Unit test your instrumentation
Treat your telemetry like any other code path: unit tests that verify the metadata you emit (tags, metric names, span attributes) catch instrumentation regressions before they silently break a dashboard or alert.
Lean on the (now much better) official docs
Post-graduation, OpenTelemetry’s documentation is considerably more mature than it was a few years ago, and it should be your first stop. For features that are still stabilizing (profiling and gen_ai conventions are the current examples), the project’s source code and changelogs on GitHub are still the most reliable reference.
Join the community on CNCF Slack
OpenTelemetry’s community discussion now happens in CNCF Slack, not Gitter. Channels like #opentelemetry and #otel-semantic-conventions cover project-wide developments and spec discussions; if you’re not sure where to ask, post in #otel-sig-end-user and the community will help route your question.
OpenTelemetry and Apica
OpenTelemetry solves how you generate and standardize telemetry. It doesn’t solve where that data should live, what it costs to retain, or how you make sense of it at scale. That’s where a platform layer comes in:
- Apica Flow collects and routes OTel data before ingestion, optimizing volume via the sampling and filtering practices above at the pipeline level.
- Apica Lake and InstaStore give OTel traces long-term, compliant retention with on-demand retrieval, instead of forcing a tradeoff between cost and history.
- Apica Observe correlates OTel traces, metrics, and logs with AI-driven root cause analysis.
- If you’re instrumenting LLM or agentic workloads with the emerging gen_ai conventions, see Apica’s AI & LLM Observability solution.
For more on how OpenTelemetry and pipeline architecture fit together, see OpenTelemetry and Intelligent Pipelines.
In a Glimpse
- OpenTelemetry graduated CNCF in May 2026, becoming the de facto observability standard alongside Kubernetes and Prometheus.
- Traces, metrics, and logs are stable across major SDKs; continuous profiling entered public Alpha in March 2026 but isn’t yet recommended for critical production workloads.
- Semantic conventions are maturing unevenly: database conventions are “Mixed,” while messaging and the newer gen_ai (LLM) conventions remain in “Development.” Expect further breaking changes, especially for gen_ai.
- Combine automatic and manual instrumentation, and use tail-based sampling plus filtering at the collector to control cost as data volume grows.
- The community has moved from Gitter to CNCF Slack.
- Apica pairs OpenTelemetry with intelligent pipeline routing (Flow), long-term retention (Lake/InstaStore), and AI-driven correlation (Observe) to keep OTel data both comprehensive and affordable.
