Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track systems who accept Zipkin trace format #65

Open
codefromthecrypt opened this issue Dec 9, 2016 · 2 comments
Open

Track systems who accept Zipkin trace format #65

codefromthecrypt opened this issue Dec 9, 2016 · 2 comments

Comments

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Dec 9, 2016

Zipkin's interop story is half-told by instrumentation. For example, we track which instrumentation can send zipkin formatted traces and/or use B3 propagation. I continue to hear people say there's no interoperable tracing systems, so I think it would be valuable to catalog system compatibility.

For example, we can mention directly the systems which..

  • expose zipkin's full api, just not using zipkin's codebase (ex hawkular)
  • expose zipkin's http collector endpoint, but not readback (ex stackdriver trace)
  • accept zipkin trace format via other means (ex jaeger's internal collector)
  • have means to export their trace format to zipkin (ex htrace converter)

Some times, this list changes.. for example, a system could gain traction by accepting zipkin then later switch to exclusively their own format. For that reason, this list would need to be maintained so that it doesn't mislead folks. I think that maintenance would be worthwhile as it debunks the myth that there's no interop story in tracing except by sharing libraries.

Here's a list of public work I'm aware of

Zipkin specs used for system interop

zipkin-api - some aren't aware that we publish our data format and OpenApi definition
b3-propagation - while usually doesn't affect out-of-band data, and B3 isn't required by zipkin, the de-facto propagation format is relevant (particularly aspects like debug)

Converters that allow applications to send in Zipkin format.

Apache HTrace - HTrace is a different tracing system than zipkin, notably supporting data flow operations with multiple parents. There's a library and reporting plugin to convert HTrace -> Zipkin format
Nike Wingtips - Wingtips is a log-centric different tracing system used at Uber. There's a library and reporting plugin to convert Wingtips -> Zipkin
Uber Jaeger - Jaeger was internally designed at Uber and has a different data format than Zipkin. It is in the process of being open sourced. Currently, Jaeger's oss clients report spans in Zipkin's thrift format, some directly to Zipkin.

Other tracing systems that present Zipkin http Endpoints

Apache Phoenix Zipkin Api - Phoenix has its own tracing depot, but it has an adapter which exposes the http api of zipkin for the purpose of re-using its UI.
Tracer - Tracer is a ground up system written in go. It has a different format than Zipkin, but it has an adapter which exposes the http api of zipkin for the purpose of re-using its UI.
Google Stackdriver Trace Connector - Google Stackdriver Trace is a different tracing system than zipkin, and there's a connector that pushes Zipkin traces into StackDriver. This allows reuse of Zipkin compatible instrumentation.
Hawkular APM - Hawkular is a different tracing system than zipkin, but it exposes an Http collector that consumes Zipkin traces. This allows reuse of Zipkin compatible instrumentation.

Zipkin http server ports

zipkin-query-go - port of zipkin (including the same mysql schema), written in golang.
zipkin riposte - high performance zipkin http server using Nike Riposte
zipkin armeria - high performance zipkin http server using Line Armeria
http4s - pure scala port of the zipkin http api

@codefromthecrypt
Copy link
Member Author

cc @openzipkin/core @openzipkin/instrumentation-owners

@codefromthecrypt
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant