they touch different parts of your architecture. Requests have a unique trace ID, which you can use to lookup a trace diagram, or log entries related to it. Causal diagrams are easier to understand than scrolling through logs.
contextualizing errors and delays - Visualize latency like time in my service vs waiting for other services - Understand complex applications like async code or microservices - See your architecture with live dependency diagrams built from traces
utility library, similar to metrics or logging libraries. It is a mechanism uses to trace an operation. Instrumentation is framework-specific code that uses a tracer to collect details such as the http url and request timing. Instrumentation must be configured and pointed to a tracing system for tracing to work. This is often done automatically with agents or frameworks like Spring Boot.
champions Zipkin as a part of additional roles in their company. Many site owners are part time, yet contribute back to open source. Zipkin site: Production deployment of distributed tracing, which considers Zipkin format, instrumentation or backends strategic to their observability function. For example, some sites use tools like zipkin-php or zipkin-go to collect data, but export it to Google Stackdriver for analysis and visualization. Others use our data format in their tracing pipeline which gathers data from Zipkin tools, alternative or legacy internal ones. Some use Zipkin backends, but other agent technology, such as SkyWalking to gather it. By sharing real life setups, you can ideally understand the different approaches that coexist to solve the problem of tracing.
of the company context and team on tracing * System overview from application until visualization/analysis * Site-specific data conventions such as services are named * Why tracing is important, goals and service level agreements * Status like costs adoption, ingestion and costs incurred System Overview instrumentation - approach, platforms supported data ingestion - formats, data pipeline, sampling data store and aggregation - data at rest, retention, indexing, cleansing realtime and batch analysis - techniques, visualizations, UI, tooling Site-specific data conventions service name - what is the source of your Zipkin service name? does it come from discovery? Is it used in other tools like metrics? site-specific tags - which tags do you rely on for search or aggregation? For example, do you add correlation or environment IDs to spans? Which are fixed cardinality? Goals What near, middle and long term milestones exist? What value are the business looking to receive? What improvements are you looking to further? What other projects relate to your tracing goals?
before and after refactoring the services. Identify non-conformant service communications that deviates from the design. Hotels.com says: helps in pointing out the worst offenders and by making it easier to identify performance improvements such as network calls that could be done in parallel. Netflix says: The business value is in providing operational visibility into the systems and enhance developer productivity. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95651348 https://cwiki.apache.org/confluence/display/ZIPKIN/Hotels.com https://cwiki.apache.org/confluence/display/ZIPKIN/Netflix
is the canonical backend which receives Zipkin format, and presents a UI. Some don’t run Zipkin server, or also run other products for various reasons. * SaaS preference * APM integration * Hybrid setup * SaaS preference: Ex. Infostellar use Google Stackdriver * APM integration: Ex. hotels.com use a centralised Expedia Haystack which also adds anomaly detection * Pipeline setup: Ex. yelp have “firehose” collectors which forward to a zipkin server
and trace formats which decouple sites from a mandate of using our code. By producing the same data, applications have more flexibility and choice. * 3rd party libraries * Proxies (service mesh) integration * In-house custom tools * 3rd party libraries - ex OpenCensus and some OpenTracing libraries * Proxies (service mesh) integration - ex linkerd and envoy do not use zipkin libraries for tracing, but they emit our formats * In-house custom tools - ex utilities not yet open sourced or are too bespoke.
Hotels.com started with a Zipkin backend, but are transitioning to Expedia Haystack, which provides more features like adaptive alerting. https://github.com/ExpediaDotCom/haystack Applications still emit data in Zipkin v2 format, which is forwarded to Haystack with a tool they created called Pitchfork. Developers still use Zipkin on their laptops for local troubleshooting, as it is easy to run. Hotels.com is part of the Expedia Group and is a website for booking hotel rooms online. It's tracing team operates from London. https://cwiki.apache.org/confluence/display/ZIPKIN/Hotels.com
server Netflix created a Dapper-based tracing system to trace RPC calls involved in video streaming. This included framework libraries to produce trace headers and data. As Spring Boot became prevalent, Zipkin became more useful as it is built-into the tracing library Spring Cloud Sleuth. Netflix convert legacy spans into Zipkin v2 format in their Kafka/Flink pipeline. This allows traces to stitch together for query and analysis. Netflix is a video streaming service. Its tracing team operates from the Silicon Valley. https://cwiki.apache.org/confluence/display/ZIPKIN/Netflix
Infostellar architecture runs in Google Cloud, except ground station software that runs locally at an antennae site. Many components trace with Zipkin libraries, some with OpenTracing, some homegrown. All use Zipkin’s B3 format for propagation. Even when using Zipkin libraries, data sends directly to Google Stackdriver for query and analysis. There’s no Zipkin server footprint at Infostellar. Infostellar (StellarStation) - is a space communications infrastructure firm. Its tracing team operates from Tokyo. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95655004
Medidata is an entirely AWS architecture, using the zipkin-aws image will allows http and SQS span collection. They collect 100% data into AWS-managed Elasticsearch storage. While the zipkin service is standard, Medidata has a service that reads trace data from Elasticsearch, comparing it with performance objectives in APIs and issuing alerts when performance degrades. Medidata is the largest provider of software for clinical trials. https://cwiki.apache.org/confluence/display/ZIPKIN/Medidata
always provision request IDs. Infostellar use antenna, satellite and plan tags for business context. LINE add company- specific tags like phase and instance ID. Expedia Haystack scrubs secrets. Data retention policy: Medidata retain 100% for 100 days. Netflix sample 100% of FIT experiments, 0.1% otherwise. SoundCloud retain a very low sample rate for 7 days. Tracing adoption rate: LINE is only one team’s services, Ascend <50%, Tyro is over 90%
at a proxy can raise visibility of upstream and downstream. Typeform initialise a trace and request ID in their custom proxy. Single service: hotels.com recognised even though tracing is a team sport, starting with a single service can still add value. New Framework: Sites like Ascend rolled out tracing in new applications as it was out-of-box supported with Spring Boot (via Spring Cloud Sleuth). Green Field: Infostellar engineers had previous experience with tracing, and built their platform with tracing in mind. https://cwiki.apache.org/confluence/display/ZIPKIN/Hotels.com https://cwiki.apache.org/confluence/display/ZIPKIN/Typeform