多維度立體化監控，才是真的監控
前文介紹了通用+可擴展的http監控平台與log監控平台的架構：
結果，評論里各種冷嘲熱諷。
監控這個topic本來有很多細節可以聊，既然大夥公司都做得比較完善，後續就不糾細節了，聊聊方向上的思考，架構上的設計。今天和大夥聊聊多維度立體化監控。
一、什麼是多維度立體化監控
不同公司或多或少有一些自動化監控手段，除了前文提到的：
http介面監控
log關鍵字監控
還有很多維度的監控：
操作系統，進程，埠
http狀態碼
服務存活性
介面處理時間
RPC介面監控
用戶層面監控
如果只監控一個或少數幾個維度：
監控到異常時，基本確信系統出現了問題
反過來，沒有監控到異常，不能確信系統沒有問題
例如：
監控到操作系統CPU100%，系統大概率出現了問題，但CPU正常，並不能說明系統正常，例如tomcat掛了，CPU肯定是正常的，但操作系統監控卻探測不到，於是需要進程，埠，存活性等其他監控予以輔助
進程，埠監控到異常，系統大概率出現了問題，但進程在運行，埠在監聽，並不能說明系統正常，例如程序死鎖，進程和埠是正常的，於是需要介面處理時間等其他監控予以輔助
介面處理時間監控到超時，系統大概率出現了問題，但介面處理時間不超時，並不能說明系統正常，例如資料庫掛了，資料庫連接拿不到，服務層每個介面都很快返回，並不超時
…
這裡的觀點是：單維度監控易漏報，多維度立體化監控才是監控平台的根本之道。
前文介紹的http介面監控，log關鍵字監控，在設計上都講究通用+可擴展，接下來介紹的四個維度的監控，在設計上也是看重「通用」「非侵入性」，即被監控的站點和服務無需任何埋點，無需任何修改，被監控模塊的負責人無需配合做任何事情，就能全方位cover住。
畫外音：如果有一天你有機會負責框架，組件，基礎服務，技術平台等部門，你就會明白「非侵入性」有多重要了，在公司推一個技術產品太困難了。
二、操作系統，進程，埠監控
監控需求：
系統的網路是否被打滿，磁碟是否有空間，CPU是否繁忙，內存是否用完，負載值是否過高，JVM是否正常
服務進程是否運行
監聽埠是否正常
機器間是否聯通
常見方案一：zabbix
搞運維的都懂，不展開細聊了，聊多了怕被罵。
常見方案二：shell
寫一些非常簡單的腳本，就能夠獲取到網路、磁碟、CPU、內存、load、JVM的信息，在配合一些閾值的配置，就能實現超出閾值告警的功能。
如果配合集群信息管理服務，通過ps, netstat, telnet等命令，也能快速實現進程，埠，連通性的簡易監控。
實現要點：
重點考慮擴展性，可配置性，非侵入性
集群信息管理服務（如果沒有服務，有集群信息配置文件也行）
關於集群信息管理服務，詳見《集群信息管理，架構設計中最容易遺漏的一環》。
三、404狀態碼監控
監控需求：監控http異常狀態碼。
監控方案：nginx日誌統一監控
如果實現了http介面統一監控，404監控的必要性並不是這麼強，但畢竟實現簡單，整一個通用的花不了多少時間。
在聊存活性監控，介面處理時間監控之前，多說幾句系統架構，如果實現了框架與組件的統一，統一監控會省非常多的力氣。
上圖是一個典型的互聯網分層架構圖：
最上游是APP和browser
反向代理層是nginx，統一http404狀態碼監控就實現在這一層
web層，假設自研了web-framework
service層，假設自研了service-framework，web層會通過RPC-client調用service
數據層db，假設自研了Daojia-DAO組件調用db
緩存層cache，假設自研了Daojia-KV組件調用cache
D-DAO和D-KV兩個組件並沒有大夥想的複雜，初期只是簡單的封裝了一層而已，具體的實現方案在《框架組件，究竟要不要自研？》一文中有深入的討論。
四、服務存活性監控
監控需求：進程和埠的監控，只能保證進程在，埠在，但並不能確定服務是否能響應請求，需要確定服務「活著」。
監控方案：ping-pong式監控，在站點框架，服務框架層面統一實現，提供keepalive介面：
在框架層面就可以實現ping-pong介面
監控中心通過集群信息管理服務（或者是配置文件）獲取集群類型（web/service），集群IP列表
監控中心統一往集群發送內置的ping-pong請求
強調兩點：
如果開源框架不提供ping-pong介面，可以二次開發（要慎重，任何開源框架的二次開發，都是大坑的開始）
統一集群信息管理服務，或者，統一集群信息管理配置文件，真的很重要，是技術體系統一的基石
關於集群信息管理服務，詳見《集群信息管理，架構設計中最容易遺漏的一環》。
五、介面執行時間監控
監控需求：
http站點介面有沒有超時
RPC服務介面有沒有超時
db訪問有沒有超時
cache訪問有沒有超時
除了超時，還要監控同一個介面的執行時間有沒有同比、環比的大幅度波動
例如：一個介面平均響應時間是100ms，突然有一天增加到300ms，即使沒有超時，也有理由懷疑介面出現了問題
監控方案：框架組件統一上報（如上圖1,2,3,4）
在web-framework里，對所有http介面進行數據上報，可以上報url，參數，執行時間等核心數據
在service-framework里，對所有RPC介面進行數據上報，可以上報介面，參數，執行時間等核心數據
在DAO里，對所有資料庫SQL訪問進行數據上報，可以上報sql，參數，執行時間等核心數據
早KV-client里，對所有cache訪問進行數據上報，可以上報key，執行時間等核心數據
統一上報是思路，具體上報細節，是通過flume刷日誌，還是storm/spark實時流處理，都可以。
六、總結
監控是一個技術活，並不是大家評論里說的「搭一個ELK就搞定了，何必這麼麻煩」：
監控平台的思路是多維度立體化監控
「統一操作系統、http404，服務存活性，介面處理時間」等四大類統一監控的設計核心是「非侵入性」，不需要任何人配合修改，就能實現諸多功能的技術平台，才是好技術平台
統一集群信息管理服務，統一人員信息管理服務，統一告警策略服務（或者配置文件），是統一技術體系的基石
TAG:架構師之路 |