What is Observability
🧠 What is Observability and who is it for?
Observability is the ability of a system to reveal its state based on collected data.
- Answers questions: Why is something not working?
- Enables discovery of unknown problems (unknown unknowns)
- Combines data from logs, metrics, and traces
Observability and OpenTelemetry
What is OpenTelemetry in relation to Observability?
OpenTelemetry is a way to implement observability
🧩 What is OpenTelemetry?
- A CNCF (Cloud Native Computing Foundation) project
- Standardizes how telemetry data is collected, processed, and exported
- Supports logs, metrics, traces, and profiles
- Has libraries for most languages: Go, Java, .NET, Python, JS, Rust
- Library status: https://opentelemetry.io/docs/languages/
The problem before OpenTelemetry
Before OTel, every observability vendor had its own proprietary agent and SDK:
| Vendor | Agent/SDK | Lock-in effect |
|---|---|---|
| Datadog | dd-trace-*, datadog-agent |
Traces, metrics, logs all tied to Datadog format |
| New Relic | newrelic-* agents |
Custom instrumentation API, proprietary protocol |
| Dynatrace | OneAgent | Binary injection, vendor-specific data model |
| Elastic | APM agents | ECS format, Elasticsearch-centric |
| Jaeger / Zipkin | Separate client libs | Different wire protocols, incompatible context propagation |
Consequences:
- Switching vendors meant re-instrumenting every service — weeks or months of work
- Multi-vendor setups required running multiple agents side by side
- No standard for what a “span” or “metric” looks like — each vendor defined its own semantic conventions
- Library authors couldn’t add observability without picking a vendor
OpenTelemetry solves this by providing one standard for instrumentation. You instrument once, and send data to any backend — Grafana stack, Datadog, Elastic, or all of them at the same time.
Who is OpenTelemetry for?
| Role | What OTel gives you |
|---|---|
| Developers | Instrument once with a standard SDK. No vendor-specific code in your application. Auto-instrumentation covers HTTP, DB, messaging out of the box. |
| Platform / DevOps teams | One Collector pipeline to manage instead of N vendor agents. Centralized control over sampling, filtering, and routing. |
| SRE / On-call | Consistent telemetry across all services regardless of language. Correlate traces, metrics, and logs using shared context (trace ID, span ID). |
| Architecture / Management | No vendor lock-in. Switch or add backends without touching application code. Negotiate vendor contracts from a position of strength. |
Signal Maturity
| Signal | Status |
|---|---|
| Traces | Stable |
| Metrics | Stable |
| Logs | Stable (GA since 2025) |
| Profiles | Data model stable, SDK implementation in progress |
OpenTelemetry Support per Language
| Language | Traces | Metrics | Logs | Overall Maturity |
|---|---|---|---|---|
| Java | Stable | Stable | Stable | Highest — richest auto-instrumentation |
| .NET | Stable | Stable | Stable | Very high — zero-code instrumentation |
| Python | Stable | Stable | Development | High — broad auto-instrumentation |
| Go | Stable | Stable | Beta | High — native SDK |
| JavaScript/Node.js | Stable | Stable | Development | High — zero-code instrumentation available |
| C++ | Stable | Stable | Stable | High |
| PHP | Stable | Stable | Stable | High — zero-code instrumentation available |
| Rust | Beta | Beta | Beta | Growing |
| Ruby | Stable | Development | Development | Medium |
| Erlang/Elixir | Stable | Development | Development | Lower |
| Swift (iOS) | Stable | Development | Development | In development |
| Kotlin (Android) | Development | Development | Development | In development |
Source: OpenTelemetry Language APIs & SDKs — updated April 2026