怎樣的監(jiān)控，才真正說明系統(tǒng)有問題？
監(jiān)控不告警，系統(tǒng)就一定沒有問題么?怎樣的監(jiān)控，才真正說明系統(tǒng)有問題?今天和大伙聊聊多維度立體化監(jiān)控。
什么是多維度立體化監(jiān)控?
不同公司或多或少有一些自動化監(jiān)控手段，例如：
- http接口監(jiān)控;
- log關鍵字監(jiān)控;
- 操作系統(tǒng)，進程，端口;
- http狀態(tài)碼;
- 服務存活性;
- 接口處理時間;
- RPC接口監(jiān)控;
- 用戶層面監(jiān)控;
如果只監(jiān)控一個或少數(shù)幾個維度：
- 監(jiān)控到異常時，基本確信系統(tǒng)出現(xiàn)了問題;
- 反過來，沒有監(jiān)控到異常，不能確信系統(tǒng)沒有問題;
例如：
- 監(jiān)控到操作系統(tǒng)CPU100%，系統(tǒng)大概率出現(xiàn)了問題，但CPU正常，并不能說明系統(tǒng)正常，例如tomcat掛了，CPU肯定是正常的，但操作系統(tǒng)監(jiān)控卻探測不到，于是需要進程，端口，存活性等其他監(jiān)控予以輔助;
- 進程，端口監(jiān)控到異常，系統(tǒng)大概率出現(xiàn)了問題，但進程在運行，端口在監(jiān)聽，并不能說明系統(tǒng)正常，例如程序死鎖，進程和端口是正常的，于是需要接口處理時間等其他監(jiān)控予以輔助;
- 接口處理時間監(jiān)控到超時，系統(tǒng)大概率出現(xiàn)了問題，但接口處理時間不超時，并不能說明系統(tǒng)正常，例如數(shù)據(jù)庫掛了，數(shù)據(jù)庫連接拿不到，服務層每個接口都很快返回，并不超時;
這里的觀點是：單維度監(jiān)控易漏報，多維度立體化監(jiān)控才是監(jiān)控平臺的根本之道。
接下來介紹的四個維度的監(jiān)控，在設計上也是看重“通用”“非侵入性”，即被監(jiān)控的站點和服務無需任何埋點，無需任何修改，被監(jiān)控模塊的負責人無需配合做任何事情，就能全方位cover住。
維度一，如何進行操作系統(tǒng)，進程，端口監(jiān)控?
監(jiān)控需求：
- 系統(tǒng)的網絡是否被打滿，磁盤是否有空間，CPU是否繁忙，內存是否用完，負載值是否過高，JVM是否正常;
- 服務進程是否運行;
- 監(jiān)聽端口是否正常;
- 機器間是否聯(lián)通;
常見方案一：zabbix
搞運維的都懂，不展開細聊了，聊多了怕被罵。
常見方案二：shell
寫一些非常簡單的腳本，就能夠獲取到網絡、磁盤、CPU、內存、load、JVM的信息，在配合一些閾值的配置，就能實現(xiàn)超出閾值告警的功能。
如果配合集群信息管理服務，通過ps, netstat, telnet等命令，也能快速實現(xiàn)進程，端口，連通性的簡易監(jiān)控。
實現(xiàn)要點：
- 重點考慮擴展性，可配置性，非侵入性;
- 集群信息管理服務(或者，集群信息配置文件);
維度二，如何進行404狀態(tài)碼監(jiān)控?
監(jiān)控需求：監(jiān)控http異常狀態(tài)碼。
監(jiān)控方案：nginx日志統(tǒng)一監(jiān)控。
如果實現(xiàn)了http接口統(tǒng)一監(jiān)控，404監(jiān)控的必要性并不是這么強，但畢竟實現(xiàn)簡單，整一個通用的花不了多少時間。
在聊存活性監(jiān)控，接口處理時間監(jiān)控之前，多說幾句系統(tǒng)架構，如果實現(xiàn)了框架與組件的統(tǒng)一，統(tǒng)一監(jiān)控會省非常多的力氣。
上圖是一個典型的互聯(lián)網分層架構圖：
- 最上游是APP和browser;
- 反向代理層是nginx，統(tǒng)一http404狀態(tài)碼監(jiān)控就實現(xiàn)在這一層;
- web層，假設自研了web-framework;
- service層，假設自研了service-framework，web層會通過RPC-client調用service;
- 數(shù)據(jù)層db，假設自研了Daojia-DAO組件調用db;
- 緩存層cache，假設自研了Daojia-KV組件調用cache;
D-DAO和D-KV兩個組件并沒有大伙想的復雜，初期只是簡單的封裝了一層而已。
維度三，如何進行服務存活性監(jiān)控?
監(jiān)控需求：進程和端口的監(jiān)控，只能保證進程在，端口在，但并不能確定服務是否能響應請求，需要確定服務“活著”。
監(jiān)控方案：ping-pong式監(jiān)控，在站點框架，服務框架層面統(tǒng)一實現(xiàn)，提供keepalive接口：
- 在框架層面就可以實現(xiàn)ping-pong接口;
- 監(jiān)控中心通過集群信息管理服務(或者是配置文件)獲取集群類型(web/service)，集群IP列表;
- 監(jiān)控中心統(tǒng)一往集群發(fā)送內置的ping-pong請求;
強調兩點：
- 如果開源框架不提供ping-pong接口，可以二次開發(fā)(要慎重，任何開源框架的二次開發(fā)，都是大坑的開始);
- 統(tǒng)一集群信息管理服務，或者，統(tǒng)一集群信息管理配置文件，真的很重要，是技術體系統(tǒng)一的基石;
維度四，如何進行接口執(zhí)行時間監(jiān)控?
監(jiān)控需求：
- http站點接口有沒有超時;
- RPC服務接口有沒有超時;
- db訪問有沒有超時;
- cache訪問有沒有超時;
- 除了超時，還要監(jiān)控同一個接口的執(zhí)行時間有沒有同比、環(huán)比的大幅度波動，例如：一個接口平均響應時間是100ms，突然有一天增加到300ms，即使沒有超時，也有理由懷疑接口出現(xiàn)了問題;
監(jiān)控方案：框架組件統(tǒng)一上報(如上圖1,2,3,4)。
- 在web-framework里，對所有http接口進行數(shù)據(jù)上報，可以上報url，參數(shù)，執(zhí)行時間等核心數(shù)據(jù);
- 在service-framework里，對所有RPC接口進行數(shù)據(jù)上報，可以上報接口，參數(shù)，執(zhí)行時間等核心數(shù)據(jù);
- 在DAO里，對所有數(shù)據(jù)庫SQL訪問進行數(shù)據(jù)上報，可以上報sql，參數(shù)，執(zhí)行時間等核心數(shù)據(jù);
- 在KV-client里，對所有cache訪問進行數(shù)據(jù)上報，可以上報key，執(zhí)行時間等核心數(shù)據(jù);
統(tǒng)一上報是思路，具體上報細節(jié)，是通過flume刷日志，還是storm/spark實時流處理，都可以。
總結
監(jiān)控是一個技術活：
- 監(jiān)控平臺的思路是多維度立體化監(jiān)控;
- “統(tǒng)一操作系統(tǒng)、http404，服務存活性，接口處理時間”等四大類統(tǒng)一監(jiān)控的設計核心是“非侵入性”，不需要任何人配合修改，就能實現(xiàn)諸多功能的技術平臺，才是好技術平臺;
- 統(tǒng)一集群信息管理服務，統(tǒng)一人員信息管理服務，統(tǒng)一告警策略服務(或者配置文件)，是統(tǒng)一技術體系的基石;
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】
