In the previous three parts of our OpenTracing series, we provided an Overview of OpenTracing, explaining what OpenTracing is and does, how it works and what it aims to achieve, we looked at Zipkin – a popular open-source distributed tracer and then at Jaeger – a newer open-source distributed tracer developed under the CNCF umbrella. In this blog post – the last part of the OpenTracing series – we will compare Jaeger vs. Zipkin side by side!
Prefer PDFs? Get the whole OpenTracing series as PDF: free OpenTracing eBook. Alternatively, follow @sematext if you are into observability in general.
Distributed tracers: how to debug through a complex workflow
As organizations embrace the cloud-native movement and migrate their applications from monolithic to microservice architectures, need for general visibility and observability into software behavior becomes an essential requirement. Since monolithic code base is segregated into multiple independent services running inside their own processes, which in addition can scale to various instances, diagnosing latency of an HTTP request issued from the client can end up being a serious deal rather than a trivial task.
Looking for an APM solution supporting fully distributed applications and distributed transaction tracing? Check Sematext Tracing!
Get end-to-end visibility into your distributed applications so you can find bottlenecks quickly, resolve production issues faster and with less effort. Spot performance bottlenecks, identify hotspots, find root cause of latency problems. Plus, Sematext Tracing is integrated with Log Management, Infrastructure and Real User Monitoring.
In order to fulfill the request, it has to propagate through load balancers, routers, gateways, cross machine’s boundaries used to communicate with other microservices, send asynchronous messages to message brokers, etc. Along this pipeline, there could be a possible bottleneck, contention or communication issue in any of the aforementioned components.
Debugging through such a complex workflow wouldn’t be feasible if not relying on some kind of tracing/instrumentation mechanism, and thus the reason why distributed tracers like Zipkin, Jaeger or AppDash were born (most of them are inspired on Google’s Dapper large-scale distributed tracing platform). All of the previously mentioned tracers help engineers and operation teams understand system behavior as complexity of the infrastructure grows exponentially.
Tracers expose the source of truth for interactions originated within the system. Every transaction, if properly instrumented, might reflect performance anomalies in an early phase when new services are being introduced by (probably) independent teams with polyglot software stacks and continuous deployments.
However, each of the tracers stick with its proprietary API and other peculiarities that makes it costly for developers to switch between different tracer implementations. Since implanting instrumentation points requires code modification, OSS services, application frameworks and other platforms would have hard time tying them to a single tracer vendor.
“Tracers expose the source of truth for interactions originated within the system. Every transaction, if properly instrumented, might reflect performance anomalies early.”
Jaeger vs Zipkin: comparison matrix
Jaeger vs Zipkin or Zipkin vs Jaeger?
The following is a comparison matrix between the two tracing systems. As seen on the table below, Jaeger has better OpenTracing support and more diversity of OpenTracing-compatible clients for different programming languages. This is due to Jaeger decision to adhere to the OpenTracing initiative from inception.
| JAEGER | ZIPKIN | |
| OpenTracing compatibility | Yes | Yes |
| OpenTracing-compatible clients | Ruby * PHP * Rust * | Ruby * Python (work in progress) |
| Storage support | In-memory Cassandra Elasticsearch ScyllaDB (work in progress) | In-memory MySQL Cassandra Elasticsearch |
| Sampling | Dynamic sampling rate (supports rate limiting and probabilistic sampling strategies) | Fixed sampling rate (supports probabilistic sampling strategy) |
| Span transport | UDP HTTP | HTTP Kafka Scribe AMQP |
| Docker ready | Yes | Yes |
* non-official OpenTracing clients
“Despite Zipkin being around for a while longer and being more mature, Jaeger has seen some good adoption thanks to several factors, such as good language coverage of OpenTracing-compatible clients, low memory footprint, and a modern, scalable design.”
OpenTracing: Supported instrumentation
Many frameworks and libraries ship with native OpenTracing instrumentation support or have extension points that add tracing capabilities.
- https://github.com/rnburn/nginx-opentracing/tree/opentracing-api – Instrument nginx requests via OpenTracing compatible tracing.
- https://github.com/opentracing-contrib – A collection of libraries that add OpenTracing instrumentation for Spring, Spring-Cloud, JDBC, JMS, Kafka and Mongo clients, Python, Ruby, and many other frameworks.
- https://github.com/uber-common/opentracing-python-instrumentation – Instrumenting popular Python frameworks / clients
Other tracers compatible with OpenTracing
- Tracer – designed after Dapper, not production ready.
- Lightstep – cloud-based commercial tracing instrumentation platform.
- AppDash – based on Zipkin and Dapper. Limited clients availability (Go, Python and Ruby).
- Instana – commercial product. Focused on APM and distributed tracing.
Free OpenTracing eBook
Want to get useful how-to instructions, copy-paste code for tracer registration? We’ve prepared an OpenTracing eBook which puts all key OpenTracing information at your fingertips: from introducing OpenTracing, explaining what it is and does, how it works, to covering Zipkin followed by Jaeger, both being popular distributed tracers, and finally, compare Jaeger vs. Zipkin. Download yours.
Conclusion
In the era where software complexity is increasingly overwhelming, containers have brought on additional layer of complexity with their highly dynamic and ephemeral nature. In such environments, where deployments are pushed to production on a daily basis, it is crucial to have full operational visibility of the complete infrastructure stack.
In this blog post series, we’ve described the importance and benefits of tracing, one of the core pillars of modern application observability in the context of OpenTracing. We also explored how distributed tracers such as Zipkin or Jaeger collect and store traces while revealing inefficient portions of our applications.
Finally, we compared Jaeger and Zipkin. Despite Zipkin being around for a while longer and being more mature, Jaeger has seen some good adoption thanks to several factors, such as good language coverage of OpenTracing-compatible clients, low memory footprint, and a modern, scalable design.