前言
最近剛離職，新公司還沒去報導，就整天賦閒在家看看書寫寫技術文章。
下午和某個微信群的群友聊起網際網路公司的監控系統，簡短的描述了一些我的看法。
正好最近有空，這篇文章就來聊聊我自己在職業生涯裡使用過以及瞭解過的一些監控系統，當做一篇小白掃盲或者個人漫談就好。
基礎必知
要對監控有個全面的瞭解，大體要了解三方面的知識，如下圖所示：
常見監控型別
一般在企業級技術監控領域，大體分為五種型別的監控：
- 基礎監控：包括頻寬、CDN、伺服器CPU、Memory、DiskIO、Network、Load5等指標；
- 指標監控：服務+介面維度，常見指標有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指標；
- 業務監控：拿電商來說，常見的有同比下單量、支付量、履約率、DAU、GMV、支付取消率等多重指標，一般需要根據具體的業務需要來定製化；
- 鏈路監控：鏈路監控主要用來快速定位排查問題，在目前大多數網際網路公司的微服務架構下，服務呼叫關係複雜，鏈路追蹤監控可以幫助技術同學快速的找到呼叫鏈路上某個環節的問題；
- 輿情監控：主要指對外部的一些訊息的監控，比如某APP突然掛了、下不了單、有BUG可以刷單、客訴等一些列對企業或者品牌不利的因素，便於快速處理甚至公關；
處理過程及注意點
監控從採集到告警通知，大體分為五個步驟，每個步驟的注意事項各有不同又有部分通用的考慮。
- 資料採集
-
- 釋義說明：通過各種方式採集原始的相關資料，常見的有agent、埋點等方式；
- 注意事項：主要為資料採集對業務服務的效能損耗以及對業務的侵入性兩點：
- 一般取樣都是百分比取樣，比如10%，如果100%取樣，對業務服務的效能損耗會比較大；
- 良好的監控系統，對業務來說應該是無感知的，能快速接入又不影響正常的業務迭代；
- 資料儲存
-
- 釋義說明：採集到的原始資料需要進行儲存，以便於進行後續的聚合計算；
- 注意事項：這裡需要注意的點為儲存時間和成本控制兩方面：
- 儲存時間：大多場景只關注最近一週或最近一個月，但有時候為了審計安全等需要，部分資料需要儲存的時間會比較長，甚至有1-2年，因此需要根據具體情況來設定資料過期和清理時間；
- 成本控制：有些場景對資料的實時性要求比較高，因此需要儲存到高速SSD，有些場景資料實時性沒那麼高，就可以考慮更低成本的儲存方式，甚至做資料歸檔，然後離線計算的方式來進行後續的計算；
- 資料計算
-
- 釋義說明：通過對採集到的原始資料進行各種維度的計算，才能得到我們想要的監控指標；
- 注意事項：資料計算這一環節，主要考慮的點為計算速度和結果的準確性：
- 計算速度：上面提到了，某些場景對於資料的實時性要求較高，因此在計算環節就需要考慮到這點。在具體的技術方案實現過程中，需要根據不同的業務需要來採用不同的技術選型和實現；
- 資料準確：比如上面提到的每分鐘訂單量，以及履約率、錯誤率等指標，對準確度要求是比較高的。再比如QPS這種指標，如果實時計算，對服務壓力比較大，但如果取單位時間的均值，又會造成結果的準確性降低，因此在實際實踐過程中，需要綜合考量。
- 資料展示
-
- 釋義說明：即通過介面動態視覺化的方式，將我們關注的監控指標進行展示。
- 注意事項
- 時延：時延這部分，上面已經闡述過了，主要還是要考慮到具體的業務場景，靈活採用技術方案；
- 便捷：監控是個很複雜龐大的體系，但對使用者來說，往往只關注和自己有關的模組，因此便捷可定製化的展示，良好的介面，是很需要下功夫去設計的。
- 告警通知
-
- 釋義說明：將已發生的或者即將發生的錯誤異常及時通知給相關同學，快速處理，降低影響。
- 注意事項
- 時延：告警是需要及時的做到通知的，因此對實時性要求很高。
- 降噪：這涉及到告警的一個敏感度問題，某些閾值怎麼設定，通知到誰，怎麼通知，不同等級的告警採用什麼方式通知，都有很多需要考量的方面。
監控體系
監控體系是個很龐大複雜的體系，從技術角度來說，可以看下面這張圖：
更多關於監控分級體系的內容，可參考我之前的部落格：效能測試從零開始實施指南-效能監控篇
工具漫談
這一部分，聊聊我自己使用過或者瞭解過的一些監控工具，就是個漫談部分。
剛開始從事測試工作時候，公司還有部分服務是Windows server伺服器+SQL server的資料庫。
那時候的監控，基本就是Windows自帶的各種計數器，介面是很直觀，但放在現在的時間點，應該只有極少數公司有這種情況。
後來在銀行接觸到運維同學搭建的Zabbix以及基於Prometheus+grafana搭建的一套監控。
zabbix從我個人角度來說，是個綜合性質的監控工具，夠全面，但只適合中小型企業。
當需要處理的資料和定製化需求較強時，他會有越來越明顯的短板。
Prometheus體系算是監控領域很全面靈活的，支援多種資料來源，靈活配置可定製化，很多企業都在使用這套體系，但到了一定的層級維度，靈活往往會變成桎梏。
上家公司最初接觸到的是聽雲，高度企業級商業監控工具，但成本和靈活度又是另一個維度的考量因素。
後續運維和監控團隊的同學陸續介入了pinpoint、cat、Prometheus、skywalking、jaeger，arthas，再演變到現在的二次開發封裝的一站式監控平臺。
pinpoint的取樣和鏈路追蹤做的是比較友好的，但太靈活，反而在某些階段，不是最優解。
cat是美團開源的監控產品，但也有部分缺點，比如：監控環比只有分鐘級，缺少更細的維度，介面不太友好。
skywalking是需要深度開發和改造，才能很好的應用於企業級監控需求的，它的UI操作部分，有些會顯得很迷。
jaeger是個很好用的輕量級鏈路追蹤工具，使用手感不錯，建議嘗試。
arthas是阿里開源的java問題定位和分析工具，誰用誰知道有多爽。
最後，綜合來說，每個公司在不同階段，對監控的需求和痛點是不一樣的，技術棧的選型又受限於做監控的團隊本身的一些因素。靈活使用工具，提高效率解決問題，才是技術人最該關注的。