openzipkin/zipkin

Zipkin is a distributed tracing system. In plain terms, when a single user action in a modern application is actually handled by several services talking to each other over the network, it can be hard to figure out where a delay or failure happened. Zipkin collects the timing information from each step and lets you look it up afterwards, so you can troubleshoot latency problems in that kind of service architecture. The way it works has two halves. Each application has to be instrumented, meaning it uses a tracing library to report data to Zipkin about the work it does. The most common ways to ship that data are HTTP and Kafka, with other transports like Apache ActiveMQ, gRPC, RabbitMQ, and Apache Pulsar also supported. On the receiving side, the Zipkin server stores the spans and serves a web UI on port 9411 where you can paste a trace ID from a log to jump straight to it, or query by service, operation name, tags, or duration. The UI also shows a dependency diagram of how traced requests flow between applications. Storage can be in-memory for development, or persistent through Apache Cassandra or Elasticsearch for real workloads. A smaller slim build is available that keeps in-memory and Elasticsearch storage but drops messaging transports. Someone would use this when they run a multi-service system and need to see where requests are spending their time. The quickest setup, per the README, is to download a single self-contained executable jar and run it, or launch the openzipkin/zipkin Docker image. The stack is Java, the server requires JRE 17 or higher, while the core library targets Java 8. The full README is longer than what was provided.