Based on Zipkin Distributed Link Tracking System pre-research first article

The Distributed Service tracking system originated from Google's paper "Dapper, a large-scale distributed systems tracing Infrastructure" (for reference here), Twitter's Zipkin is based on an earlier Distributed Link tracking system, and since open source is rapidly being researched by communities, many versions have been created.
Here is also a study of the Zipkin, first posted on the Twitter zipkin structure diagram.

The structure is relatively simple, the approximate process is:

1. Trace data is collected to Scribe (Facebook open Source Log transfer path) or Kafka (Apache distributed messaging System).
2. The data in the Scribe/kafaka is stored in the database by the controller.
3. Finally, the UI and query queries are displayed.

Here will mention a log analysis system elk, it is a collection of log collection, log analysis query in one. The system is mainly divided into: collection (Logstash), Storage (Elasticsearch), display (Kibana) Three parts, currently we are used to do distributed service log system.

In this thought altogether elk has helped us to collect the log of distributed services and unified storage, why the link tracking system can not directly use these logs to do the query display it?

So from this point of view, I would like to make a composition of the structure of the scheme. First put out my drawing of the structure (ugly, will see it):

Start the deployment environment for this structure, and the environment is deployed next time.

The current division develops distributed service architectures and discusses distributed Link tracking systems. So in this study of Distributed Link Tracking system, and write notes as a learning motivation. All of the notes are personal, and there may be errors, I hope you can point out.

Based on Zipkin Distributed Link Tracking System pre-research first article