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