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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· 全面梳理代碼，千萬不要吃掉異常了，往往很多時(shí)候Bug無法找到原因就是不知道這里吃掉的到底是什么異常。使用ELK我們可以很方便搜索過濾日志，多記一點(diǎn)異常或非正常流程的Error非常有助于我們修Bug。

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

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

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

.]

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

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

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

· 時(shí)間戳

· 各種用于搜索的Tag

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

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

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

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

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

那么：

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

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

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

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

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

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

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

· 和外部交互的請(qǐng)求

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

· 落庫的請(qǐng)求

· 查緩存的請(qǐng)求

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

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

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

· 關(guān)注異常或系統(tǒng)層面的壓力報(bào)警，關(guān)注業(yè)務(wù)量掉0（指的是突然下落30%以上）報(bào)警。

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

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

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

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

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

有打點(diǎn)、有錯(cuò)誤日志、有詳細(xì)請(qǐng)求日志，還怕定位不到問題？