之前聊了聊《監(jiān)控告警策略設(shè)計(jì)》，有童鞋問(wèn)，那監(jiān)控告警架構(gòu)怎么設(shè)計(jì)？

很多公司布控了很多系統(tǒng)監(jiān)控，但有問(wèn)題還是報(bào)不出來(lái)，根本原因：沒有實(shí)施多維度立體化監(jiān)控。

什么是多維度立體化監(jiān)控？

不同公司或多或少有一些自動(dòng)化監(jiān)控手段：

• http接口監(jiān)控；
• log關(guān)鍵字監(jiān)控；

除此之外，其實(shí)還有很多維度的監(jiān)控：

• 操作系統(tǒng)，進(jìn)程，端口；
• http狀態(tài)碼；
• 服務(wù)存活性；
• 接口處理時(shí)間；
• RPC接口監(jiān)控；
• 用戶層面監(jiān)控；

如果只監(jiān)控一個(gè)或少數(shù)幾個(gè)維度：

• 監(jiān)控到異常時(shí)，基本確信系統(tǒng)出現(xiàn)了問(wèn)題；
• 反過(guò)來(lái)，沒有監(jiān)控到異常，不能確信系統(tǒng)沒有問(wèn)題；

例如：

• 情況一：監(jiān)控到操作系統(tǒng)CPU100%，系統(tǒng)大概率出現(xiàn)了問(wèn)題，但CPU正常，并不能說(shuō)明系統(tǒng)正常，例如tomcat掛了，CPU肯定是正常的，但操作系統(tǒng)監(jiān)控卻探測(cè)不到，于是需要進(jìn)程，端口，存活性等其他監(jiān)控予以輔助。
• 情況二：進(jìn)程，端口監(jiān)控到異常，系統(tǒng)大概率出現(xiàn)了問(wèn)題，但進(jìn)程在運(yùn)行，端口在監(jiān)聽，并不能說(shuō)明系統(tǒng)正常，例如程序死鎖，進(jìn)程和端口是正常的，于是需要接口處理時(shí)間等其他監(jiān)控予以輔助。
• 情況三：接口處理時(shí)間監(jiān)控到超時(shí)，系統(tǒng)大概率出現(xiàn)了問(wèn)題，但接口處理時(shí)間不超時(shí)，并不能說(shuō)明系統(tǒng)正常，例如數(shù)據(jù)庫(kù)掛了，數(shù)據(jù)庫(kù)連接拿不到，服務(wù)層每個(gè)接口都很快返回，并不超時(shí)。

我們會(huì)發(fā)現(xiàn)，單維度監(jiān)控易漏報(bào)，多維度立體化監(jiān)控才是監(jiān)控平臺(tái)的根本之道。

如何實(shí)施多維度立體化監(jiān)控呢？

除了最常見的http接口監(jiān)控（第一大類），log關(guān)鍵字監(jiān)控（第二大類），今天再介紹四個(gè)維度上的監(jiān)控。

這四個(gè)維度的監(jiān)控，在設(shè)計(jì)上也是看重“通用”“非侵入性”，即被監(jiān)控的站點(diǎn)和服務(wù)無(wú)需任何埋點(diǎn)，無(wú)需任何修改，被監(jiān)控模塊的負(fù)責(zé)人無(wú)需配合做任何事情，就能全方位cover住。

“非侵入性”在架構(gòu)設(shè)計(jì)的過(guò)程中非常重要。如果有一天你負(fù)責(zé)過(guò)框架，組件，基礎(chǔ)服務(wù)，技術(shù)平臺(tái)等部門，你就會(huì)明白，在公司推一個(gè)技術(shù)產(chǎn)品，太困難了。

第三大類：操作系統(tǒng)，進(jìn)程，端口監(jiān)控。

監(jiān)控需求：

• 系統(tǒng)的網(wǎng)絡(luò)是否被打滿，磁盤是否有空間，CPU是否繁忙，內(nèi)存是否用完，負(fù)載值是否過(guò)高，JVM是否正常；
• 服務(wù)進(jìn)程是否運(yùn)行；
• 監(jiān)聽端口是否正常；
• 機(jī)器間是否聯(lián)通；

常見方案一：zabbix

搞運(yùn)維的都懂，不展開細(xì)聊了，聊多了怕被罵。

常見方案二：shell

寫一些非常簡(jiǎn)單的腳本，就能夠獲取到網(wǎng)絡(luò)、磁盤、CPU、內(nèi)存、load、JVM的信息，再配合一些閾值的配置，就能實(shí)現(xiàn)超出閾值告警的功能。

如果配合集群信息管理服務(wù)，通過(guò)ps, netstat, telnet等命令，也能快速實(shí)現(xiàn)進(jìn)程，端口，連通性的簡(jiǎn)易監(jiān)控。

實(shí)現(xiàn)要點(diǎn)：

• 重點(diǎn)考慮擴(kuò)展性，可配置性，非侵入性；
• 需要有集群信息統(tǒng)一管理（如果沒有配置中心，有集群統(tǒng)一管理服務(wù)，或者集群統(tǒng)一管理配置文件也行）；

第四大類：404狀態(tài)碼監(jiān)控。

• 監(jiān)控需求：監(jiān)控http異常狀態(tài)碼。
• 監(jiān)控方案：nginx日志統(tǒng)一監(jiān)控。

如果實(shí)現(xiàn)了http接口統(tǒng)一監(jiān)控，404監(jiān)控的必要性并不是這么強(qiáng)，但畢竟實(shí)現(xiàn)簡(jiǎn)單，整一個(gè)通用的花不了多少時(shí)間。

在聊存活性監(jiān)控，接口處理時(shí)間監(jiān)控之前，多說(shuō)幾句系統(tǒng)架構(gòu)，如果實(shí)現(xiàn)了框架與組件的統(tǒng)一，統(tǒng)一監(jiān)控會(huì)省非常多的力氣。

上圖是一個(gè)典型的互聯(lián)網(wǎng)分層架構(gòu)圖：

• 最上游是APP和browser；
• 反向代理層是nginx，統(tǒng)一http404狀態(tài)碼監(jiān)控就實(shí)現(xiàn)在這一層；
• web層，假設(shè)自研了web-framework；
• service層，假設(shè)自研了service-framework，web層會(huì)通過(guò)RPC-client調(diào)用service；
• 數(shù)據(jù)層db，假設(shè)自研了Daojia-DAO組件調(diào)用db；
• 緩存層cache，假設(shè)自研了Daojia-KV組件調(diào)用cache；

第五大類：服務(wù)存活性監(jiān)控。

監(jiān)控需求：進(jìn)程和端口的監(jiān)控，只能保證進(jìn)程在，端口在，但并不能確定服務(wù)是否能響應(yīng)請(qǐng)求，需要確定服務(wù)“活著”。

監(jiān)控方案：ping-pong式監(jiān)控，在站點(diǎn)框架，服務(wù)框架層面統(tǒng)一實(shí)現(xiàn)，提供keepalive接口：

• 在框架層面就可以實(shí)現(xiàn)ping-pong接口；
• 監(jiān)控中心通過(guò)集群信息管理服務(wù)（或者是配置文件）獲取集群類型（web/service），集群IP列表；
• 監(jiān)控中心統(tǒng)一往集群發(fā)送內(nèi)置的ping-pong請(qǐng)求；

強(qiáng)調(diào)兩點(diǎn)：

• 如果開源框架不提供ping-pong接口，可以二次開發(fā)（要慎重，任何開源框架的二次開發(fā)，都是大坑的開始）；
• 統(tǒng)一集群信息管理服務(wù)，或者，統(tǒng)一集群信息管理配置文件，真的很重要，是技術(shù)體系統(tǒng)一的基石；

第六大類：接口執(zhí)行時(shí)間監(jiān)控。

監(jiān)控需求：

• http站點(diǎn)接口有沒有超時(shí)；
• RPC服務(wù)接口有沒有超時(shí)；
• db訪問(wèn)有沒有超時(shí)；
• cache訪問(wèn)有沒有超時(shí)；
• 除了超時(shí)，還要監(jiān)控同一個(gè)接口的執(zhí)行時(shí)間有沒有同比、環(huán)比的大幅度波動(dòng)；

例如：一個(gè)接口平均響應(yīng)時(shí)間是100ms，突然有一天增加到300ms，即使沒有超時(shí)，也有理由懷疑接口出現(xiàn)了問(wèn)題。

監(jiān)控方案：框架組件統(tǒng)一上報(bào)（如上圖1,2,3,4）：

• 在web-framework里，對(duì)所有http接口進(jìn)行數(shù)據(jù)上報(bào)，可以上報(bào)url，參數(shù)，執(zhí)行時(shí)間等核心數(shù)據(jù)；
• 在service-framework里，對(duì)所有RPC接口進(jìn)行數(shù)據(jù)上報(bào)，可以上報(bào)接口，參數(shù)，執(zhí)行時(shí)間等核心數(shù)據(jù)；
• 在DAO里，對(duì)所有數(shù)據(jù)庫(kù)SQL訪問(wèn)進(jìn)行數(shù)據(jù)上報(bào)，可以上報(bào)sql，參數(shù)，執(zhí)行時(shí)間等核心數(shù)據(jù)；
• 早KV-client里，對(duì)所有cache訪問(wèn)進(jìn)行數(shù)據(jù)上報(bào)，可以上報(bào)key，執(zhí)行時(shí)間等核心數(shù)據(jù)；

統(tǒng)一上報(bào)是思路，具體上報(bào)細(xì)節(jié)，是通過(guò)flume刷日志，還是實(shí)時(shí)流處理，都可以。

總結(jié)

監(jiān)控是一個(gè)技術(shù)活，并不是大家評(píng)論里說(shuō)的“搭一個(gè)ELK就搞定了，何必這么麻煩”。

其中架構(gòu)實(shí)現(xiàn)要點(diǎn)是：

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

知其然，知其所以然。

思路比結(jié)論更重要。