之前聊了聊《監控告警策略設計》，有童鞋問，那監控告警架構怎么設計？

很多公司布控了很多系統監控，但有問題還是報不出來，根本原因：沒有實施多維度立體化監控。

什么是多維度立體化監控？

不同公司或多或少有一些自動化監控手段：

• 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；

第五大類：服務存活性監控。

監控需求：進程和端口的監控，只能保證進程在，端口在，但并不能確定服務是否能響應請求，需要確定服務“活著”。

監控方案：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刷日志，還是實時流處理，都可以。

總結

監控是一個技術活，并不是大家評論里說的“搭一個ELK就搞定了，何必這么麻煩”。

其中架構實現要點是：

• 監控平臺的思路是多維度立體化監控；
• “統一操作系統、http404，服務存活性，接口處理時間”等四大類統一監控的設計核心是“非侵入性”，不需要任何人配合修改，就能實現諸多功能的技術平臺，才是好技術平臺；
• 統一集群信息管理服務，統一人員信息管理服務，統一告警策略服務（或者配置文件），是統一技術體系的基石；

知其然，知其所以然。

思路比結論更重要。