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

一、需求緣起

---

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

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

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

（2）技術反饋“正在跟進”

（3）10分鐘之后，CXO詢問進度，技術反饋“正在解決”

（4）60分鐘之后，CXO說怎么還沒有解決，技術反饋“正在解決”

實際上，可能還沒有找到問題在哪里。

case 2：用戶通過客服反饋功能不可用

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

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

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

可能2個小時過去了，技術還沒有定位到問題在哪一層。

存在的問題：技術被動

（1）出了問題成為最后知曉者，用戶受影響周期長

（2）查找問題路徑長，定位和修復問題時間久，用戶受影響周期長

所有系統(tǒng)負責人能快速回答這兩個問題么

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

（2）如果不正常，問題大致在哪里？

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

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

---

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

回答：監(jiān)控

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

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

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

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

（2）進程、端口層面

（3）日志層面

（4）接口層面

（5）用戶層面

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

---

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

回答：zabbix，用過的都說好

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

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

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

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

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

（1）監(jiān)控中心要實現(xiàn)擴展性較強的配置，方便擴展“監(jiān)控哪個ip上哪個進程或者端口的存活性”

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

匯總型監(jiān)控

命令由agent在各臺機器上執(zhí)行，將結果匯總上報到監(jiān)控中心接口，實現(xiàn)要點：

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

（2）agent如何快速從監(jiān)控中心獲取需要監(jiān)控的進程和端口，必須要保證擴展性

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

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

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

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

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

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

（1）日志分級規(guī)范非常重要，需要進行日志按照級別分離，ERROR日志單獨拿出來一個文件是最好的

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

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

（4）簡易的配置與良好的擴展性，需要支持方面的增加“某一臺機器”“某一個路徑”“ERROR每分鐘超過多少”的報警配置

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

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

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

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

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

統(tǒng)一keepalive接口快速實施要點

（1）在站點框架與服務框架層面統(tǒng)一實現(xiàn)一個keepalive接口

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

（3）簡易的配置與良好的擴展性

接口處理時間統(tǒng)一上報快速實施要點

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

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

（3）或者使用upd上報

（4）時間上報需要異步，不要因為這個而增加業(yè)務處理時間

（5）良好的配置與擴展性，監(jiān)控中心統(tǒng)一配置報警（絕對時間，或者處理時間環(huán)比增長報警）

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

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

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

回答：只有站在調用者的角度，對被調用方的可用性可靠性的評判才是最準確的

思路：模擬調用方調用站點、服務，來對站點和服務進行監(jiān)控

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

如上圖所示，實現(xiàn)“模擬調用方對站點和服務進行監(jiān)控”的分層架構

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

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

監(jiān)控中心：調度發(fā)包層對站點和服務進行監(jiān)控，對結果進行管理，對閾值進行判斷與實施報警

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

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

（2）監(jiān)控項管理：監(jiān)控哪個服務、調度頻率、防抖動配置、責任人

（3）責任人管理：責任人、郵箱、手機號、微信號

（4）調度中心：隔多長時間調度每個監(jiān)控項

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

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

for(每一個監(jiān)控項里被監(jiān)控的服務)｛ // 其實是并行執(zhí)行的，并不是for

         for(這個服務所對應集群里的每個ip)｛
                   調度發(fā)包層，對服務進行發(fā)包；
                   收集發(fā)包層的監(jiān)控結果與異常信息
                   if(異常次數(shù)超過我們設定的閾值){
                            找到服務對應的責任人;
                            異常信息發(fā)短信;
                            發(fā)郵件;
                            發(fā)微信;
           }
         ｝
｝

其他實踐：

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

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

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

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

（5）發(fā)包器的結果校驗要進行業(yè)務校驗，例如一個http請求僅僅檢查返回碼是200是不夠的，還要檢測返回的html或者json的內(nèi)容是更準確的

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

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

“模擬調用方調用站點、服務，來對站點和服務進行監(jiān)控”的方法，可以精確的判斷有問題的是哪一個ip上的哪一個服務上的哪一個接口，理論上應該是粒度最細的監(jiān)控了，為什么還需要用戶視角的監(jiān)控呢？

回答：

（1）架構是做了可用性保證的，一個服務掛了，用戶視角的監(jiān)控沒有報警，說明對用戶沒有影響，如果此時凌晨收到報警，也是不需要馬上起床來處理的

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

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

（1）復用接入層的接口監(jiān)控，只是，不對每一個web-server的站點ip實施監(jiān)控，而是對nginx反向代理層實施監(jiān)控

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

四、總結

---

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

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

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

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

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

（5）模擬調用方調用站點、服務，來對站點和服務進行監(jiān)控

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

回答：只有站在調用者的角度，對被調用方的可用性可靠性的評判才是最準確的