朱曄的網際網路架構實踐心得S1E4：簡單好用的監控六兄弟
這裡所說的六兄弟只指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功能。
有打點、有錯誤日誌、有詳細請求日誌，還怕定位不到問題？