Every observability vendor used to ship its own agent and SDK. Switching platforms meant re-instrumenting every service, so most teams never switched, even when costs or capabilities no longer fit. OpenTelemetry changed that.
This guide explains what OpenTelemetry is, how it works and how to adopt it without disrupting your teams.
Switching platforms meant re-instrumenting every service, so most teams never switched, even when costs or capabilities no longer fit.
What is OpenTelemetry?
OpenTelemetry is an open-source observability framework that provides a single set of APIs, SDKs and tools for generating and exporting telemetry data. It was formed in 2019 by merging two earlier projects, OpenTracing and OpenCensus, and is hosted by the Cloud Native Computing Foundation (CNCF).
OpenTelemetry is not a backend. It does not store or visualise data. It produces and transports data to the backend of your choice, such as Grafana Cloud, Datadog, Elastic, New Relic, Honeycomb or a cloud provider's native tools.
What does OpenTelemetry include?
| Component | What it does |
|---|---|
| Specification | Defines data models and behaviour across languages |
| APIs and SDKs | Libraries for Java, .NET, Python, Go, JavaScript and more |
| Auto-instrumentation | Agents and libraries that instrument common frameworks without code changes |
| Semantic conventions | Standard names for attributes like http.request.method or service.name |
| OTLP | The OpenTelemetry Protocol for sending telemetry |
| Collector | A service that receives, processes and exports telemetry |
What signals does OpenTelemetry support?
Distributed trace spans across microservices
Illustration in progress
- Traces: follow a request across services, showing each step as a span.
- Metrics: counters, gauges and histograms for rates, sizes and durations.
- Logs: structured log records correlated with traces through trace and span IDs.
- Profiles: continuous profiling, which entered public alpha in March 2026 and links profiles to traces; it is not yet recommended for critical production workloads.
How does the OpenTelemetry Collector work?
The Collector is a pipeline with three stages:
OpenTelemetry Collector architecture
Illustration in progress
- Receivers accept data in OTLP, Prometheus, Jaeger, Zipkin and other formats.
- Processors batch data, add attributes, drop noisy telemetry, redact sensitive fields and apply sampling.
- Exporters send data to one or more backends.
Running the Collector as an agent on each node and as a central gateway gives you one control point for cost, security and routing. You can even send the same data to two backends during a migration.
Why does OpenTelemetry matter for the business?
- No vendor lock-in. Change backends without re-instrumenting every service.
- Cost control. Filter, sample and route data before it reaches expensive storage.
- Consistency. Every team uses the same naming conventions, so cross-service investigation works.
- Future-proofing. OTel is the industry standard and widely adopted by cloud providers and vendors.
How do you adopt OpenTelemetry?
- Start with a pilot service on a critical user journey.
- Use auto-instrumentation first for HTTP, database and messaging libraries.
- Deploy the Collector as a gateway with batching and resource detection.
- Agree semantic conventions, especially service.name, deployment.environment and team ownership attributes.
- Add manual spans for important business operations, such as "place order".
- Set a sampling strategy. Tail-based sampling keeps errors and slow requests while dropping routine traces.
- Roll out service by service, running in parallel with existing agents until you are confident.
How Crozaint approaches OpenTelemetry
OpenTelemetry is the instrumentation standard in every Crozaint observability engagement. In the Audit phase (weeks 1–2) we map your current tools and telemetry and define an OTel instrumentation strategy. In the Build phase (weeks 3–4) we deploy Grafana Cloud and instrument services with OpenTelemetry.
Because instrumentation is vendor-neutral, your team keeps full control. You own the configuration, and you can change backends later without starting over.
Common mistakes to avoid
- Instrumenting everything at once instead of starting with key journeys
- Inconsistent service.name values across teams
- Sending every trace to the backend without sampling
- Logging sensitive data without Collector redaction
- Mixing proprietary agents and OTel without a migration plan
Conclusion
OpenTelemetry is the foundation of modern observability. Instrument once, route anywhere, and keep control of your telemetry and your costs.
Planning an OpenTelemetry rollout? Book a 30-minute discovery call with a Crozaint observability engineer.