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

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

 

1、需求緣起

創業型公司有系統監控麼？來看兩個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）若是不正常，問題大體在哪裏？

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

 

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

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

回答：監控

什麼是立體化監控？

回答：多維度監控

監控維度有哪些？

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

（2）進程、端口層面

（3）日誌層面

（4）接口層面

（5）用戶層面

 

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

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

回答：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）引入第三方監控

 

4、總結

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

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

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

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

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

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

 

以上內容均來自微信公衆號「架構師之路」胡劍老師的文章，歡迎關注。