Google Cloud Platform has released an open source Zipkin server that allows Zipkin-compatible clients to send traces to Google’s own Stackdriver Trace distributed tracing service for analysis. This Zipkin/Stackdriver Trace integration is aimed at developers whose applications and services are written in a language or framework that Stackdriver Trace doesn’t officially support, and owners of applications that are currently instrumented with Zipkin who want access to Stackdriver Trace’s advanced analysis tools.
Google Stackdriver is a monitoring, logging and diagnostic service for applications on cloud platforms. Although data captured from any cloud platform can be sent to the Stackdriver API, Stackdriver functionality is highly integrated with many services within Google Cloud Platform (GCP) (and can be used for free by GCP customers). Google Stackdriver consists of several tools, and includes Stackdriver Trace, a distributed tracing service that has evolved from the original Google Dapper distributed tracing system.
Stackdriver Trace allows developers to track the flow of a request through an instrumented distributed (microservice) system, and analyse application latency and isolate performance bottlenecks. Stackdriver Trace was initially focused on Google App Engine projects, but currently supports applications running on virtual machines or containers via instrumentation libraries for Node.js, Java, and Go (Ruby and .Net support will be available soon), and also through an API.
Another popular distributed tracing system is Zipkin, which was initially created by Twitter, and used the Dapper paper for inspiration. The work was open-sourced in 2012, and has subsequently evolved into the community-driven Open Zipkin project. This in turn has led to the formation of the Open Tracing API, a CNCF-backed project. Zipkin provides a range of instrumentation libraries for capturing traces from applications, as well as a backend system for storing and presenting traces through a web interface. There are currently Zipkin clients available for Java, .Net, Node.js, Python, Ruby and Go, with built-in integration to a variety of popular web frameworks. According the GCP blog, Zipkin is widely used, and Twitter, Yelp and Salesforce are major contributors to the project
The Google Cloud Platform blog states that the new Stackdriver Trace Zipkin Connector is a drop-in replacement for an existing Zipkin backend and continues to use the same Zipkin-compatible tracers; there is no longer a requirement to configure, manage or maintain a Zipkin backend. Alternatively, the new collector can be run alongside each service that's instrumented with Zipkin tracers.
This current Stackdriver-Zipkin v0.2.0 release has several known limitations:
- Zipkin tracers must support the correct Zipkin time and duration semantics.
- Zipkin tracers and the Stackdriver Trace instrumentation libraries can’t append spans to the same traces, as they both use different formats for propagating trace context between services. This means that traces that are captured in one library won’t contain spans for services instrumented in the other type of library i.e. traces passing over service code instrumented with a mix of Stackdriver Trace and Zipkin will have to be integrated outside of standard Stackdriver reporting.
- The initial release only supports write operations on the Zipkin server. However, the Google Cloud Platform blog states that developers can raise an issue or pullrequest via GitHub if the absense of read functionality is a blocker.
The Google Stackdriver Trace Zipkin Collector code can be downloaded from the GoogleCloudPlatform GitHub repository. Instructions for configuring and collecting trace data from a distributed tracer can be found in the ‘Using Stackdriver Trace with Zipkin' guide.
