// the find
openzipkin/zipkin
Zipkin is a distributed tracing system
Zipkin is Twitter's original distributed tracing system, now an OpenZipkin community project. It collects span timing data from instrumented services, stores it in a pluggable backend, and lets you look up traces by ID or query by service/operation/tag. Aimed at teams debugging latency in microservice architectures who want a self-hosted solution they can wire into existing message brokers.
The core library is only 155k and avoids pulling in gson as a transitive dependency by minifying and repackaging the bits it uses — rare discipline in the Java ecosystem. The collector abstraction is genuinely flexible: HTTP, Kafka, RabbitMQ, ActiveMQ, and Pulsar all work as ingestion transports with no changes to the storage layer. Storage backends are properly abstracted behind StorageComponent, so swapping Cassandra for Elasticsearch is a config change, not a code change. The JUnit 5 extension (zipkin-junit5) makes it straightforward to write integration tests that actually send spans to a real Zipkin instance rather than mocking everything out.
Dependency graph aggregation requires a separate Spark job (zipkin-dependencies) for both Cassandra and Elasticsearch backends — you don't get that view just by running Zipkin, which is a real operational surprise for new adopters. MySQL storage is documented as having known performance problems at any real scale; it exists for onboarding, not production, but that distinction isn't prominent enough. OpenTelemetry has won the instrumentation war and W3C TraceContext is replacing B3 propagation — teams starting today will likely end up with OTel Collector feeding Grafana Tempo or Jaeger instead, and Zipkin's long-term relevance is tied to how well it accepts OTLP, which remains a community plugin rather than a first-class transport. The UI hasn't kept pace: no flamegraph view, limited filtering, and nothing like Jaeger's service performance monitoring pages.