個人專題目錄

實現全鏈路監控

SkyWalking

https://github.com/apache/skywalking

SkyWalking是apache基金會下面的一個開源APM項目，為微服務架構和云原生架構系統設計。它通過探針自動收集所需的指標，并進行分布式追蹤。通過這些調用鏈路以及指標，Skywalking APM會感知
應用間關系和服務間關系，并進行相應的指標統計。Skywalking支持鏈路追蹤和監控應用組件基本涵蓋
主流框架和容器，如國產RPC Dubbo和motan等，國際化的spring boot，spring cloud。SkyWalking 是針對分布式系統的 APM 系統，也被稱為分布式追蹤系統

• 全自動探針監控，不需要修改應用程序代碼。查看支持的中間件和組件庫列表：https://github.com/apache/incubator-skywalking
• 支持手動探針監控, 提供了支持 OpenTracing 標準的SDK。覆蓋范圍擴大到 OpenTracing-Java 支持的組件。查看OpenTracing組件支持列表：https://github.com/opentracing-contrib/meta
• 自動監控和手動監控可以同時使用，使用手動監控彌補自動監控不支持的組件，甚至私有化組件。
• 純 Java 后端分析程序，提供 RESTful 服務，可為其他語言探針提供分析能力。
• 高性能純流式分析
• 支持多種插件，UI功能較強，接入端無代碼侵入。

Zipkin

https://zipkin.io/

https://github.com/openzipkin/zipkin

由Twitter公司開源，開放源代碼分布式的跟蹤系統，用于收集服務的定時數據，以解決微服務架構中的延遲問題，包括：數據的收集、存儲、查找和展現。特點是輕量，使用部署簡單。通過Java程序中引入客戶端，可隱式攔截Http、Thrift等形式服務調用。通過Http、Kafka、Scribe等方式同步監控數據到服務端，ZipKin帶有Web UI，但沒有告警功能。

Pinpoint

https://github.com/naver/pinpoint

一款對Java編寫的大規模分布式系統的APM工具，由韓國人開源的分布式跟蹤組件。特點是支持多種插件，UI功能強大，接入端無代碼侵入。

CAT

https://github.com/dianping/cat

CAT是大眾點評開源的基于編碼和配置的調用鏈分析，應用監控分析，日志采集，監控報警等一系列的監控平臺工具。支持JVM性能數據采集、服務Trace、告警等功能，但需要寫監控代碼。

字節碼注入 vs API 調用

Pinpoint 實現了基于字節碼注入的 Java Agent 探針，而 Zipkin 的 Brave 框架僅僅提供了應用層面的 API，但是細想問題遠不那么簡單。字節碼注入是一種簡單粗暴的解決方案，理論上來說無論任何方法調用，都可以通過注入代碼的方式實現攔截，也就是說沒有實現不了的，只有不會實現的。但 Brave 則不同，其提供的應用層面的 API 還需要框架底層驅動的支持，才能實現攔截。

全鏈路監控大數據解決方案

image-20200225100520627.png

全鏈路監控特質

低侵入性

監控系統應盡可能減少對業務系統的侵入，保持對使用方的透明性，減少開發人員的負擔，降低接入門檻和難度。對于應用的程序員來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那么這個跟蹤系統也太脆弱了，往往由于跟蹤系統在應用中植入代碼的bug或疏忽導致應用出問題，這樣才是無法滿足對跟蹤系統“無所不在的部署”這個需求。

低性能影響

由于全鏈路監控系統需要對各種應用中間件進行日志數據采集，大多都需要在業務系統內進行“埋點”或放置agent，一般都是在核心業務流程。在一些高度優化過的服務，即使一點點損耗也會很容易察覺到，而且有可能迫使在線服務的部署團隊不得不將跟蹤系統關停。

因此應盡可能降低對業務系統造成的性能影響，一般來說，對CPU的耗用低于2%可以作為一個參考閾值。

靈活全面的接入策略

為了盡可能降低接入成本，應該提供靈活的監控配置策略，讓業務方決定是否接入，以及收集數據的范圍和粒度，并提供對應的技術方案保障監控策略生效。

時效性

實時有效的監控數據展示功能，幫助相關人員理解系統行為，為流程、架構、代碼優化，以及擴容縮容、服務限流降級提供正確客觀的數據參考。

可擴展性

一個優秀的調用跟蹤系統必須支持分布式部署，具備良好的可擴展性。能夠支持的組件越多當然越好。或者提供便捷的插件開發API，對于一些沒有監控到的組件，應用開發者也可以根據需要自行擴展。

全鏈路監控功能模塊

一般的全鏈路監控系統，大致可分為四大功能模塊：

埋點與生成日志

埋點即系統在當前節點的上下文信息，可以分為 客戶端埋點、服務端埋點，以及客戶端和服務端雙向型埋點。埋點日志通常要包含以下內容traceId、spanId、調用的開始時間，協議類型、調用方ip和端口，請求的服務名、調用耗時，調用結果，異常信息等，同時預留可擴展字段，為下一步擴展做準備;

收集和存儲日志

主要支持分布式日志采集的方案，同時增加MQ作為緩沖;

每個機器上有一個 deamon 做日志收集，業務進程把自己的Trace發到daemon，daemon把收集Trace往上一級發送;

多級的collector，類似pub/sub架構，可以負載均衡;

對聚合的數據進行 實時分析和離線存儲;

離線分析 需要將同一條調用鏈的日志匯總在一起;

分析和統計調用鏈路數據，以及時效性

調用鏈跟蹤分析：把同一TraceID的Span收集起來，按時間排序就是timeline。把ParentID串起來就是調用棧。

拋異常或者超時，在日志里打印TraceID。利用TraceID查詢調用鏈情況，定位問題。

依賴度量：

• 強依賴：調用失敗會直接中斷主流程
• 高度依賴：一次鏈路中調用某個依賴的幾率高
• 頻繁依賴：一次鏈路調用同一個依賴的次數多

離線分析：按TraceID匯總，通過Span的ID和ParentID還原調用關系，分析鏈路形態。

實時分析：對單條日志直接分析，不做匯總，重組。得到當前QPS，延遲。

全鏈路監控系統希望達到的效果

請求鏈路追蹤，故障快速定位

可以通過調用鏈結合業務日志快速定位錯誤原因。

可視化

記錄各個階段耗時，進行性能分析。

依賴優化

統計各個調用環節的可用性、梳理服務依賴關系以及優化。

數據分析，鏈路梳理和優化

分析用戶的行為路徑，梳理和優化整體調用鏈路。

本文參考：

（一文搞懂全鏈路監控：方案概述與比較）https://cloud.tencent.com/developer/article/1501891

（APM巔峰對決：skywalking P.K. Pinpoint）https://skywalking.apache.org/zh/blog/2019-02-24-skywalking-pk-pinpoint.html

（開源APM之Skywalking和Pinpoint的實測對比）http://blog.zollty.com/b/archive/apm-comparison-of-skywalking-and-pinpiont.html

《OpenTracing 官方標準 —— 中文版》

Google 論文 《Dapper，大規模分布式系統的跟蹤系統》