青年IT男

个人从事金融行业,就职过易极付、思建科技、某网约车平台等重庆一流技术团队,目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。微信公众号:青年IT男。

zipkin分布式链路监控

zipkin分布式链路监控

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.

This project includes a dependency-free library and a spring-boot server. Storage options include in-memory, JDBC (mysql), Cassandra, and Elasticsearch.

Quick-start

The quickest way to get started is to fetch the latest released server as a self-contained executable jar. Note that the Zipkin server requires minimum JRE 8. For example:

You can also start Zipkin via Docker.

Once the server is running, you can view traces with the Zipkin UI at http://your_host:9411/zipkin/.

If your applications aren’t sending traces, yet, configure them with Zipkin instrumentation or try one of our examples.

Check out the zipkin-server documentation for configuration details, or docker-zipkin for how to use docker-compose.

Core Library

The core library is used by both Zipkin instrumentation and the Zipkin server. Its minimum Java language level is 6, in efforts to support those writing agent instrumentation.

This includes built-in codec for Zipkin’s v1 and v2 json formats. A direct dependency on gson (json library) is avoided by minifying and repackaging classes used. The result is a 155k jar which won’t conflict with any library you use.

Ex.

Note: The above is just an example, most likely you’ll want to use an existing tracing library like Brave

Storage Component

Zipkin includes a StorageComponent, used to store and query spans and dependency links. This is used by the server and those making custom servers, collectors, or span reporters. For this reason, storage components have minimal dependencies, but most require Java 8+

Ex.

In-Memory

The InMemoryStorage component is packaged in zipkin’s core library. It is neither persistent, nor viable for realistic work loads. Its purpose is for testing, for example starting a server on your laptop without any database needed.

Cassandra

The Cassandra component is tested against Cassandra 3.11.3+. It stores spans using UDTs, such that they appear like the v2 Zipkin model in cqlsh. It is designed for scale. For example, it uses a combination of SASI and manually implemented indexes to make querying larger data more performant.

Note: This store requires a spark job to aggregate dependency links.

Elasticsearch

The Elasticsearch component is tested against Elasticsearch 2-6.x. It stores spans as json and has been designed for larger scale.

Note: This store requires a spark job to aggregate dependency links.

Disabling search

Search is enabled by default, primarily in support of the GET /tracesGET /spans and GET /services endpoints used by the “Find a Trace” screen in Zipkin’s UI. When search is disabled, traces can only be retrieved by ID.

Sites who use another service (such as logs) to find trace IDs can disable search to reduce storage costs or increase write throughput.

StorageComponent.Builder.searchEnabled(false) is implied when a zipkin is run with the env variable SEARCH_ENABLED=false.

Legacy (v1) components

The following components are no longer encouraged, but exist to help aid transition to supported ones. These are indicated as “v1” as they use data layouts based on Zipkin’s V1 Thrift model, as opposed to the simpler v2 data model currently used.

MySQL

The MySQL v1 component currently is only tested with MySQL 5.6-7. It is designed to be easy to understand, and get started with. For example, it deconstructs spans into columns, so you can perform ad-hoc queries using SQL. However, this component has known performance issues: queries will eventually take seconds to return if you put a lot of data into it.

Cassandra

The Cassandra v1 component is tested against Cassandra 2.2+. It stores spans as opaque thrifts which means you can’t read them in cqlsh. However, it is designed for scale. For example, it has manually implemented indexes to make querying larger data more performant. This store requires a spark job to aggregate dependency links.

Running the server from source

The Zipkin server receives spans via HTTP POST and respond to queries from its UI. It can also run collectors, such as RabbitMQ or Kafka.

To run the server from the currently checked out source, enter the following. JDK 8 is required.

Artifacts

Library Releases

Releases are uploaded to Bintray.

Library Snapshots

Snapshots are uploaded to JFrog after commits to master.

Docker Images

Released versions of zipkin-server are published to Docker Hub as openzipkin/zipkin. See docker-zipkin for details.

Javadocs

http://zipkin.io/zipkin contains versioned folders with JavaDocs published on each (non-PR) build, as well as releases.

Git地址:https://github.com/openzipkin/zipkin.git

0
青年IT男

个人从事金融行业,就职过易极付、思建科技等重庆一流技术团队,目前就职于某网约车平台负责整个支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。

You must be logged in to post a comment

This site is protected by wp-copyrightpro.com