摘要：還可以初步判斷出問題的原因是異常導(dǎo)致還是突增的壓力所致。通過面板配置的服務(wù)調(diào)用量和業(yè)務(wù)進(jìn)出量，排除上下游問題，定位出問題的模塊。

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

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

這兩套體系都由收集器+存儲+展示網(wǎng)站構(gòu)成，青綠色的收集器，藍(lán)綠色的存儲，紅色的展示網(wǎng)站。

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

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

TIG體系更多用于各種Metrics指標(biāo)類數(shù)據(jù)的收集、保存、查看、報警。

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

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

上圖是Kibana的界面，這里可以看到我們把微服務(wù)各個組件的日志都收集到了ES中，在Kibana上可以使用表達(dá)式進(jìn)行各種搜索，最常用的就是按照串聯(lián)微服務(wù)整個流程的RequestID或用戶的UserID搜索相關(guān)日志了。很多公司的開發(fā)習(xí)慣到服務(wù)器上去一臺一臺搜索日志，好一點會用ansible批量搜索，這樣其實是非常不方便的：

· 文本的搜索會比ES索引數(shù)據(jù)庫的搜索慢的多。

· 文本的搜索遇到文件大的話，占用服務(wù)器相當(dāng)多的內(nèi)存和CPU資源，影響到業(yè)務(wù)的進(jìn)行。

· 文件日志一般會進(jìn)行歸檔和壓縮，想要搜索非當(dāng)日的日志不那么方便。

· 權(quán)限不太好控制，而且原始的文件日志對外開放查詢的話可能會有安全問題有信息泄露風(fēng)險。

· 在把數(shù)據(jù)統(tǒng)一收集到ES的過程中，我們可以做很多額外的工作，包括脫敏，存儲到其它數(shù)據(jù)源，發(fā)郵件和IM通知（比如可以和Slack或釘釘機器人整合）等等。

我一直有一個觀點，我認(rèn)為再怎么強調(diào)異常都不過分，特別是一直上拋到業(yè)務(wù)表面的未處理異常以及服務(wù)中的系統(tǒng)異常。我們可以把異常區(qū)分為業(yè)務(wù)邏輯主動產(chǎn)生的可以預(yù)先知道是咋回事的業(yè)務(wù)異常以及無法預(yù)先知道的系統(tǒng)異常。對于系統(tǒng)異常往往意味著底層基礎(chǔ)設(shè)施（如網(wǎng)絡(luò)、數(shù)據(jù)庫、中間件）等有抖動或故障或是代碼中有Bug（即使不是Bug也是邏輯不完善的情況），每一個異常，我們都需要逐一進(jìn)行排查調(diào)查出根本原因，如果暫時沒有時間調(diào)查的話，需要記錄在案有時間再去調(diào)查。對于有些業(yè)務(wù)量特別大的系統(tǒng)，每天會有幾十萬的異常，大概有100+以上的情況。最差最差那就做到這幾點吧：

· 全面梳理代碼，千萬不要吃掉異常了，往往很多時候Bug無法找到原因就是不知道這里吃掉的到底是什么異常。使用ELK我們可以很方便搜索過濾日志，多記一點異?；蚍钦Ａ鞒痰腅rror非常有助于我們修Bug。

· 我們需要對異常出現(xiàn)的頻次進(jìn)行監(jiān)控和報警，比如XXException最近1分鐘有200條異常，時間久了我們會對這些異常有感覺，看到這樣的量我們知道這必然是抖動，如果出現(xiàn)XXException最近1分鐘有10000條異常，那么我們知道這不一定是網(wǎng)絡(luò)抖動了，這是依賴服務(wù)掛的節(jié)奏，馬上需要啟動應(yīng)急響應(yīng)的排查流程。

· 確保100%關(guān)注和處理好空指針、數(shù)組越界、并發(fā)錯誤之類的異常，這每一個異?；揪褪且粋€Bug了，會導(dǎo)致業(yè)務(wù)無法繼續(xù)的，有的時候這些異常因為絕對數(shù)量小會在眾多異常中埋沒，需要每天多帶帶看這些異常進(jìn)行逐一解決。這一個異常如果影響到了一個用戶正常的流程，那么這個用戶可能就流失了，雖然這一個用戶只是千萬用戶中的一員，但是給這一個用戶帶來的感受是很差的。我一直覺得我們要先于用戶發(fā)現(xiàn)問題解決問題，最好是等到客服反饋過來的時候（大多數(shù)非付費類互聯(lián)網(wǎng)產(chǎn)品的用戶不會因為遇到一個阻礙流程的問題去打客服電話，而是選擇放棄這個產(chǎn)品）已經(jīng)是一個帶有修復(fù)時間點的已知問題。

做的更好一點甚至我們可以為每一個錯誤分配一個ID，如果這個錯誤有機會透傳到用戶這端，在500頁面上不那么明顯的地方顯示一下這個ID，如果用戶截屏反饋問題的話，可以輕易通過這個錯誤ID在ELK中找到相應(yīng)錯誤，一鍵定位問題。

.]

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

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

有關(guān)打點
如文本一開始的架構(gòu)圖所示，除了我們可以使用Telegraf的各種插件來收集各種存儲、中間件、系統(tǒng)層面的指標(biāo)之外，我們還做了一個MetricsClient小類庫，讓程序可以把各種打點的數(shù)據(jù)保存到InfluxDb。其實每一條進(jìn)入InfluxDb的Measurement記錄只是一個事件，有下面這些信息：

· 時間戳

· 各種用于搜索的Tag

· 值（耗時、執(zhí)行次數(shù)）

如下圖我們可以看到在這個bankservice中，我們記錄了各種異步同步操作的成功、業(yè)務(wù)異常、系統(tǒng)異常事件，然后在Grafana進(jìn)行簡單的配置，就可以呈現(xiàn)出需要的圖了。

對于MetricsClient，可以在代碼中手工調(diào)用也可以使用AOP的方式進(jìn)行調(diào)用，我們甚至可以為所有方法加上這個關(guān)注點，自動收集方法的執(zhí)行次數(shù)、時間、結(jié)果（正常、業(yè)務(wù)異常、系統(tǒng)異常）打點記錄到InfluxDb中，然后在Grafana配置自己需要的Dashboard用于監(jiān)控。

對于RPC框架也是建議框架內(nèi)部自動整合打點的，保存RPC方法每次執(zhí)行的情況，細(xì)化到方法的粒度配置出一些圖表來，在出現(xiàn)事故的時候一鍵定位到疑似出問題的方法。通過AOP方+RPC框架自動打點其實已經(jīng)可以覆蓋大部分需求了，當(dāng)然如果我們在代碼中再加一些業(yè)務(wù)層面的打點就更好了。

如果我們?yōu)槊恳粋€業(yè)務(wù)行為，配置兩個圖，一個是調(diào)用量，一個是調(diào)用性能，如下圖：

那么：

· 出現(xiàn)問題的時候，我們可以在很短的時間內(nèi)判斷出哪塊有問題。

· 還可以初步判斷出問題的原因是異常導(dǎo)致還是突增的壓力所致。

這里推薦的配置方式是根據(jù)數(shù)據(jù)流，從前到后，每一個環(huán)節(jié)配置一下數(shù)據(jù)處理的數(shù)量和性能：

· 上游進(jìn)來的數(shù)據(jù)

· 發(fā)送到MQ的數(shù)據(jù)

· MQ接收到的數(shù)據(jù)

· MQ處理完成的數(shù)據(jù)

· 和外部交互的請求

· 得到外部響應(yīng)的請求

· 落庫的請求

· 查緩存的請求

出了問題可以及時定位到出問題的模塊，或至少是業(yè)務(wù)線，會比無頭蒼蠅好很多（當(dāng)然，如果我們沒有事先配置自己需要的Dashboard那也是白搭）。Dashboard一定是需要隨著業(yè)務(wù)的迭代不斷去維護的，別經(jīng)過幾輪迭代之前的打點早已廢棄，到出了問題的時候再看Dashboard全是0調(diào)用。

Grafana對接InfluxDb數(shù)據(jù)源挺好的，但是對接MySQL做一些查詢總感覺不是特別方便，這里推薦一個開源的系統(tǒng)Metabase，我們可以方便得保存一些SQL進(jìn)行做一些業(yè)務(wù)或監(jiān)控之類的統(tǒng)計。你可能會說了，這些業(yè)務(wù)統(tǒng)計是運營關(guān)注的，而且我們由BI，我們需要自己做這些圖表干啥，我想說我們即使搞技術(shù)也最好有一個自己的小業(yè)務(wù)面板，不是說關(guān)注業(yè)務(wù)量而是能有一個地方讓我們知道業(yè)務(wù)跑的情況，在關(guān)鍵的時候看一眼判斷一下影響范圍。

好了，說到這里，你是否已看到了通過這六兄弟，其實我們打造的是一個立體化的監(jiān)控體系，分享一個排查問題的幾步走方式吧，畢竟在出大問題的時候我們的時間往往就只有那么幾分鐘：

· 關(guān)注異?；蛳到y(tǒng)層面的壓力報警，關(guān)注業(yè)務(wù)量掉0（指的是突然下落30%以上）報警。

· 通過Grafana面板配置的業(yè)務(wù)Dashboard判斷系統(tǒng)哪個模塊有壓力問題、性能問題。

· 通過Grafana面板配置的服務(wù)調(diào)用量和業(yè)務(wù)進(jìn)出量，排除上下游問題，定位出問題的模塊。

· 通過Kibana查看相應(yīng)模塊是否出現(xiàn)錯誤或異常。

· 根據(jù)客戶反饋的錯誤截屏，找到錯誤ID，在Kibana中搜索全鏈路日志找問題。

· 對于細(xì)節(jié)問題，還有一招就是查請求日志了。我們可以在Web端的系統(tǒng)做一個開關(guān)，根據(jù)一定的條件可以開啟記錄詳細(xì)的Request和Response HTTP Log的開關(guān)，有了每一個請求詳細(xì)的數(shù)據(jù)，我們可以根據(jù)用戶信息“看到”用戶訪問網(wǎng)站的整個過程，這非常有助于我們排查問題。當(dāng)然，這個數(shù)據(jù)量可能會非常大，所以需要慎重開啟這么重的Trace功能。

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