創(chuàng)業(yè)公司快速搭建立體化監(jiān)控之路（WOT2016）

本文內(nèi)容：創(chuàng)業(yè)型公司如何快速搭建可擴(kuò)展，可落地的立體化監(jiān)控平臺(tái)

一、需求緣起

---

創(chuàng)業(yè)型公司有系統(tǒng)監(jiān)控么？來(lái)看兩個(gè)case：

case 1：CXO大群內(nèi)貼了一張“用戶微信投訴”的截圖

（1）CXO大群內(nèi)貼了一張“用戶微信投訴”的截圖

（2）技術(shù)反饋“正在跟進(jìn)”

（3）10分鐘之后，CXO詢問(wèn)進(jìn)度，技術(shù)反饋“正在解決”

（4）60分鐘之后，CXO說(shuō)怎么還沒(méi)有解決，技術(shù)反饋“正在解決”

實(shí)際上，可能還沒(méi)有找到問(wèn)題在哪里。

case 2：用戶通過(guò)客服反饋功能不可用

（1）用戶反饋到客服，不能下單

（2）客服 -> 產(chǎn)品 -> 測(cè)試 -> 技術(shù)

（3）技術(shù)：站點(diǎn)層 -> 服務(wù)層1 -> 服務(wù)層2 -> 數(shù)據(jù)層

可能2個(gè)小時(shí)過(guò)去了，技術(shù)還沒(méi)有定位到問(wèn)題在哪一層。

存在的問(wèn)題：技術(shù)被動(dòng)

（1）出了問(wèn)題成為最后知曉者，用戶受影響周期長(zhǎng)

（2）查找問(wèn)題路徑長(zhǎng)，定位和修復(fù)問(wèn)題時(shí)間久，用戶受影響周期長(zhǎng)

所有系統(tǒng)負(fù)責(zé)人能快速回答這兩個(gè)問(wèn)題么

（1）所負(fù)責(zé)的系統(tǒng)現(xiàn)在運(yùn)行是否正常？

（2）如果不正常，問(wèn)題大致在哪里？

今天的主題是“創(chuàng)業(yè)型公司如何快速解決這兩個(gè)問(wèn)題”

二、解決方案：立體化監(jiān)控

---

怎么知道系統(tǒng)運(yùn)行是否正常？

回答：監(jiān)控

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

回答：多維度監(jiān)控

監(jiān)控維度有哪些？

回答：（1）機(jī)器、操作系統(tǒng)層面

（2）進(jìn)程、端口層面

（3）日志層面

（4）接口層面

（5）用戶層面

三、創(chuàng)業(yè)型公司如何快速實(shí)現(xiàn)立體化監(jiān)控

---

【如可快速實(shí)現(xiàn)機(jī)器、操作系統(tǒng)級(jí)別的監(jiān)控？】

回答：zabbix，用過(guò)的都說(shuō)好

不足：CPU，LOAD，內(nèi)存，網(wǎng)絡(luò)，磁盤異常說(shuō)明系統(tǒng)一定異常，但這些參數(shù)正常并不能說(shuō)明系統(tǒng)正常，例如：進(jìn)程掛了，端口掛了，通過(guò)這些參數(shù)就檢測(cè)不到

【如何快速實(shí)現(xiàn)進(jìn)程、端口級(jí)別的監(jiān)控？】

兩類實(shí)現(xiàn)思路：分發(fā)型監(jiān)控 + 匯總型監(jiān)控

分發(fā)型監(jiān)控

命令由監(jiān)控中心分發(fā)到各個(gè)被監(jiān)控機(jī)器的agent上，agent執(zhí)行監(jiān)控，實(shí)現(xiàn)要點(diǎn)：

（1）監(jiān)控中心要實(shí)現(xiàn)擴(kuò)展性較強(qiáng)的配置，方便擴(kuò)展“監(jiān)控哪個(gè)ip上哪個(gè)進(jìn)程或者端口的存活性”

（2）對(duì)于進(jìn)程與端口的監(jiān)控，甚至無(wú)需agent來(lái)執(zhí)行，直接使用帶超時(shí)的端口連接或者telnet就能快速實(shí)現(xiàn) 

匯總型監(jiān)控

命令由agent在各臺(tái)機(jī)器上執(zhí)行，將結(jié)果匯總上報(bào)到監(jiān)控中心接口，實(shí)現(xiàn)要點(diǎn)：

（1）agent必須能夠快速部署到所有的機(jī)器

（2）agent如何快速?gòu)谋O(jiān)控中心獲取需要監(jiān)控的進(jìn)程和端口，必須要保證擴(kuò)展性

（3）agent如何快速的執(zhí)行本地檢測(cè)，例如：進(jìn)程監(jiān)控用ps？端口監(jiān)控用netstat？

進(jìn)程與端口監(jiān)控的不足：進(jìn)程與端口異常說(shuō)明系統(tǒng)一定異常，但它們正常并不能說(shuō)明系統(tǒng)正常，例如：進(jìn)程和端口都在，但ERROR日志狂刷

【如何快速實(shí)現(xiàn)日志的監(jiān)控？】

兩類實(shí)現(xiàn)思路：ERROR日志的監(jiān)控 + 日志關(guān)鍵字監(jiān)控

這兩類實(shí)現(xiàn)又有“日志各機(jī)器單獨(dú)監(jiān)控”與“日志匯總到中心監(jiān)控”兩種方法，暫時(shí)不展開(kāi)。

ERROR日志監(jiān)控快速實(shí)施要點(diǎn)

（1）日志分級(jí)規(guī)范非常重要，需要進(jìn)行日志按照級(jí)別分離，ERROR日志單獨(dú)拿出來(lái)一個(gè)文件是最好的

（2）日志切分規(guī)范也很重要，建議按照小時(shí)切分

（3）1和2的目的，是為了保證擴(kuò)展性，并減少掃描的日志量，做到了1和2之后，例如用一個(gè)crontab，設(shè)定一定閾值，每分鐘wc -l ERROR文件，超過(guò)閾值就可以報(bào)警

（4）簡(jiǎn)易的配置與良好的擴(kuò)展性，需要支持方面的增加“某一臺(tái)機(jī)器”“某一個(gè)路徑”“ERROR每分鐘超過(guò)多少”的報(bào)警配置

日志關(guān)鍵字監(jiān)控

和ERROR日志監(jiān)控的思路是類似的，當(dāng)日志中出現(xiàn)一些事先設(shè)定的關(guān)鍵字（或者出現(xiàn)頻率超過(guò)一定閾值），例如exception、timeout就報(bào)警，這種報(bào)警能夠報(bào)出比ERROR更精準(zhǔn)的系統(tǒng)異常

ERROR日志監(jiān)控與日志關(guān)鍵字監(jiān)控的不足：ERROR日志超過(guò)閾值說(shuō)明系統(tǒng)一定異常，不超過(guò)閾值并不能說(shuō)明系統(tǒng)正常，例如：進(jìn)程死鎖，此時(shí)并不會(huì)刷ERROR日志

【如何快速實(shí)現(xiàn)接口的監(jiān)控】

有兩種常見(jiàn)的快速實(shí)現(xiàn)思路：統(tǒng)一keepalive接口 + 接口處理時(shí)間統(tǒng)一上報(bào)

統(tǒng)一keepalive接口快速實(shí)施要點(diǎn)

（1）在站點(diǎn)框架與服務(wù)框架層面統(tǒng)一實(shí)現(xiàn)一個(gè)keepalive接口

（2）監(jiān)控中心統(tǒng)一調(diào)用站點(diǎn)、服務(wù)的keepalive接口

（3）簡(jiǎn)易的配置與良好的擴(kuò)展性

接口處理時(shí)間統(tǒng)一上報(bào)快速實(shí)施要點(diǎn)

（1）在站點(diǎn)框架和服務(wù)框架層面統(tǒng)一實(shí)現(xiàn)處理時(shí)間的收集

（2）由于并發(fā)量很大，需要在本地進(jìn)行初步匯總

（3）或者使用upd上報(bào)

（4）時(shí)間上報(bào)需要異步，不要因?yàn)檫@個(gè)而增加業(yè)務(wù)處理時(shí)間

（5）良好的配置與擴(kuò)展性，監(jiān)控中心統(tǒng)一配置報(bào)警（絕對(duì)時(shí)間，或者處理時(shí)間環(huán)比增長(zhǎng)報(bào)警）

統(tǒng)一keepalive接口與接口處理時(shí)間統(tǒng)一上報(bào)的不足：上報(bào)異常說(shuō)明系統(tǒng)一定異常，上報(bào)正常不能說(shuō)明系統(tǒng)正常，例如：某個(gè)服務(wù)后端的數(shù)據(jù)庫(kù)掛了，此時(shí)這個(gè)服務(wù)的keepalive接口返回其實(shí)是正常的，接口的處理時(shí)間可能會(huì)比平常要快很多（原來(lái)數(shù)據(jù)庫(kù)還要執(zhí)行一個(gè)sql，現(xiàn)在連接都拿不到，立馬就返回了）

【到底什么樣的監(jiān)控，才能說(shuō)明系統(tǒng)是正常的呢？】

郁悶了，上述多個(gè)維度的監(jiān)控，都不能完全說(shuō)明系統(tǒng)正常，怎么辦？

回答：只有站在調(diào)用者的角度，對(duì)被調(diào)用方的可用性可靠性的評(píng)判才是最準(zhǔn)確的

思路：模擬調(diào)用方調(diào)用站點(diǎn)、服務(wù)，來(lái)對(duì)站點(diǎn)和服務(wù)進(jìn)行監(jiān)控

通用接口監(jiān)控分層架構(gòu)圖

如上圖所示，實(shí)現(xiàn)“模擬調(diào)用方對(duì)站點(diǎn)和服務(wù)進(jìn)行監(jiān)控”的分層架構(gòu)

被監(jiān)控層：被監(jiān)控的站點(diǎn)和服務(wù)，例如A，B，C

發(fā)包層：模擬站點(diǎn)和服務(wù)調(diào)用方的發(fā)包器，例如A-sender，B-sender，C-sender

監(jiān)控中心：調(diào)度發(fā)包層對(duì)站點(diǎn)和服務(wù)進(jìn)行監(jiān)控，對(duì)結(jié)果進(jìn)行管理，對(duì)閾值進(jìn)行判斷與實(shí)施報(bào)警

監(jiān)控中心又分為這么幾個(gè)部分：

（1）集群管理：每個(gè)被監(jiān)控服務(wù)有哪些ip

（2）監(jiān)控項(xiàng)管理：監(jiān)控哪個(gè)服務(wù)、調(diào)度頻率、防抖動(dòng)配置、責(zé)任人

（3）責(zé)任人管理：責(zé)任人、郵箱、手機(jī)號(hào)、微信號(hào)

（4）調(diào)度中心：隔多長(zhǎng)時(shí)間調(diào)度每個(gè)監(jiān)控項(xiàng)

（5）發(fā)包層通信：獲取發(fā)包層的監(jiān)控結(jié)果與異常信息

監(jiān)控流程，用偽代碼描述吧：

for(每一個(gè)監(jiān)控項(xiàng)里被監(jiān)控的服務(wù))｛ // 其實(shí)是并行執(zhí)行的，并不是for

         for(這個(gè)服務(wù)所對(duì)應(yīng)集群里的每個(gè)ip)｛
                   調(diào)度發(fā)包層，對(duì)服務(wù)進(jìn)行發(fā)包；
                   收集發(fā)包層的監(jiān)控結(jié)果與異常信息
                   if(異常次數(shù)超過(guò)我們?cè)O(shè)定的閾值){
                            找到服務(wù)對(duì)應(yīng)的責(zé)任人;
                            異常信息發(fā)短信;
                            發(fā)郵件;
                            發(fā)微信;
           }
         ｝
｝

其他實(shí)踐：

（1）一個(gè)服務(wù)提供的接口很多，可以選取最核心的接口進(jìn)行發(fā)包監(jiān)控

（2）寫接口可能會(huì)對(duì)數(shù)據(jù)產(chǎn)生污染，建議選取讀接口進(jìn)行監(jiān)控

（3）如果一定要對(duì)寫接口進(jìn)行監(jiān)控，務(wù)必插入操作和刪除操作要是成對(duì)進(jìn)行的（還是會(huì)對(duì)業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)產(chǎn)生污染）

（4）發(fā)包層的sender程序可以復(fù)用接口測(cè)試的代碼

（5）發(fā)包器的結(jié)果校驗(yàn)要進(jìn)行業(yè)務(wù)校驗(yàn)，例如一個(gè)http請(qǐng)求僅僅檢查返回碼是200是不夠的，還要檢測(cè)返回的html或者json的內(nèi)容是更準(zhǔn)確的

【什么樣的監(jiān)控，能決定凌晨收到報(bào)警而不起床處理呢？】

回答：用戶視角的監(jiān)控

“模擬調(diào)用方調(diào)用站點(diǎn)、服務(wù)，來(lái)對(duì)站點(diǎn)和服務(wù)進(jìn)行監(jiān)控”的方法，可以精確的判斷有問(wèn)題的是哪一個(gè)ip上的哪一個(gè)服務(wù)上的哪一個(gè)接口，理論上應(yīng)該是粒度最細(xì)的監(jiān)控了，為什么還需要用戶視角的監(jiān)控呢？

回答：

（1）架構(gòu)是做了可用性保證的，一個(gè)服務(wù)掛了，用戶視角的監(jiān)控沒(méi)有報(bào)警，說(shuō)明對(duì)用戶沒(méi)有影響，如果此時(shí)凌晨收到報(bào)警，也是不需要馬上起床來(lái)處理的

（2）用戶是在全國(guó)各地進(jìn)行訪問(wèn)的，很有可能某個(gè)地域的網(wǎng)絡(luò)出問(wèn)題，此時(shí)只有在全國(guó)布點(diǎn)的用戶視角監(jiān)控才能發(fā)現(xiàn)

如何快速的實(shí)施用戶視角的監(jiān)控：

（1）復(fù)用接入層的接口監(jiān)控，只是，不對(duì)每一個(gè)web-server的站點(diǎn)ip實(shí)施監(jiān)控，而是對(duì)nginx反向代理層實(shí)施監(jiān)控

（2）引入第三方監(jiān)控

四、總結(jié)

---

創(chuàng)業(yè)型公司快速實(shí)施立體化多維度監(jiān)控總結(jié)：

（1）機(jī)器、操作系統(tǒng)維度監(jiān)控：zabbix

（2）進(jìn)程、端口維度監(jiān)控：分發(fā)型監(jiān)控 + 匯總型監(jiān)控

（3）錯(cuò)誤日志與關(guān)鍵字維度監(jiān)控

（4）keepalive接口與所有接口統(tǒng)一處理時(shí)間統(tǒng)一上報(bào)監(jiān)控

（5）模擬調(diào)用方調(diào)用站點(diǎn)、服務(wù)，來(lái)對(duì)站點(diǎn)和服務(wù)進(jìn)行監(jiān)控

到底什么樣的監(jiān)控，才能說(shuō)明系統(tǒng)是正常的呢？

回答：只有站在調(diào)用者的角度，對(duì)被調(diào)用方的可用性可靠性的評(píng)判才是最準(zhǔn)確的