監(jiān)控雜談

春秋戰(zhàn)國時期，有位神醫(yī)被尊為“醫(yī)祖”，他就是“扁鵲”。一次，魏文王問扁鵲說：“你們家兄弟三人，都精于醫(yī)術，到底哪一位最好呢？”扁鵲答：“長兄最好，中兄次之，我最差。”文王又問：“那么為什么你最出名呢？”扁鵲答：“長兄治病，是治病于病情發(fā)作之前，由于一般人不知道他事先能鏟除病因，所以他的名氣無法傳出去；中兄治病，是治病于病情初起時，一般人以為他只能治輕微的小病，所以他的名氣只及本鄉(xiāng)里；而我是治病于病情嚴重之時，一般人都看到我在經(jīng)脈上穿針管放血，在皮膚上敷藥等大手術，所以以為我的醫(yī)術高明，名氣因此響遍全國。”

監(jiān)控在企業(yè)應用系統(tǒng)中屬于不可或缺的基礎建設，一個完善的監(jiān)控體系可以幫助我們發(fā)現(xiàn)系統(tǒng)瓶頸、了解系統(tǒng)狀態(tài)，最重要的是發(fā)現(xiàn)系統(tǒng)故障。

一些小型企業(yè)系統(tǒng)，可能更多的利用云產(chǎn)品自帶的系統(tǒng)監(jiān)控來監(jiān)控系統(tǒng)CPU、磁盤、內(nèi)存等指標，對程序運行只能通過日志來監(jiān)控，比如定期grep一下日志中的Exception，或者Catch住異常然后發(fā)一份郵件，或者利用JMX來監(jiān)控(但這個需要一直有人盯著)。這種方式便捷又原始，不過也是，小型系統(tǒng)如果為了監(jiān)控去引入Cat、Prometheus、Skywalking這類組件，從成本上來說得不償失。

這種在不能引入第三方組件的情況下，可以考慮對系統(tǒng)原有的Log組件做一些封裝，以Slf4j為例，我們可以通過實現(xiàn)它的Filter來做日志攔截，如果有Error日志，就通過釘釘或者企業(yè)微信的WebHook機器人進行統(tǒng)治，將異常情況實時通知給業(yè)務開發(fā)者。當然這個組件可以像上面這樣簡單實現(xiàn)，也可以做的很復雜，比如做Error日志通知的黑白名單，除了Error日志，我們還可以在Http的Filter上判斷接口響應時間，如果接口處理超過一定時間就進行告警，此外Dubbo的Filter也是同理，如果系統(tǒng)又配置中心這一概念，還可以玩的更靈活。當然，為了防止Error日志請求釘釘?shù)暮臅r影響業(yè)務，這部分邏輯可以異步去處理，我們使用的組件是通過時間輪去異步發(fā)送釘釘消息，并且對時間片中相同的日志進行了合并。

上面這種方式是比較簡單粗暴的，它可以解決大部分的問題，如果你的Log打的比較規(guī)范，在系統(tǒng)崩潰前就可以收到很多告警消息，最直觀的就是請求響應超時的告警突增，這些都預示著你的系統(tǒng)有“病”，但是這種簡單粗暴的監(jiān)控沒法告訴你是什么病，這時候系統(tǒng)壓力已經(jīng)瀕臨極限，就需要扁鵲來穿針放血，排查系統(tǒng)問題，最有效的辦法是直接重啟系統(tǒng)，但這會丟掉病人發(fā)病時第一時間的資料，堆棧信息。

當然，現(xiàn)實情況可能比較復雜，說不定發(fā)生故障時系統(tǒng)已經(jīng)封閉，進行上下線重啟操作，或者權限管理比較嚴格，無法第一時間連上故障機器進行排查，只能去Review代碼或者排查日志，都不好說。

智者千慮，必有一失。愚者千慮，必有一得。

這句話出自《晏子春秋》，用在監(jiān)控系統(tǒng)也再合適不過，就算設計的再精妙的監(jiān)控系統(tǒng)可能都逃不過系統(tǒng)病情嚴重后扁鵲出手，線上故障是無法避免的。所以監(jiān)控系統(tǒng)應該作用于我們開發(fā)的三個階段。

開發(fā)時

開發(fā)中我們需要一個充當扁鵲大哥的角色，幫助我們直接發(fā)現(xiàn)代碼問題，比較直接的方式就是組內(nèi)的Code Review，嚴格代碼提交規(guī)范，再業(yè)務再老道的人也難防提交一個Bug。此外就是引入Sonar這類靜態(tài)代碼掃描工具來排除隱藏Bug，以及規(guī)范我們的代碼提交。

運行時

這是監(jiān)控系統(tǒng)的關鍵，這部分需要依賴第三方組件。

比如做鏈路監(jiān)控的Skywalking、Cat，Skywalking通過給我們的請求添加TraceId，來分析從用戶發(fā)起請求到結束經(jīng)過了那些系統(tǒng)處理、耗時、緩存、數(shù)據(jù)庫訪問等等。此外點評開源的Cat，功能強大，可以收集接口的平均響應時間、99線、95線、最大最小響應時間、失敗率等信息，還有接口的RT圖，系統(tǒng)上下游調(diào)用分析，堆棧快照，告警等功能，無論是系統(tǒng)性能優(yōu)化時分析瓶頸，還是排查問題，Cat都是得力幫手，不過Cat現(xiàn)在的社區(qū)不是很活躍，對一些新技術支持不是很完善。

除了調(diào)用鏈路的監(jiān)控，還有我們機器性能指標、業(yè)務監(jiān)控等需求，常用的方案是Prometheus(普羅米修斯)，Prometheus支持用戶利用其API自己開發(fā)Node Exporter插件，去監(jiān)控不同的中間件指標，Prometheus默認的Node Exporter主要用于監(jiān)控機器性能，還有一些第三方開發(fā)的Mysql Exporter、RocketMQ Exporter可以用于監(jiān)控Mysql節(jié)點、RocketMQ的IO、生產(chǎn)消費量，消息大小等指標。

Prometheus的指標主要有四類：Counter,Gauge,Histogram,Summary。

?Counter 連續(xù)增加不會減少的計數(shù)器，例如：網(wǎng)站訪問人數(shù)，生成請求次數(shù)、錯誤次數(shù)等指標。Counter類型的指標，只包含一個inc()的方法，就是用于計數(shù)器+1?Gauge 一個可增可減的動態(tài)指標值，可以用來統(tǒng)計 如CPU，內(nèi)存使用率，線程池數(shù)量等，包含兩個主要的方法inc()和dec()，用于增加和減少計數(shù)?Histogram 指標生成的是直方圖數(shù)據(jù)，主要用來統(tǒng)計數(shù)據(jù)的分布情況，類似一段時間內(nèi)http請求響應小于0.005秒、小于0.01秒、小于0.025秒的數(shù)據(jù)分布情況?Summary Summary 類型是在客戶端直接聚合生成的百分位數(shù)

同樣，我們在設計監(jiān)控項時需要考慮到Google提出的四個黃金指標。

??延遲：服務請求所花費的時間，需要區(qū)分成功請求和失敗請求。例如，失敗請求可能會以非常低的延遲返回錯誤結果。??流量：針對系統(tǒng)，例如，每秒HTTP請求數(shù)，或者數(shù)據(jù)庫系統(tǒng)的事務。??錯誤：請求失敗的速率，要么是HTTP 500錯誤等顯式失敗，要么是返回錯誤內(nèi)容或無效內(nèi)容等隱式失敗，或者基于策略原因導致的失敗——例如，強制要求響應時間超過30ms的請求視為錯誤。??飽和度：應用程序有多“滿”，或者受限的資源，如內(nèi)存或IO。這還包括即將飽和的部分，例如正在快速填充的磁盤。

故障時

故障處理也應當屬于我們監(jiān)控系統(tǒng)的一部分，在這部分，我們需要在排查到問題原因后，對故障期間的錯誤數(shù)據(jù)進行修復，這就需要我們自己通過業(yè)務邏輯去開發(fā)相應的工具箱以及建立完整的SOP體系了，當然，這不是一蹴而就的事，需要在平常問題修復排查時進行沉淀。

為了防止故障發(fā)生，一些復雜的業(yè)務邏輯上線前一定要做灰度開關、功能開關或者降級服務，不需要設計的多么精妙，一個簡單的if邏輯判斷即可，保證業(yè)務可以平穩(wěn)運行后，日后刪掉這部分開關再上線。降級開關可以用在一些預估有大流量或者接口本身響應時長就高的情況，防止系統(tǒng)或者下游被大流量直接打垮。

最后，本文只是簡單提了一些系統(tǒng)指標監(jiān)控、故障監(jiān)控，此外還有性能監(jiān)控，是我們進行性能分析、性能優(yōu)化的關鍵，這部分監(jiān)控需要深入到應用程序運行時類加載、方法耗時、系統(tǒng)API、網(wǎng)絡請求首包耗時、DNS解析耗時的層次。建立一個精細的監(jiān)控平臺，是一個需要長久時間發(fā)展演進的過程，不管是千慮一得，還是千慮一失，都是難以避免的，當然最終要的是在血的教訓中積累經(jīng)驗，避免問題再次發(fā)生。

讀者討論請點擊閱讀原文到博客內(nèi)留言