經過團隊兩個月的努力，新版本的監控系統終於上線了。
從早期構思當下痛點，下定決心重做，真正的把一個“系統”升級爲“服務”，到快速迭代中實際需求的不斷提出、改進，這裏總結了迭代過程中的經驗和心得，希望給同樣爲業務監控系統發愁的筒子們一些幫助和啓發。
故事是從一次類似的評審環節開始的，負責這個監控系統的工程師小曹、小黃和小孫參加了答辯。
一、背景環節（10分鐘）
評委A：你們是重新做了一個監控+報警系統？？？
工程師小曹：是的，叫dolphin。
評委A：爲什麼要做這個系統重構老的不行麼？做這個系統的意義在哪裏？可不可以不做？（靈魂3連問）
工程師小曹：好大夫在線從2006年到2020年，經過14年的業務高速發展，監控系統面臨的挑戰也越來越大，碰到的問題也越來越多，所以我們決定要重做監控系統…
評委B：爲什麼不直接使用開源系統？
工程師小曹：主要有以下4個原因：
- 開源系統沒有自動報警升級策略，比如我們要求的升級路徑是：系統負責人（多人）=> 團隊技術負責人 => CTO/CEO；
- 開源系統一般只能簡單報警，如報給配置好的特定幾個人（一般是運維同學），而我們是希望一線工程師更多的感知、承擔相關工作，向devops看起，所以我們需要按照系統負責人拆分報警，要自定義、靈活且容易上手的配置規則和閾值；
- 開源系統配套的報警規則一般是功能都有（短信、郵件、webhook等），但是抽象度不足，比如設置通用型報警規則，報警靜默等，即便是強大的alertmanager(https://prometheus.io/docs/alerting/latest/alertmanager/)，也還是過於簡單；
- 整體來說，當前的開源監控+報警系統，還只是一個“系統”，而我們需要的是一個“服務”，當然我們也是在這些開源系統上豐富了功能，希望還是去做一個監控、報警服務。
評委A：感覺你在背作文啊，你的作文有論據麼？還是聊聊具體的問題吧。
工程師小黃：是的，我們確實遇到了很多的問題：
- 之前的版本是基於zabbix和自定義系統結合的，業務運維同學需要7x24h值班，人工打電話叫你起來解決各種問題，不但容易誤事，大家還相互埋怨；
- 負責人交接系統的時候，相關報警沒有及時更換，導致新負責人沒有收到報警，一旦發生故障只能用戶上報，時間久，業務受損嚴重，整體績效不合格；
- 報警沒有升級機制，一線開發、運維長時間沒有解決問題，業務持續受損，直到某個大牛醫生給老闆私聊反饋了這個問題，老闆找來技術領導，問咋回事，這個時候技術領導才知道出了這麼大的問題，整體績效不合格；
- 報警規則不靈活，一旦底層故障，大面積短信轟炸，搞不清楚是什麼問題，定位時間很長，整體績效不合格；
- 維護報警規則成本高，新增、修改、刪除都需要相關同學進行配置，很麻煩；
- 沒有統計分析量化，哪個團隊報警多，需要重點干預完全不知道；
評委A：你們這個系統的目標用戶是哪些人？
工程師小黃：秉承devops的思想，我們的用戶當然是一線開發、技術lead、運維和CTO（甚至是CEO）。
評委B：監控這個概念還是太廣了，你們這個系統具體定位是什麼？
工程師小黃：一般我們將監控系統分爲五層來考慮，當然也有人分成三層，大致的意思都差不多：
- 客戶端監控：用戶行爲信息，業務返回碼，客戶端性能，運營商，版本，操作系統等；
- 業務層監控：業務數據的監控，例如：登錄，註冊，下單，支付等等；
- 應用層監控：相關的技術參數，例如：URL 請求次數，Service 請求數量，SQL 執行的結果，Cache 的利用率，QPS 等等；
- 系統層監控：物理主機，虛擬主機以及操作系統的參數。例如：CPU 利用率，內存利用率，磁盤空間情況；
- 網絡層監控：網絡情況參數。例如：網關流量情況，丟包率，錯包率，連接數等等；
目前階段，我們主要還是定位在客戶端、業務層和應用層監控等，基於日誌分析的監控。在後續規劃中，也會逐步下探到系統層和網絡層。
二、詳細設計考察環節（40分鐘）
評委C：你們早期監控系統是怎麼設計的？
工程師小黃：當用戶請求到好大夫在線的服務器之後，會產生相應的日誌。比如Nginx會有access.log，程序會記錄locallog（自定義日誌）和tracelog（分佈式調用棧日誌）等，然後對日誌進行收集和存儲，最後定時查詢告警指標，判斷是否要告警，如果要告警，通過郵件和短信進行發送。
評委C：這個設計有問題麼？
工程師小黃：故障可能得不到及時解決。由於報警發送通道只有郵件和短信，如果故障發生晚上凌晨，大家都在睡覺的時候，即便收到郵件和短信告警的，基本不可能叫起來去處理故障。所以出現的情況是第二天一早就收到了用戶的投訴。一看手機發現收到了N條報警短信，故障時長已經非常久了，一份故障總結報告在向你招手！時間一長，故障報告寫到了手軟之後，每當到了上線日，晚上都會睡不踏實，一段時間就要看看手機沒有短信告警，害怕出問題。每當半夜聽到手機的震動或者叮的響聲，心裏就一緊，常常失眠。
評委C：那這個問題你們是怎麼解決的，爲什麼要這麼這麼做？
工程師小黃：我們加入了電話報警機制，而且是追命連環call，務必要保證把負責人從夢裏叫醒，去解決問題。
當然也不只是簡單加上了電話報警這個通路。報警規則往往是分鐘級別的，不能一直觸發一直報警，所以也加入了電話應答後自動靜默的特點，同時伴隨着故障升級的特性，後續會再講。
評委D：除了電話報警的問題，你們還遇到了別的問題了麼？
工程師小孫：主要是職責不夠明確。雖然電話告警，能夠讓故障得到及時的解決。但是早期的告警指標大多數都是兜底監控，監控指標都是監控全量的報錯情況，比如sentry(https://sentry.io/)報錯全量監控，status狀態非0全量監控。報警接收人基本爲系統架構部人員和運維人員。導致系統架構部和運維同學頻繁的接到電話告警，先判斷問題，再找業務部門溝通，效率非常低成本又高，似乎又回到了類似之前值班運維人工值守的狀況。
評委D：那你們是怎麼解決這個問題的？
工程師小孫：我們抽象了用戶、團隊、應用、監控項等等基本概念，做到告警規則->團隊->對應負責人的自由匹配。每當告警事件產生後，就可以直接找到對應的告警負責人，進行精準告警。
評委D：這個問題給你們最大的感受是什麼？
工程師小孫：如果你是運維或者架構師，有沒有晚上頻繁接到電話告警，擔心家人晚上睡不好，自己“主(bei)動(gan)”去另外一個臥室睡覺的！這個功能上線後，世界又迴歸清靜了，當然更多的工程師同學要起來查問題了。。。系統感知能力越強（監控項加的越多），工程師提前消除潛在風險、bug的能力就越強，長期看其實是更有利於大家節假日休息的。
評委E：那之前說的自動升級報警又是什麼？
工程師小孫：當故障產生的時候，系統的直接負責人開始排查解決故障，但有時候問題不是很好解決，相關負責人在聚精會神解決問題時，往往又忘了反饋問題，就會導致故障長時間得不到的解決，影響的用戶越來越多，投訴也越來越多，直到某個大牛醫生將問題私信給了老闆，老闆叫來技術領導，問咋回事，這個時候技術領導纔開始加大資源投入去排查解決問題。針對這類問題，儘管定了相關流程，如10分鐘如果沒解決要上報，誰跟進，誰協調資源等等，但是一旦故障發生時，很容易忽略時間，最終導致各方都不滿意，績效當然不合格了。
評委E：那你們是怎麼解決的？
工程師小孫：我們加入了告警自動升級機制。當故障產生後，系統直接負責人（必須有第一、第二負責人）首先會同時接收到告警信息，一段時間（如15分鐘）後，如果問題還沒有得到解決，團隊技術負責人和系統架構師就會收到告警信息，可以進行協助或者干預了。又過去一段時間（如30分鐘）後，問題還是沒有得到解決，CTO將會收到報警信息，問題會自動升級上報。
升級的好處是技術負責人可以視報警嚴重程度，決定是否加大資源去排查問題，同時向老闆彙報原因，即做到了及時感知問題，不掩蓋問題，也不耽誤事。
當然，這樣的後果是系統負責人的壓力直接就上去了，他們要花更多的時間去關注系統的穩定性、錯誤率和bug等，你也不好意思總讓CTO接到你們團隊的報警是吧？
評委E：這個問題給你們的感受是什麼？
工程師小曹：流程還是靠系統保障更靠譜，技術要對業務負責，故障都不感知怎麼能行？故障、bug出了不可怕，大家第一時間止損，然後總結就行了。不要怕，更不能掩蓋問題。
評委F：真是問題推着設計走啊，那整體來看，新監控系統大體是什麼樣的？
工程師小曹：整體的架構如下圖：
dolphin的主要的新特性如下：
a) 告警規則和應用關聯，應用和人關聯。只要維護好應用和人的關係，那麼告警規則不用頻繁的發生變化。並且應用和人的關係在監控系統中由業務自己負責維護：
b) 告警規則新增、修改、刪除等維護工作直接給了相關業務部門開發人員，職責明確，不再由特定的人員去維護：
c) 採用Prometheus技術體系。定時任務會從Elasticsearch採集監控指標數據，存儲到Prometheus中。定時任務通過PromQL去Prometheus查詢數據，根據預定義規則判斷是否滿足告警事件。同時Prometheus Web UI 和Grafana可以直接到Prometheus查詢相關數據，用於圖形展示。
d) 添加企業微信羣報警機器人功能。當產生告警事件之後，不僅僅只有打電話，短信，郵件。還可以通過報警機器人，推送告警信息到事業部門的技術羣中，並且@系統的相關負責人。這個報警機器人，不僅僅是多了一種告警發送通道，還可以報警產生之後，可以讓同部門的更多的同事知道告警信息，協助排查問題：
e) 告警日誌歷史可以方便查詢：
f) 應用總覽。這個相當於是所有系統的portal入口匯聚，可以方便跳轉到各應用的文檔頁面(設計/使用/介紹等)，關聯各個系統的confluence，方便大家整體查找：
g) 通訊錄、權限和內部hr、OPS系統打通，隨時感知人員入、離職狀態，提醒技術負責人進行人員變更：
評委F：聽上去都挺不錯的，那真實上線之後，有遇到什麼沒想到的問題麼？
工程師小曹：還是挺多的，比如缺乏報警靜默功能。當程序觸發了報警規則，或者有些報警不影響用戶，但是需要等到代碼上線之後才能修復的，這個時候需要把報警給屏蔽掉。
評委F：這個問題你們是怎麼解決的？
工程師小黃：上線靜默功能，以在一定時間段降低不必要的報警。架構圖如下：
頁面配置如下：
有了靜默就要防止無休止靜默，萬一忘了打開就誤事了。所以系統會在靜默超過一段時間後強制釋放，以避免大家遺忘。
另外，告警觸達率不高也是我們需要重點關注的。有的應用加的報警規則比較全面，但是有些應用只有基本的sentry，即只關注到了應用層面的報警。但是更多相關中間件的報警項也非常多，業務方如果逐一去加的話，不但繁瑣，而且很容易出現諸多問題（經驗不足導致誤報或者報不出來）。由此，我們設計了通用型報警規則，即把業務方使用的中間件（mq、redis、mysql等等），設立默認規則作用於所有的應用，這樣就具備了更多的感知能力。當某個系統依賴的中間件故障時，系統負責人也可以收到相關中間件報警，再加上原有的應用層報警，這樣就更容易定位問題了。當然，如果某些應用需要對中間件有自定義規則時，也可以複寫通用型報警規則和閾值。如下圖：
dolphin系統會優先加載應用特有的報警規則和閾值。
這些問題都解決後，各團隊基本都開始大規模使用了，簡單的配置規則，靈活的聯繫人變更，及時的報警頻率，都收穫了好評，當然改進更是源源不斷。比如每次報警內容只能推送告警的聚合數字內容，不能推送告警具體的原因，更沒有根因分析，不能幫助業務方快速定位問題。每次收到報警，還是要打開電腦，連上vpn，sentry、日誌等一頓看，然後發現不影響，確實有點兒煩人，能不能協助進一步定位具體問題原因呢？
我們仔細思考、分析了日常報警原因和表象後，發現還是可以進一步提供更豐富的信息出來的，比如：如果是sentry類的報警，可以直接推送相關具體問題的網頁截圖。更高級的用法是使用另一組同學研發的神器：系統畫像系統。畫像系統會去幫助設計一個具體信息聚合頁，如：status非0報警、錯誤數據、redis連接超時、mysql慢查詢等等，我們將這些對應的聚合頁，通過報警機器人自動推送出來。
a) 推送Sentry網頁截圖：
b) 推送畫像系統網頁截圖：
ps.關於系統畫像系統，後續會再單獨介紹，感興趣的同學們可以持續關注下這個神器是如何誕生以及幫助大家快速定位問題的。
衆評委此刻頓時騷動起來，從他們的眼中我彷彿看到了無數次夜裏我爬起來解決問題的身影。。。
三、補充說明環節（10分鐘）
評委A：你們未來還有什麼規劃麼？
工程師小曹：主要是以下幾方面：
- 報警趨勢的變化分析，可以評估一個應用是不是在逐步的惡化，及時提示相關係統負責人進行重點關注，不能總是去救火的狀態；
- 隨着公司整體容器化的進行，dolphin也要對接上容器化，進一步打通p8s、k8s，擴展報警範圍和能力；
- 報警機器人強化，當然這也取決於企業微信機器人自定義回覆消息能力的開放，目前還是單向的沒法互動；
- 高可用和可擴展性持續增強，隨着報警項的增多，及時觸達率是我們重點關注的；
- 後續繼續完善相關文檔，能開源出來就更好了。。。
答辯組織者：評委們，還有其它問題麼？
評審N：挺全面的了，期待早日完善上述特點，特別是機器人交互方式，能夠方便大家直接簡單操作就更好了。
本文轉載自公衆號HaoDF技術團隊（ID：gh_a0f9bc95946e）。
原文鏈接：