OpenTelemetry Observability
Term 58 of 68 in the ERPStack technical glossary
What is OpenTelemetry Observability?
OpenTelemetry (OTel) is an open-source observability framework for collecting, processing, and exporting telemetry data — traces, metrics, and logs — from distributed applications into monitoring backends like Grafana, Datadog, or Jaeger.
OpenTelemetry Observability at a glance
- Signals
- 3: traces, metrics and logs, emitted through 1 vendor-neutral instrumentation API
- Trace model
- 1 trace identifier propagated across every hop, so a request is reconstructable end to end
- Portability
- Instrument once, change backend later — the code does not know which vendor receives the data
- Cost control
- Sampling, because retaining 100% of traces at volume costs more than the insight is worth
- Built with
- OpenTelemetry instrumentation in Next.js 16 and TypeScript 5.9 services on Docker and Kubernetes, spans covering PostgreSQL 18 queries, Redis calls and Apache Kafka hops, joined to Sentry
- Numbers that matter
- 3 signals; 1 trace identifier across every hop; keep 100% of errors and sample the rest; 6 services in 1 request is common
- Compare with
- Vendor-specific agents, or Sentry alone for exception grouping
- Commonly paired with
- Sentry error grouping, Docker and Kubernetes workloads, Apache Kafka consumers, Next.js 16 server code, Redis calls and PostgreSQL 18 queries
How OpenTelemetry Observability works in production
The ERPStack approach to OpenTelemetry Observability
We instrument all production ERP deployments with OpenTelemetry, exporting traces to Grafana Tempo and metrics to Prometheus for real-time SLA monitoring and database query optimization.
Frequently asked questions about OpenTelemetry Observability
What does OpenTelemetry Observability standardise?
How software emits telemetry, independent of who stores it. OpenTelemetry Observability defines APIs and wire formats for 3 signals — traces, metrics and logs — so instrumentation is written once and the backend becomes a configuration choice. That breaks the pattern where changing monitoring vendors meant re-instrumenting an entire codebase, which is why vendor-specific agents were so sticky.
Why are traces more useful than logs in distributed systems?
Because they preserve causality. A log line records that something happened; a trace records that this request caused this database call which caused that timeout. OpenTelemetry Observability propagates 1 trace identifier through every hop, so a slow request can be attributed to a specific span rather than inferred by correlating timestamps across several machines by hand.
How much telemetry should you keep?
Less than you emit. OpenTelemetry Observability at volume produces data that costs real money to retain, so sampling is a design decision: keep a small percentage of successful traces and, ideally, 100% of errors and slow requests, which are the ones anyone will look at. Deciding this deliberately is better than discovering it through an invoice.
Does this replace an error tracker like Sentry?
No — they answer different questions. OpenTelemetry Observability shows where time went across a distributed request; an error tracker groups exceptions, attaches stack traces and release context, and tells you which deploy introduced a fault. Most teams run both, and the integration point is a shared trace identifier so an exception can be opened directly from the trace that produced it.