Short answer
Jaeger is a tracing backend: a server that receives spans, stores them, and serves a UI for waterfall and dependency graph views. OpenTelemetry is the standard for emitting telemetry from applications. The Jaeger client libraries are deprecated; the official path is to instrument with OpenTelemetry and send to either Jaeger (which accepts OTLP) or any other OTLP-compatible backend.
A short history
Jaeger started at Uber in 2015 as a Zipkin-compatible tracing system. It became a CNCF project and shipped client SDKs for Go, Java, Python, Node, C++. In 2019 the OpenTracing and OpenCensus projects merged into OpenTelemetry, and Jaeger's maintainers contributed heavily to that effort. By 2022 the Jaeger clients were officially deprecated in favor of OpenTelemetry SDKs, and Jaeger 1.35+ started accepting OTLP directly.
So "OpenTelemetry vs Jaeger" today is really "OpenTelemetry SDK vs the deprecated Jaeger client SDK," and "OTLP vs the old Jaeger Thrift protocol." For new work the answer is OpenTelemetry on both axes.
Scope
Jaeger handles traces. It does not collect logs or metrics — that is by design. OpenTelemetry covers all three signal types. If you want logs and metrics next to your traces in one query surface, you need either a backend like Telemtra that handles all three, or a multi-product stack (Jaeger + Loki + Prometheus) tied together at the UI layer.
Protocols
Old Jaeger pipelines used Thrift over UDP or gRPC. OpenTelemetry uses OTLP over HTTP/protobuf or gRPC. The OpenTelemetry Collector has a jaeger receiver that accepts Jaeger Thrift and a jaeger exporter that emits it — so you can bridge legacy Jaeger clients into an OTel pipeline without rewriting them yet:
receivers:
jaeger:
protocols:
thrift_http:
endpoint: 0.0.0.0:14268
grpc:
endpoint: 0.0.0.0:14250
exporters:
otlphttp/telemtra:
endpoint: https://ingest.telemtra.io
headers:
x-api-key: ${env:TELEMTRA_API_KEY}
service:
pipelines:
traces:
receivers: [jaeger]
exporters: [otlphttp/telemtra]That single Collector lets a service that still uses the legacy Jaeger client emit traces into Telemtra alongside services that emit OTLP natively.
Migration path from Jaeger client SDKs to OpenTelemetry
- Add the OpenTelemetry SDK to one service alongside the Jaeger client.
- Configure both exporters to send to the same backend (or to a Collector that converts).
- Verify traces appear and look correct in the backend UI.
- Remove the Jaeger client and its dependencies.
- Repeat per service.
Trace context propagation will keep working because both Jaeger and OpenTelemetry libraries can be configured to use the W3C tracecontext propagator. Make that the default propagator before you mix SDKs.
Where Telemtra fits
Telemtra is OTLP-native. It accepts traces from OpenTelemetry SDKs directly, or from legacy Jaeger clients through a Collector with the jaeger receiver. The trace waterfall, latency percentiles, and Service Map in Telemtra do not care which client emitted the spans, as long as they reach the OTLP endpoint.
The advantage over running Jaeger yourself is the rest of the surface: logs and metrics in the same workspace, alerts on trace percentile latency, ingest-time Data Shaper rules, and workspace controls without operating Cassandra or Elasticsearch backends.
How to choose today
- For instrumentation: always OpenTelemetry. The Jaeger clients are deprecated.
- For a tracing backend: run Jaeger if you specifically want to operate the open-source backend yourself and only need traces. Use Telemtra (or another OTLP-native backend) if you also want logs, metrics, dashboards, alerts, and service maps in the same place.
- For migrations: route legacy Jaeger traffic through a Collector. The bridge is well-supported.
See What is OTLP? and the Collector quickstart. Start a free Telemtra workspace to receive Jaeger or OTLP traces in minutes.