1、大眾點評 Cat 監控平台
CAT(Central Application Tracking)是基於Java開發的實時應用監控平台，為大眾點評網提供了全面的監控服務和決策支持。
CAT作為大眾點評網基礎監控組件，它已經在中間件框架（MVC框架，RPC框架，數據庫框架，緩存框架等）中得到廣泛應用，為點評各業務線提供系統的性能指標、健康狀況、基礎告警等。
地址：https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html
https://blog.csdn.net/AlbertFly/article/details/84657124
整體設計
監控整體要求就是快速發現故障、快速定位故障以及輔助進行程序性能優化。為了做到這些，我們對監控系統的一些非功能做了如下的要求：
實時處理：信息的價值會隨時間銳減，尤其是事故處理過程中。
全量數據：最開始的設計目標就是全量采集，全量的好處有很多。
高可用：所有應用都倒下了，需要監控還站着，並告訴工程師發生了什么，做到故障還原和問題定位。
故障容忍：CAT本身故障不應該影響業務正常運轉，CAT掛了，應用不該受影響，只是監控能力暫時減弱。
高吞吐：要想還原真相，需要全方位地監控和度量，必須要有超強的處理吞吐能力。
可擴展：支持分布式、跨IDC部署，橫向擴展的監控系統。
不保證可靠：允許消息丟失，這是一個很重要的trade-off，目前CAT服務端可以做到4個9的可靠性，可靠系統和不可靠性系統的設計差別非常大。
CAT從開發至今，一直秉承着簡單的架構就是最好的架構原則，主要分為三個模塊：CAT-client、CAT-consumer、CAT-home。
Cat-client 提供給業務以及中間層埋點的底層SDK。
Cat-consumer 用於實時分析從客戶端提供的數據。
Cat-home 作為用戶給用戶提供展示的控制端。
在實際開發和部署中，Cat-consumer和Cat-home是部署在一個JVM內部，每個CAT服務端都可以作為consumer也可以作為home，這樣既能減少整個層級結構，也可以增加系統穩定性。
消息樹
CAT監控系統將每次URL、Service的請求內部執行情況都封裝為一個完整的消息樹、消息樹可能包括Transaction、Event、Heartbeat、Metric和Trace信息，各個消息樹之間，通過 rootMessageId以及parentMessageId串聯起來，形成整個調用鏈條。
客戶端設計
客戶端設計是CAT系統設計中最為核心的一個環節，客戶端要求是做到API簡單、高可靠性能，無論在任何場景下都不能影響客業務性能，監控只是公司核心業務流程一個旁路環節。CAT核心客戶端是Java，也支持Net客戶端，近期公司內部也在研發其他多語言客戶端。以下客戶端設計及細節均以Java客戶端為模板。
設計架構
CAT客戶端在收集端數據方面使用ThreadLocal（線程局部變量），是線程本地變量，也可以稱之為線程本地存儲。其實ThreadLocal的功用非常簡單，就是為每一個使用該變量的線程都提供一個變量值的副本，屬於Java中一種較為特殊的線程綁定機制，每一個線程都可以獨立地改變自己的副本，不會和其它線程的副本沖突。
在監控場景下，為用戶提供服務都是Web容器，比如tomcat或者Jetty，后端的RPC服務端比如Dubbo或者Pigeon，也都是基於線程池來實現的。業務方在處理業務邏輯時基本都是在一個線程內部調用后端服務、數據庫、緩存等，將這些數據拿回來再進行業務邏輯封裝，最后將結果展示給用戶。所以將所有的監控請求作為一個監控上下文存入線程變量就非常合適。
客戶端埋點
日志埋點是監控活動的最重要環節之一，日志質量決定着監控質量和效率。當前CAT的埋點目標是以問題為中心，像程序拋出exception就是典型問題。我個人對問題的定義是：不符合預期的就可以算問題，比如請求未完成、響應時間快了慢了、請求TPS多了少了、時間分布不均勻等等。
在互聯網環境中，最突出的問題場景，突出的理解是：跨越邊界的行為。包括但不限於：
HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL;
搜索/查詢引擎、業務應用、外包系統、遺留系統;
第三方網關/銀行, 合作伙伴/供應商之間；
各類業務指標，如用戶登錄、訂單數、支付狀態、銷售額。
具體操作參考：https://blog.csdn.net/weter_drop/article/details/83349651
監控指標
2、服務鏈路追蹤(Spring Cloud Sleuth)
Sleuth是Spring Cloud的組件之一，它為Spring Cloud實現了一種分布式追蹤解決方案，兼容Zipkin，HTrace和其他基於日志的追蹤系統，例如 ELK（Elasticsearch 、Logstash、 Kibana）。
相關術語
Span ---- 基本的工作單元。無論是發送一個RPC或是向RPC發送一個響應都是一個Span。每一個Span通過一個64位ID來進行唯一標識，並通過另一個64位ID對Span所在的Trace進行唯一標識。
Span能夠啟動和停止，他們不斷地追蹤自身的時間信息，當你創建了一個Span，你必須在未來的某個時刻停止它。
提示：啟動一個Trace的初始化Span被叫作 Root Span ，它的 Span ID 和 Trace Id 相同。
Trace ---- 由一系列Span 組成的一個樹狀結構。例如，如果你要執行一個分布式大數據的存儲操作，這個Trace也許會由你的PUT請求來形成。
Annotation：用來及時記錄一個事件的存在。通過引入 Brave 庫，我們不用再去設置一系列的特別事件，從而讓 Zipkin 能夠知道客戶端和服務器是誰、請求是從哪里開始的、又到哪里結束。出於學習的目的，還是把這些事件在這里列舉一下：
cs （Client Sent） - 客戶端發起一個請求，這個注釋指示了一個Span的開始。
sr （Server Received） - 服務端接收請求並開始處理它，如果用 sr 時間戳減去 cs 時間戳便能看出有多少網絡延遲。
ss（Server Sent）- 注釋請求處理完成(響應已發送給客戶端)，如果用 ss 時間戳減去sr 時間戳便可得出服務端處理請求耗費的時間。
cr（Client Received）- 預示了一個 Span的結束，客戶端成功地接收到了服務端的響應，如果用 cr 時間戳減去 cs 時間戳便可得出客戶端從服務端獲得響應所需耗費的整個時間。
顏色相同的注釋表示是同一個Span（這里一共有7個Span，編號從 Ａ到Ｇ），以下面這個注釋為例：
Trace Id = X
Span Id = D
Client Sent
這個注釋表示當前Span的Trace Id 為 X，Span Id 為 D，同時，發生了 Client Sent 事件。
下圖展示了父子關系的Span的調用鏈路：
具體操作參考：https://blog.csdn.net/pengjunlee/article/details/87797969
3、分布式跟蹤系統Zipkin
Zipkin分布式跟蹤系統；它可以幫助收集時間數據，解決在microservice架構下的延遲問題；它管理這些數據的收集和查找；Zipkin的設計是基於谷歌的Google Dapper論文。
每個應用程序向Zipkin報告定時數據，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程序；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，並且可以查看每個跟蹤請求占總跟蹤時間的百分比。
隨着業務越來越復雜，系統也隨之進行各種拆分，特別是隨着微服務架構和容器技術的興起，看似簡單的一個應用，后台可能有幾十個甚至幾百個服務在支撐；一個前端的請求可能需要多次的服務調用最后才能完成；當請求變慢或者不可用時，我們無法得知是哪個后台服務引起的，這時就需要解決如何快速定位服務故障點，Zipkin分布式跟蹤系統就能很好的解決這樣的問題。
Zipkin架構
跟蹤器(Tracer)位於你的應用程序中，並記錄發生的操作的時間和元數據,提供了相應的類庫，對用戶的使用來說是透明的，收集的跟蹤數據稱為Span;
將數據發送到Zipkin的儀器化應用程序中的組件稱為Reporter,Reporter通過幾種傳輸方式之一將追蹤數據發送到Zipkin收集器(collector)，
然后將跟蹤數據進行存儲(storage),由API查詢存儲以向UI提供數據。
架構圖如下：
參考文檔：https://segmentfault.com/a/1190000012342007
https://www.cnblogs.com/zhongpan/p/7506930.html
4、pinpoint分布式性能監控工具
Pinpoint是一款全鏈路分析工具，提供了無侵入式的調用鏈監控、方法執行詳情查看、應用狀態信息監控等功能。基於GoogleDapper論文進行的實現，與另一款開源的全鏈路分析工具Zipkin類似，但相比Zipkin提供了無侵入式、代碼維度的監控等更多的特性。 Pinpoint支持的功能比較豐富，可以支持如下幾種功能：
服務拓撲圖：對整個系統中應用的調用關系進行了可視化的展示，單擊某個服務節點，可以顯示該節點的詳細信息，比如當前節點狀態、請求數量等
實時活躍線程圖：監控應用內活躍線程的執行情況，對應用的線程執行性能可以有比較直觀的了解
請求響應散點圖：以時間維度進行請求計數和響應時間的展示，拖過拖動圖表可以選擇對應的請求查看執行的詳細情況
請求調用棧查看：對分布式環境中每個請求提供了代碼維度的可見性，可以在頁面中查看請求針對到代碼維度的執行詳情，幫助查找請求的瓶頸和故障原因。
應用狀態、機器狀態檢查：通過這個功能可以查看相關應用程序的其他的一些詳細信息，比如CPU使用情況，內存狀態、垃圾收集狀態，TPS和JVM信息等參數。
架構組成
Pinpoint 主要由 3 個組件外加 Hbase 數據庫組成，三個組件分別為：Agent、Collector 和 Web UI。
Agent組件：用於收集應用端監控數據，無侵入式，只需要在啟動命令中加入部分參數即可
Collector組件：數據收集模塊，接收Agent發送過來的監控數據，並存儲到HBase
WebUI：監控展示模塊，展示系統調用關系、調用詳情、應用狀態等，並支持報警等功能
參考地址：https://www.cnblogs.com/zz0412/p/9333296.html
https://blog.csdn.net/kangguang/article/details/77290209
5、SkyWalking 分布式追蹤系統
SkyWalking ，它是一款優秀的國產 APM 工具，包括了分布式追蹤、性能指標分析、應用和服務依賴分析等。
SkyWalking 的核心是數據分析和度量結果的存儲平台，通過 HTTP 或 gRPC 方式向 SkyWalking Collecter 提交分析和度量數據，SkyWalking Collecter 對數據進行分析和聚合，存儲到 Elasticsearch、H2、MySQL、TiDB 等其一即可，最后我們可以通過 SkyWalking UI 的可視化界面對最終的結果進行查看。Skywalking 支持從多個來源和多種格式收集數據：多種語言的 Skywalking Agent 、Zipkin v1/v2 、Istio 勘測、Envoy 度量等數據格式。
整體架構看似模塊有點多，但在實際上還是比較清晰的，主要就是通過收集各種格式的數據進行存儲，然后展示。所以搭建 Skywalking 服務我們需要關注的是 SkyWalking Collecter、SkyWalking UI 和 存儲設備，SkyWalking Collecter、SkyWalking UI 官方下載安裝包內已包含，最終我們只需考慮存儲設備即可。