本文內容：創業型公司如何快速搭建可擴展，可落地的立體化監控平臺

一、需求緣起

創業型公司有系統監控麽？來看兩個case：

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

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

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

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

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

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

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

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

（2）客服 -> 產品 -> 測試 -> 技術

（3）技術：站點層 -> 服務層1 -> 服務層2 -> 數據層

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

存在的問題：技術被動

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

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

所有系統負責人能快速回答這兩個問題麽

（1）所負責的系統現在運行是否正常？

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

今天的主題是“創業型公司如何快速解決這兩個問題”

二、解決方案：立體化監控

怎麽知道系統運行是否正常？

回答：監控

什麽是立體化監控？

回答：多維度監控

監控維度有哪些？

回答：（1）機器、操作系統層面

（2）進程、端口層面

（3）日誌層面

（4）接口層面

（5）用戶層面

三、創業型公司如何快速實現立體化監控

【如可快速實現機器、操作系統級別的監控？】

回答：zabbix，用過的都說好

不足：CPU，LOAD，內存，網絡，磁盤異常說明系統一定異常，但這些參數正常並不能說明系統正常，例如：進程掛了，端口掛了，通過這些參數就檢測不到

【如何快速實現進程、端口級別的監控？】

兩類實現思路：分發型監控 + 匯總型監控

分發型監控

命令由監控中心分發到各個被監控機器的agent上，agent執行監控，實現要點：

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

（2）對於進程與端口的監控，甚至無需agent來執行，直接使用帶超時的端口連接或者telnet就能快速實現

匯總型監控

命令由agent在各臺機器上執行，將結果匯總上報到監控中心接口，實現要點：

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

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

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

進程與端口監控的不足：進程與端口異常說明系統一定異常，但它們正常並不能說明系統正常，例如：進程和端口都在，但ERROR日誌狂刷

【如何快速實現日誌的監控？】

兩類實現思路：ERROR日誌的監控 + 日誌關鍵字監控

這兩類實現又有“日誌各機器單獨監控”與“日誌匯總到中心監控”兩種方法，暫時不展開。

ERROR日誌監控快速實施要點

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

（2）日誌切分規範也很重要，建議按照小時切分

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

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

日誌關鍵字監控

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

ERROR日誌監控與日誌關鍵字監控的不足：ERROR日誌超過閾值說明系統一定異常，不超過閾值並不能說明系統正常，例如：進程死鎖，此時並不會刷ERROR日誌

【如何快速實現接口的監控】

有兩種常見的快速實現思路：統一keepalive接口 + 接口處理時間統一上報

統一keepalive接口快速實施要點

（1）在站點框架與服務框架層面統一實現一個keepalive接口

（2）監控中心統一調用站點、服務的keepalive接口

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

接口處理時間統一上報快速實施要點

（1）在站點框架和服務框架層面統一實現處理時間的收集

（2）由於並發量很大，需要在本地進行初步匯總

（3）或者使用upd上報

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

（5）良好的配置與擴展性，監控中心統一配置報警（絕對時間，或者處理時間環比增長報警）

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

【到底什麽樣的監控，才能說明系統是正常的呢？】

郁悶了，上述多個維度的監控，都不能完全說明系統正常，怎麽辦？

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

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

通用接口監控分層架構圖

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

被監控層：被監控的站點和服務，例如A，B，C

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

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

監控中心又分為這麽幾個部分：

（1）集群管理：每個被監控服務有哪些ip

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

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

（4）調度中心：隔多長時間調度每個監控項

（5）發包層通信：獲取發包層的監控結果與異常信息

監控流程，用偽代碼描述吧：

for(每一個監控項裏被監控的服務)｛ // 其實是並行執行的，並不是for

for(這個服務所對應集群裏的每個ip)｛

調度發包層，對服務進行發包；

收集發包層的監控結果與異常信息

if(異常次數超過我們設定的閾值){

找到服務對應的責任人;

異常信息發短信;

發郵件;

發微信;

}

｝

｝

其他實踐：

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

（2）寫接口可能會對數據產生汙染，建議選取讀接口進行監控

（3）如果一定要對寫接口進行監控，務必插入操作和刪除操作要是成對進行的（還是會對業務數據統計產生汙染）

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

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

【什麽樣的監控，能決定淩晨收到報警而不起床處理呢？】

回答：用戶視角的監控

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

回答：

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

（2）用戶是在全國各地進行訪問的，很有可能某個地域的網絡出問題，此時只有在全國布點的用戶視角監控才能發現

如何快速的實施用戶視角的監控：

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

（2）引入第三方監控

四、總結

創業型公司快速實施立體化多維度監控總結：

（1）機器、操作系統維度監控：zabbix

（2）進程、端口維度監控：分發型監控 + 匯總型監控

（3）錯誤日誌與關鍵字維度監控

（4）keepalive接口與所有接口統一處理時間統一上報監控

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

以上內容均來自微信公眾號“架構師之路”胡劍老師的文章，歡迎關註。

創業公司快速搭建立體化監控之路（WOT2016）