Server extensions and choices
Server extensions
Zipkin server bundles extension for span collection and storage. By default spans can be collected over http, Kafka or RabbitMQ transports and stored in-memory or in MySQL, Cassandra or Elasticsearch.
The following modules add storage or transport extensions to the default server build.Please refer to their individual documentation for setup and configuration guides.
OpenZipkin supported
The following extensions are supported by the OpenZipkin team and are hosted atthe OpenZipkin GitHub group. You can reach out tothe team on Zipkin Gitter chat.
Type | Module | Related product | Other notes |
---|---|---|---|
Collector | zipkin-aws collector-sqs | AWS SQS | |
Collector | zipkin-aws collector-kinesis | AWS Kinesis | |
Storage | zipkin-aws storage-elasticsearch-aws | AWS Elasticsearch Service | |
Storage | zipkin-aws storage-xray | AWS X-Ray | only supports sending to an XRay UDP daemon |
Storage | zipkin-gcp storage-stackdriver | GCP Stackdriver | only supports sending to an Stackdriver |
Community supported
Type | Module | Related product | Other notes |
---|---|---|---|
Storage | zipkin-logzio | Logz.io | Supports both sending and reading back data to and from Logz.io: Secure & Scalable Log Management with Cloud-Based ELK |
Storage | zipkin-scouter storage-scouter | Scouter APM | only supports sending to an Scouter |
Storage | zipkin-storage-kafka | Apache kafka | Supports aggregation and indexing of tracing data via Kafka Streams State Store. |
Reporter | spring-cloud-sleuth-haystack-reporter | Haystack | Supports sending data to Haystack, a resilient, scalable tracing and analysis system. |
Alternative servers
The OpenZipkin team publish apis, data formats, and shared libraries that allow alternate backends to process thesame data sent to the default Zipkin server.
Community supported
Listed below are alternative backends that accept Zipkin format. Some use the same code as Zipkin on the same endpoints while others are on alternative endpoints or partially support features. In any case, the following aim to allow existing zipkin clients to use backends the OpenZipkin team does not support. Hence, direct questions to their respective communities.
- Apache SkyWalking
- When zipkin-receiver is enabled, Skywalking exposes the same HTTP POST endpoints Zipkin does
- http port 9411 accepts
/api/v1/spans
(thrift, json) and/api/v2/spans
(json, proto) POST requests. - this extension uses the same encoding library and same endpoints as Zipkin does.
- http port 9411 accepts
- When zipkin-receiver is enabled, Skywalking exposes the same HTTP POST endpoints Zipkin does
- Jaeger
- When
COLLECTOR_ZIPKIN_HTTP_PORT=9411
is set, Jaeger exposes a partial implementation of Zipkin’s HTTP POST endpoints- http port 9411 accepts
/api/v1/spans
(thrift, json) and/api/v2/spans
(json, proto) POST requests.
- http port 9411 accepts
- When
SPAN_STORAGE_TYPE=kafka
andzipkin-thrift
, Jaeger reads Zipkin v1 thrift encoded span messages from a Kafka topic.- Note: The above is a deprecated practice in Zipkin. Most instrumentation bundle multiple spans per message in v2 format.
- When
- Pitchfork
- Pitchfork exposes the same HTTP POST endpoints Zipkin does
- http port 9411 accepts
/api/v1/spans
(thrift, json) and/api/v2/spans
(json, proto) POST requests.
- http port 9411 accepts
- Pitchfork exposes the same HTTP POST endpoints Zipkin does
Did we miss a server extension or alternative? Please open a pull-request toopenzipkin.github.io.