cat全链路监控_谛听全链路监控平台实践与思考
一、項目背景
近幾年，信也科技的研發技術伴隨著業務的快速增長逐步演化為微服務化的分布式體系架構，但隨之帶來的系統間的上下游依賴關系的復雜度也呈指數級上升，已有的煙囪式的監控產品(CAT、ELK等)存在數據散落、指標覆蓋度低的特點，用戶定位、分析異常故障需要切換多個監控產品，并且經常需要上下游多人協作定位，定位問題的效率非常低下，甚至會出現找不到問題根源等難題，同時監控數據的價值也沒有有效挖掘與使用。為了解決這些問題，諦聽全鏈路監控平臺應運而生。
二、產品介紹
諦聽全鏈路監控平臺通過自動化埋點、收集、存儲、分析分布式系統中的指標數據、鏈路數據和日志數據，將流轉在上下游站點間的信息串聯起來，形成全鏈路跟蹤，通過多維指標、鏈路與日志的關聯分析與計算，提供統一告警、信息檢索和展示等功能，極大的提升了定位故障的效率。目前線上已接入300多個應用，每日產生近百億條數據，支撐公司多個重要項目(測試多環境、OneID、應用水位線、風險模型變量監控、AlarmBox等)的實施。
三、設計理念
監控系統本質是海量數據的采集、處理、分析、存儲及展示，平臺設計的難點在于我們不僅要知道“有沒有問題”，還要知道“是什么原因”導致的問題，以及發現問題如何快速修復。目前我們主要對系統的運行狀態(請求量、響應時間、異常數、出錯率等)、事件狀態(配置變更、發版、重啟、告警等)及內部狀態(健康狀態、連接池情況、線程池情況、隊列積壓數、GC次數以及時長等)等數據進行多維度監測，從面到線再到點逐步排除過濾，進而發現故障根因，支撐開發快速排障，這是當初設計諦聽監控高效排障的思路。
進一步，我們是否可以利用應用的實時運行的數據，通過檢測算法和模型，提前發現問題避免故障的發生，這是我們后續努力嘗試探索的一個方向。
舉個典型的例子來說，用戶收到一條應用響應慢的告警信息，大致的排障流程如下：
收到告警信息后，首先查看應用概覽頁并結合拓撲關系圖分析是自身問題(異常、慢查詢等情況)還是外部服務(DB、緩存、三方服務等)依賴問題。
查看事件中心分析是否是近期系統發版或者容器自動重啟導致的系統異常，是否有其它告警事件發生。
在應用監控指標頁查看接口列表定位具體慢的接口，按時間區間查詢鏈路日志，發現是慢SQL導致的問題。
查看慢SQL對應的日志報文信息，發現是參數傳遞錯誤，導致接口變慢。
查看接口上游，分析定位到調用方應用及接口與應用負責人溝通修復問題。
目前我們已在積極探索將一些標準化定位問題的流程通過自動化分析手段，將診斷結果附加到告警消息中(例如應用異常的堆棧摘要推送到異常類告警中)，幫助開發人員進一步提升定位問題的效率。
四、總體架構
信也根據內部現有的監控系統及基礎設施并結合開源系統為基礎，打通日志Logging、指標(時序)Metrics和鏈路Tracing數據，經過近1年的逐步演化實踐形成以下架構：
該架構主要有以下幾個特點：
高吞吐量：監控平臺每日處理近百億條TB級數據，整個處理過程全異步，服務端實時無狀態方式，支持大流量增長下數據采樣及機器擴容。
實時性：采用flink實時計算，對于復雜的監控規則，每分鐘的檢測窗口，分鐘級的告警推送；利用客戶端Agent秒級檢測任務，對應用的緊急異常事件(死鎖、OOM等)達到秒級檢測，實時推送告警。
低成本接入：使用主流的Agent無侵入的方式接入，容器接入應用無感知，降低應用接入及運維成本，功能比jar包方式功能更強大。
高可用：集群化部署，無單點問題，即使監控服務組件出現問題對應用也無影響，監控組件(kafka、flink、influxdb-proxy、elk等)從設計上具有多副本和數據恢復能力。
適應性強：與業界很多開源系統及組件做了良好的適配，且與公司多個系統進行數據關聯，提升定位問題的效率。
五、設計及實現
1. 客戶端設計
1.1?插件開發
Java Agent(Instrumentation)是JDK1.5引入的技術，基于JVM TI機制，使得開發者可以構建一個獨立于應用程序的代理(Agent)，用來監測運行在 JVM 上的程序或者替換和修改某些類的定義。
諦聽Agent主要使用基于AspectJ在類加載期切面織入方式對各種組件代碼進行AOP攔截，通過–javaagent 參數指定一個特定的 jar 文件(包含 Instrumentation 代理)來啟動相應的代理程序，植入我們擴展的Plugin代碼以實現監控功能。
目前諦聽已支持近20種常用插件主要包括sofa-plugin,httpclient3-plugin,httpclient4-plugin,okhttp2-plugin,okhttp3-plugin,mysql-plugin,redis-plugin,resttemplate-plugin,feign-plugin, xxljob-plugin, tomcat-plugin,jetty-plugin等。
1.2 指標收集
為了保證數據的準確性，諦聽Agent實現了通過從操作系統內核文件、MBean、組件自帶監控擴展點以及AOP攔截等多種方式結合獲取數據，不但可以根據指標的重要性進行分級，而且支持動態設置不同的指標上報頻率，并且設計上支持推和拉兩種方式(目前使用的是推的模式)。
值得說明的是，使用Linux內核文件的監控數據相比較其它方式，數據的準確度及完整度更高，例如讀取/proc/stat收集cpu信息與我們日常使用的TOP命令獲取的數據方式一致，經測試比JVM的收集的CPU數據準確性高很多，而且可以進一步了解CPU消耗的原因是系統、用戶還是IO等待導致的。
目前諦聽支持CPU、內存、磁盤、網絡、文件句柄、內存區、垃圾回收、堆與非堆、thread、tomcat、jetty、sofa、netty、sentinel、rabbitMQ、druid、tomcatJDBC、hakari等200多個系統及中間件指標。
同時收集了60多個維度200多個性能指標，全部使用預計算的模式，充分保證數據的精確性。
另外，通過定時清理無請求的多余指標、指標分級、動態啟停指標收集、高基維度指標防呆設計等多種方式防止指標收集對應用的影響。
1.3 日志收集
日志使用自研的日志組件，日志輸出時自動與鏈路關聯，并支持MDC方式自定義擴展，并根據應用的重要程度進行集群分離、冷熱分離，熱數據使用SSD存儲，提升查詢性能。
另外，通過諦聽平臺查詢日志，諦聽后臺根據用戶查詢條件自動分析精準定位，另提供關鍵詞高亮，線程查詢，鏈路查詢，IP查詢，上下文查詢等多種條件組合查詢，查詢效率比原有的Kibana查詢效率提升5倍以上，用戶體驗更佳。
1.4 鏈路設計
數據主要使用公司已有的CAT的CAL數據模型，并在CAT的服務端定制鏈路分析器將CAT的模型清洗成類OpenTracing的模型，存儲到elasticsearch中，解決了CAT無法根據條件查詢鏈路的問題，并保留了與CAT系統的鏈路兼容，方便互相連接，諦聽支持10多種條件鏈路查詢，并支持手動打點及從請求或者響應報文中規則匹配將業務信息與鏈路自動關聯，提升查詢及定位問題的效率。
鏈路系統中另外一個有挑戰的問題是，如何在各種技術棧調用情況下保證不丟失Trace信息、不破壞鏈路的完整性？
這里就涉及到數據透傳的功能，分為應用內和應用間Trace信息的傳播，有同步和異步兩種調用情況，還有可能遇到池化復用線程(ExecutorService)的場景，諦聽主要使用TransmittableThreadLocal(阿里開源的庫)技術，TTL繼承了InheritableThreadLocal，優化了在使用線程池等會池化復用線程的情況下傳遞ThreadLocal的使用(我們使用TTL Agent方式，應用無侵入，透明實現線程池的傳遞，進一步說明了Agent功能非常強大)，在數據透傳實現層根據協議的不同有不同的設置方式，比如目前廣泛使用的rpc調用使用的http協議，我們首先將上下文中的信息取出放到Request Header中，服務端再從Request Header中取出放到上下文中，完成透傳工作，對于其它的協議比如sofa，kafka等協議也有類似于header方式，傳遞流程類似，以上這一系列工作由Agent內部插件自動埋點實現。
2. 計算層設計
數據分區處理方式讓同一個應用的維度數據進入同一個Partition，利用Flink的廣播流+State+Checkpoint等機制實現。我們對計算邏輯進行高度抽象化，具體處理流程如下：
如圖所示，這種機制有如下優點：
通過廣播流在每個節點都保存了一份完整的規則數據，當規則發生變化時，每個節點都會獲取到最新的規則，這保證了整體邏輯的一致性。
將數據流時間設置為EventTime，同時利用Flink的TimeService機制解決了動態開窗、延時、亂序問題，Flink中的 state解決了數據緩存的問題，使其不用依賴于外部緩存，大大增加了吞吐量。
同時基于Flink本身的checkpoint機制，可以實現failover后狀態中的規則和緩存數據的恢復。
3. 存儲層設計
諦聽根據監控數據的使用場景不同，使用兩種存儲引擎：
對于時序類的指標數據，使用高性能的開源時序數據庫influxdb，目前按應用及指標維度進行拆表，明細數據保存3個月，定期rollup保證查詢性能。influxdb開源版本不支持集群模式，我們通過在influxdb前面的proxy中實現故障遷移，在線擴縮容、數據恢復、監控等功能，保障系統的高可用。
對于調用鏈的日志類數據使用業界廣泛使用的ELK架構，通過Mapping模板優化，關閉不必要的分詞和存儲，調整默認的字段類型、優化索引刷新時間、按小時滾動創建索引、Routing直接命中分片(不打開整個索引)，冷熱分離，保證實時數據的查詢性能，查詢時根據時間及條件精準定位路由，前臺查詢達到秒級返回。
六、核心功能及實踐場景
以上藍色為已完成功能，棕色為規劃待開發功能
核心功能建設思路：基于底層采集的全、準、細的指標、鏈路與日志數據，經過一系列的關聯分析，提供數字化的呈現，并與常用診斷工具與其它系統集成，為數據應用及智能化場景提供支撐，提升效率，為應用賦能：
1.?實踐場景一 多維條件查詢鏈路，多視圖展示
諦聽提供根據時間范圍、TraceId、客戶端名、服務端名、客戶端IP、服務端IP、僅異常調用、接口名稱、環境、耗時大于(ms)、HTTP狀態碼等條件進行組合查詢。
支持查看鏈路中請求報文、響應報文、SQL語句、redis命令、異常堆棧信息、業務主鍵等信息展示。
Agent自動在服務的響應報文中添加traceId，服務接收方可以通過頁面、異常對話框、日志、數據庫等存儲，出現異常時可以快速通過TraceID進行鏈路重放，現場溯源。
諦聽支持根據業務信息(報文提取及手工打點方式)查詢鏈路，實時追蹤用戶軌跡，以業務的角度去排查異常問題。
諦聽提供拓撲視圖、調用樹視圖、混合視圖及日志視圖，多種角度展示鏈路信息，并提供系統指標、應用信息幫助開發更快速地找出性能瓶頸。
2.?實踐場景二 多維指標分析，快速定位根因
諦聽監控平臺提供應用上下游拓撲、慢調用、慢SQL、異常統計、CPU高、GC問題、線程問題等多種常見問題的多維分析能力，代替傳統的人肉命令行(例：top,jstack,netstat,iostat,jmap,jinfo等)定位問題的方式，幫助開發人員快速找到故障的根因。
3. 實踐場景三 實時告警，多種報表，提前發現問題
提供6套默認告警模板，應用無需配置，告警功能自動生效，另外提供可視化的告警規則定制能力以及規則化配置觸發容器的能力(重啟、拉出流量等行為)，幫助應用自愈。
支持告警消息的分組、抑制、靜默、聚合減少告警噪聲干擾，支持郵件、短信、企微、WebHook、MQ等多種通道告警消息的推送。
提供日報表、周報表、健康分等多種報表，幫助開發人員提前發現系統問題。
七、未來展望
(1) 目前CAT異步鏈路問題還未完全解決，后續逐步脫離CAT，兼容云原生OpenTelemetry標準。
(2) Cat指標監控維度單一，不能滿足業務需求，后續開放客戶端的metrics，支持業務監控，完善整體監控告警體系。
(3) 完善全鏈路監控體系，向用戶體驗端監控、業務監控和中間件監控進一步拓展。
(4) 利用收集的多維度的監控數據進行挖掘，結合應用場景，利用算法模型及專家經驗，使應用更加智能更加高效。
八、致謝
感謝翔哥和豐哥及各位總監的指導，感謝運維團隊性能優化方面的支持，感謝實時數據團隊告警計算支持，感謝質量部前端的技術支持，同時感謝技術小伙伴提出許多寶貴建議。
九、參考資料
作者介紹
haydenzhu， 信也科技資深架構師
總結
以上是生活随笔為你收集整理的cat全链路监控_谛听全链路监控平台实践与思考的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .net core 文件流保存图片_Ja
- 下一篇： ios键盘横屏_cocos2d 3.2版