摘要：還可以初步判斷出問題的原因是異常導致還是突增的壓力所致。通過面板配置的服務調用量和業務進出量，排除上下游問題，定位出問題的模塊。

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

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

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

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

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

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

對于ELK，由于日志數據量往往較大，并且突發日志激增的情況很普遍，寫入索引沒有這么快，所以一般會引入Kafka之類的消息隊列在之前擋一擋。

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

上圖是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中找到相應錯誤，一鍵定位問題。

.]

上圖是Grafana的截圖，Grafana支持挺多數據源，InfluxDb也是其中的一個數據源，類似于InfluxDb的產品還有Graphite，也是不錯的選擇。Telegraf是InfluxDb公司的收集數據的Agent套件，會有相當多的插件，這些插件并不復雜，自己也可以通過Python簡單編寫，就是有點費時間，有現成的么就用，說白了就是從各個中間件暴露出來的Stats接口收集格式化數據然后寫入InfluxDb中去。我們來看看Telegraf支持的插件（圖片截取自https://github.com/influxdata...）：

使用這些插件運維或開發自己不需要費什么力氣就可以把我們所有的基礎組件都監控起來了。

有關打點
如文本一開始的架構圖所示，除了我們可以使用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功能。

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