Mengekspor Jejak ke Zipkin

Creating spans is not enough - they must be exported to a backend that stores and visualizes them. Zipkin is a popular, easy-to-run choice.

The simplest way to run Zipkin locally is its Docker image. It exposes a UI and an ingest API on port 9411.

Add the reporter dependency so finished spans are sent to Zipkin.

Tell Spring where Zipkin lives. The default endpoint is the local Zipkin ingest URL.

Combine the exporter with a sampling probability. In development you often sample 100% to see every trace.

Spans are grouped by service. Zipkin uses spring.application.name as the service name, so set it meaningfully on each app.

Each service buffers finished spans and reports them to Zipkin asynchronously (over HTTP by default). Zipkin joins spans sharing a traceId into one trace.

In the Zipkin UI you search by service, span name, tag or duration, then open a trace to see the waterfall of spans across all services.

Zipkin can render a service dependency diagram from collected traces, showing which services call which - a live map of your architecture.

The same Micrometer setup can export elsewhere. With the OpenTelemetry bridge you can send to OTLP-compatible backends (Tempo, Jaeger, vendors) instead of Zipkin.

In production, lower the sampling rate, secure the Zipkin endpoint, and ensure the reporter's async queue does not drop too many spans under load. Tracing should never harm request latency.

Confirm your exporter knowledge.

You exported traces to Zipkin:

• Run Zipkin (port 9411) and add the Zipkin reporter
• Set the endpoint and a sampling probability
• spring.application.name is the Zipkin service name
• Explore waterfalls and the service dependency graph in the UI