朱曄的互聯網架構實踐心得S1E4：簡單好用的監控六兄弟

朱曄的互聯網架構實踐心得S1E4：簡單好用的監控六兄弟

【下載本文PDF進行閱讀】

這裏所說的六兄弟只指ELK套件（ElasticSearch+Logstash+Kibana）以及TIG套件（Telegraf+InfluxDb+Grafana）。

 

上圖顯示了兩套獨立的體系，ELK和TIG（TIG是我本身編出來的，網上沒有相似於ELK這種約定俗成的說法）：

這兩套體系都由收集器+存儲+展現網站構成，青綠色的收集器，藍綠色的存儲，紅色的展現網站。

這兩套體系都有免費的組件可使用，安裝配置也相對簡單（固然公司也要賺錢，他們確定都主推Cloud版本，通常也不會用Cloud版本，確定本地部署）。

ELK體系更多用於日誌類數據的收集、保存、搜索、查看、報警。

TIG體系更多用於各類Metrics指標類數據的收集、保存、查看、報警。

對於ELK，因爲日誌數據量每每較大，而且突發日誌激增的狀況很廣泛，寫入索引沒有這麼快，因此通常會引入Kafka之類的消息隊列在以前擋一擋。

對於ELK，在進入ES以前數據會有一些過濾解析和額外的報警之類的需求，因此可使用logstash在以前做爲一個匯聚處理層，利用豐富的插件作各類處理。可是logstash的性能不是那麼高，對資源的消耗很厲害，使用的時候須要注意。

 

有關ELK

 

上圖是Kibana的界面，這裏能夠看到咱們把微服務各個組件的日誌都收集到了ES中，在Kibana上可使用表達式進行各類搜索，最經常使用的就是按照串聯微服務整個流程的RequestID或用戶的UserID搜索相關日誌了。不少公司的開發習慣到服務器上去一臺一臺搜索日誌，好一點會用ansible批量搜索，這樣實際上是很是不方便的：

• 文本的搜索會比ES索引數據庫的搜索慢的多。
• 文本的搜索遇到文件大的話，佔用服務器至關多的內存和CPU資源，影響到業務的進行。
• 文件日誌通常會進行歸檔和壓縮，想要搜索非當日的日誌不那麼方便。
• 權限不太好控制，並且原始的文件日誌對外開放查詢的話可能會有安全問題有信息泄露風險。
• 在把數據統一收集到ES的過程當中，咱們能夠作不少額外的工做，包括脫敏，存儲到其它數據源，發郵件和IM通知（好比能夠和Slack或釘釘機器人整合）等等。

 

有關異常

我一直有一個觀點，我認爲再怎麼強調異常都不過度，特別是一直上拋到業務表面的未處理異常以及服務中的系統異常。咱們能夠把異常區分爲業務邏輯主動產生的能夠預先知道是咋回事的業務異常以及沒法預先知道的系統異常。對於系統異常每每意味着底層基礎設施（如網絡、數據庫、中間件）等有抖動或故障或是代碼中有Bug（即便不是Bug也是邏輯不完善的狀況），每個異常，咱們都須要逐一進行排查調查出根本緣由，若是暫時沒有時間調查的話，須要記錄在案有時間再去調查。對於有些業務量特別大的系統，天天會有幾十萬的異常，大概有100+以上的狀況。最差最差那就作到這幾點吧：

• 全面梳理代碼，千萬不要吃掉異常了，每每不少時候Bug沒法找到緣由就是不知道這裏吃掉的究竟是什麼異常。使用ELK咱們能夠很方便搜索過濾日誌，多記一點異常或非正常流程的Error很是有助於咱們修Bug。
• 咱們須要對異常出現的頻次進行監控和報警，好比XXException最近1分鐘有200條異常，時間久了咱們會對這些異常有感受，看到這樣的量咱們知道這必然是抖動，若是出現XXException最近1分鐘有10000條異常，那麼咱們知道這不必定是網絡抖動了，這是依賴服務掛的節奏，立刻須要啓動應急響應的排查流程。
• 確保100%關注和處理好空指針、數組越界、併發錯誤之類的異常，這每個異常基本就是一個Bug了，會致使業務沒法繼續的，有的時候這些異常由於絕對數量小會在衆多異常中埋沒，須要天天單獨看這些異常進行逐一解決。這一個異常若是影響到了一個用戶正常的流程，那麼這個用戶可能就流失了，雖然這一個用戶只是千萬用戶中的一員，可是給這一個用戶帶來的感覺是不好的。我一直以爲咱們要先於用戶發現問題解決問題，最好是等到客服反饋過來的時候（大多數非付費類互聯網產品的用戶不會由於遇到一個阻礙流程的問題去打客服電話，而是選擇放棄這個產品）已是一個帶有修復時間點的已知問題。

作的更好一點甚至咱們能夠爲每個錯誤分配一個ID，若是這個錯誤有機會透傳到用戶這端，在500頁面上不那麼明顯的地方顯示一下這個ID，若是用戶截屏反饋問題的話，能夠輕易經過這個錯誤ID在ELK中找到相應錯誤，一鍵定位問題。

 

有關TIG

 

上圖是Grafana的截圖，Grafana支持挺多數據源，InfluxDb也是其中的一個數據源，相似於InfluxDb的產品還有Graphite，也是不錯的選擇。Telegraf是InfluxDb公司的收集數據的Agent套件，會有至關多的插件，這些插件並不複雜，本身也能夠經過Python簡單編寫，就是有點費時間，有現成的麼就用，說白了就是從各個中間件暴露出來的Stats接口收集格式化數據而後寫入InfluxDb中去。咱們來看看Telegraf支持的插件（圖片截取自https://github.com/influxdata/telegraf）：

 

使用這些插件運維或開發本身不須要費什麼力氣就能夠把咱們全部的基礎組件都監控起來了。

 

有關打點

如文本一開始的架構圖所示，除了咱們可使用Telegraf的各類插件來收集各類存儲、中間件、系統層面的指標以外，咱們還作了一個MetricsClient小類庫，讓程序能夠把各類打點的數據保存到InfluxDb。其實每一條進入InfluxDb的Measurement記錄只是一個事件，有下面這些信息：

• 時間戳
• 各類用於搜索的Tag
• 值（耗時、執行次數）

以下圖咱們能夠看到在這個bankservice中，咱們記錄了各類異步同步操做的成功、業務異常、系統異常事件，而後在Grafana進行簡單的配置，就能夠呈現出須要的圖了。

 

對於MetricsClient，能夠在代碼中手工調用也可使用AOP的方式進行調用，咱們甚至能夠爲全部方法加上這個關注點，自動收集方法的執行次數、時間、結果（正常、業務異常、系統異常）打點記錄到InfluxDb中，而後在Grafana配置本身須要的Dashboard用於監控。

對於RPC框架也是建議框架內部自動整合打點的，保存RPC方法每次執行的狀況，細化到方法的粒度配置出一些圖表來，在出現事故的時候一鍵定位到疑似出問題的方法。經過AOP方+RPC框架自動打點其實已經能夠覆蓋大部分需求了，固然若是咱們在代碼中再加一些業務層面的打點就更好了。

若是咱們爲每個業務行爲，配置兩個圖，一個是調用量，一個是調用性能，以下圖：

 

那麼：

• 出現問題的時候，咱們能夠在很短的時間內判斷出哪塊有問題。
• 還能夠初步判斷出問題的緣由是異常致使仍是突增的壓力所致。

這裏推薦的配置方式是根據數據流，從前到後，每個環節配置一下數據處理的數量和性能：

• 上游進來的數據
• 發送到MQ的數據
• MQ接收到的數據
• MQ處理完成的數據
• 和外部交互的請求
• 獲得外部響應的請求
• 落庫的請求
• 查緩存的請求

出了問題能夠及時定位到出問題的模塊，或至少是業務線，會比無頭蒼蠅好不少（固然，若是咱們沒有事先配置本身須要的Dashboard那也是白搭）。Dashboard必定是須要隨着業務的迭代不斷去維護的，別通過幾輪迭代以前的打點早已廢棄，到出了問題的時候再看Dashboard全是0調用。

 

其它

 

Grafana對接InfluxDb數據源挺好的，可是對接MySQL作一些查詢總感受不是特別方便，這裏推薦一個開源的系統Metabase，咱們能夠方便得保存一些SQL進行作一些業務或監控之類的統計。你可能會說了，這些業務統計是運營關注的，並且咱們由BI，咱們須要本身作這些圖表幹啥，我想說咱們即便搞技術也最好有一個本身的小業務面板，不是說關注業務量而是能有一個地方讓咱們知道業務跑的狀況，在關鍵的時候看一眼判斷一下影響範圍。

 

好了，說到這裏，你是否已看到了經過這六兄弟，其實咱們打造的是一個立體化的監控體系，分享一個排查問題的幾步走方式吧，畢竟在出大問題的時候咱們的時間每每就只有那麼幾分鐘：

• 關注異常或系統層面的壓力報警，關注業務量掉0（指的是忽然下落30%以上）報警。
• 經過Grafana面板配置的業務Dashboard判斷系統哪一個模塊有壓力問題、性能問題。
• 經過Grafana面板配置的服務調用量和業務進出量，排除上下游問題，定位出問題的模塊。
• 經過Kibana查看相應模塊是否出現錯誤或異常。
• 根據客戶反饋的錯誤截屏，找到錯誤ID，在Kibana中搜索全鏈路日誌找問題。
• 對於細節問題，還有一招就是查請求日誌了。咱們能夠在Web端的系統作一個開關，根據必定的條件能夠開啓記錄詳細的Request和Response HTTP Log的開關，有了每個請求詳細的數據，咱們能夠根據用戶信息「看到」用戶訪問網站的整個過程，這很是有助於咱們排查問題。固然，這個數據量可能會很是大，因此須要慎重開啓這麼重的Trace功能。

有打點、有錯誤日誌、有詳細請求日誌，還怕定位不到問題？