java apm工具
APM工具對比
市面上有很多分散式鏈路監控的工具，客觀對比。
調研
市面上的APM（Application Performance Management）理論模型大多都是借鑑，Google Dapper論文。
我最近也在選取使用哪一個工具，這裡的對比是在Spring Cloud 中的使用。
對比三種工具：
- zipkin：Twitter公司開源的一個分散式追蹤工具，被Spring Cloud Sleuth整合，使用廣泛而穩定
- skywalking：中國人吳晟（華為）開源的一款分散式追蹤，分析，告警的工具，現在是Apache旗下開源專案
- cat：大眾點評開源的一款分散式鏈路追蹤工具。
整體架構
zipkin
zipkin分為zipkin服務端和客戶端，每一個被監控的服務都是客戶端。
元件：
- 追蹤器：位於客戶端，並記錄有關發生的操作的時間和元資料，對使用者透明
- Reporter： 將資料傳送到Zipkin的檢測應用程式
- Transport ：傳輸資料：HTTP, Kafka and Scribe.
- Collector：位於服務端中，收集傳輸來的資料
- Storage ：儲存資料，預設儲存在記憶體中
- search ：查詢api，JSON應用程式設計介面，被UI呼叫
- UI ：Web UI提供了一種基於服務，時間Annotation檢視跟蹤的方法。UI中沒有內建身份驗證
skywalking
元件：
skywalking分為四個部分:探針，平臺後端，儲存，UI
- Probes,探針，探針因使用的語言不同而不通，收集資料並且格式化為skywalking所需的格式。
- Platform backend 平臺後端，對應於zipkin server，可以叢集部署，聚合，分析，將資料展示在UI中
- Storage：儲存，可擴充套件的儲存，可以使es，H2，MySQL叢集
- UI 豐富的視覺化功能，提供身份驗證
cat
- cat-client 業務模組，埋點，傳送訊息給consumer
- cat-consumer，分析從client接收的資料
- cat-home 將資料展示在控制端
- 儲存
基本原理
zipkin
┌─────────────┐ ┌───────────────────────┐ ┌─────────────┐ ┌──────────────────┐
│ User Code │ │ Trace Instrumentation │ │ Http Client │ │ Zipkin Collector │
└─────────────┘ └───────────────────────┘ └─────────────┘ └──────────────────┘
│ │ │ │
┌─────────┐
│ ──┤GET /foo ├─▶ │ ────┐ │ │
└─────────┘ │ record tags
│ │ ◀───┘ │ │
────┐
│ │ │ add trace headers │ │
◀───┘
│ │ ────┐ │ │
│ record timestamp
│ │ ◀───┘ │ │
┌─────────────────┐
│ │ ──┤GET /foo ├─▶ │ │
│X-B3-TraceId: aa │ ────┐
│ │ │X-B3-SpanId: 6b │ │ │ │
└─────────────────┘ │ invoke
│ │ │ │ request │
│
│ │ │ │ │
┌────────┐ ◀───┘
│ │ ◀─────┤200 OK ├─────── │ │
────┐ └────────┘
│ │ │ record duration │ │
┌────────┐ ◀───┘
│ ◀──┤200 OK ├── │ │ │
└────────┘ ┌────────────────────────────────┐
│ │ ──┤ asynchronously report span ├────▶ │
│ │
│{ │
│ "traceId": "aa", │
│ "id": "6b", │
│ "name": "get", │
│ "timestamp": 1483945573944000,│
│ "duration": 386000, │
│ "annotations": [ │
│--snip-- │
└────────────────────────────────┘
當發起一個呼叫，Trace Instrumentation會攔截請求，新增tag，新增traceID和spanID進http頭，當服務返回時，它會非同步地向Collector傳送資料。Collector受到資料後儲存，分析，同時UI會展示資料在介面上。
skywalking
探針將資料通過gRPC或者HTTP傳輸給後端平臺（server），後端平臺將資料儲存在Storage中，並且分析資料將結果展示在UI中
cat
客戶端：收集資料通過ThreadLocal，將資料存在ThreadLocal中，當結束時傳送資料給服務端。
舉例：
序列化與通訊：自定義的序列化協議，Netty資料傳輸
服務端：
監控模型：
- Transaction：適合記錄跨越系統邊界的程式訪問行為,比如遠端呼叫，資料庫呼叫，也適合執行時間較長的業務邏輯監控，Transaction用來記錄一段程式碼的執行時間和次數
- Event：用來記錄一件事發生的次數，開銷較小
- Heartbeat：表示程式內定期產生的統計資訊, 如CPU利用率, 記憶體利用率, 連線池狀態, 系統負載等
- Metric：用於記錄業務指標、指標可能包含對一個指標記錄次數、記錄平均值、記錄總和，業務指標最低統計粒度為1分鐘
| 類別 | 實現方式 |
|---|---|
| zipkin | 攔截請求 |
| skywalking | java探針，位元組碼增強 |
| cat | 程式碼埋點 |
接入方式
| 類別 | 接入方式 | agent到collector的協議 |
|---|---|---|
| zipkin | sleuth，引入依賴和配置 | http，mq |
| skywalking | javaanent | gRPC，http |
| cat | 程式碼侵入 | http/tcp |
資料收集
| 類別 | 資料 |
|---|---|
| zipkin | 鏈路，耗時 |
| skywalking | 鏈路，耗時，cpu，mem，JVM |
| cat | 鏈路，耗時，cpu，mem，JVM |
UI
| 類別 | 豐富度 |
|---|---|
| zipkin | 一般 |
| skywalking | 豐富 |
| cat | 豐富 |
資料儲存方案
| 類別 | 儲存方案 |
|---|---|
| zipkin | 記憶體，mysql，es，Cassandra |
| skywalking | es，mysql，h2,TiDB |
| cat | mysql，hdfs |
支援語言
| 類別 | 語言 |
|---|---|
| zipkin | C#,Go,Java,JS,Ruby,Scala,PHP;社群支援c++，Python |
| skywalking | Java，c#，PHP，Node.js |
| cat | Java, C/C++, Node.js, Python, Go |
使用者
| 類別 | 使用者 |
|---|---|
| zipkin | 多 |
| skywalking | 多 |
| cat | 較多 |
版本迭代速度
| 類別 | 速度 |
|---|---|
| zipkin | 快 |
| skywalking | 快 |
| cat | 慢 |
其它
| 類別 | 作者 | 粒度 | traceID查詢 | 告警 | 依賴分析 | OpenTracing標準 |
|---|---|---|---|---|---|---|
| zipkin | 介面級 | yes | no | yes | 部分支援 | |
| skywalking | 吳晟，華為 | 方法級 | yes | yes | yes | 完全支援 |
| cat | 吳其敏，尤勇，大眾點評 | 程式碼級 | no | yes | no | 不支援 |
注：OpenTracing通過提供平臺無關、廠商無關的API，使得開發人員能夠方便的新增（或更換）追蹤系統的實現。
總結
zipkin
- 優點：輕量級，springcloud整合，使用人數多，成熟
- 不足：功能簡單，只有鏈路監控
skywalking
- 優點：採集資料豐富，UI友好，擴充套件性高，使用者多，支援中介軟體以及框架多，社群活躍
- 不足：成熟度不夠高
cat
- 優點採集資料非常豐富，UI友好，粒度最細
- 程式碼侵入，需改動業務程式碼，git不夠活躍，更新緩慢，儲存支援不夠廣泛
這些工具各有長短，根據實際場景不同選擇之。
參考文件
https://zipkin.io/
https://github.com/apache/skywalking
https://github.com/dianping/cat/wiki
https://juejin.im/post/5a274614518825592c07f8b8
https://www.jianshu.com/p/0fbbf99a236e