背景

在企業(yè)級(jí)的微服務(wù)環(huán)境中，跑著成百上千個(gè)服務(wù)都算是比較小的規(guī)模了。在生產(chǎn)環(huán)境上，日志扮演著很重要的角色，排查異常需要日志，性能優(yōu)化需要日志，業(yè)務(wù)排查需要業(yè)務(wù)等等。然而在生產(chǎn)上跑著成百上千個(gè)服務(wù)，每個(gè)服務(wù)都只會(huì)簡(jiǎn)單的本地化存儲(chǔ)，當(dāng)需要日志協(xié)助排查問(wèn)題時(shí)，很難找到日志所在的節(jié)點(diǎn)。也很難挖掘業(yè)務(wù)日志的數(shù)據(jù)價(jià)值。

那么將日志統(tǒng)一輸出到一個(gè)地方集中管理，然后將日志處理化，把結(jié)果輸出成運(yùn)維、研發(fā)可用的數(shù)據(jù)是解決日志管理、協(xié)助運(yùn)維的可行方案，也是企業(yè)迫切解決日志的需求。

我們的解決方案

通過(guò)上面的需求我們推出了日志監(jiān)控系統(tǒng)。   

• 日志統(tǒng)一收集、過(guò)濾清洗。
• 生成可視化界面、監(jiān)控，告警，日志搜索。

功能流程概覽

• 在每個(gè)服務(wù)節(jié)點(diǎn)上埋點(diǎn)，實(shí)時(shí)采集相關(guān)日志。
• 統(tǒng)一日志收集服務(wù)、過(guò)濾、清洗日志后生成可視化界面、告警功能。

我們的架構(gòu)

1、日志文件采集端我們使用filebeat,運(yùn)維通過(guò)我們的后臺(tái)管理界面化配置，每個(gè)機(jī)器對(duì)應(yīng)一個(gè)filebeat，每個(gè)filebeat日志對(duì)應(yīng)的topic可以是一對(duì)一、多對(duì)一，根據(jù)日常的日志量配置不同的策略。

除了采集業(yè)務(wù)服務(wù)日志外，我們還收集了mysql的慢查詢(xún)?nèi)罩竞湾e(cuò)誤日志,還有別的第三方服務(wù)日志，如:nginx等。最后結(jié)合我們的自動(dòng)化發(fā)布平臺(tái)，自動(dòng)發(fā)布并啟動(dòng)每一個(gè)filebeat進(jìn)程。

2、調(diào)用棧、鏈路、進(jìn)程監(jiān)控指標(biāo)我們使用的代理方式：Elastic APM，這樣對(duì)于業(yè)務(wù)側(cè)的程序無(wú)需任何改動(dòng)。對(duì)于已經(jīng)在運(yùn)營(yíng)中的業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，為了加入監(jiān)控而需要改動(dòng)代碼，那是不可取的，也是無(wú)法接受的。Elastic APM可以幫我們收集http接口的調(diào)用鏈路、內(nèi)部方法調(diào)用棧、使用的sql、進(jìn)程的cpu、內(nèi)存使用指標(biāo)等。

可能有人會(huì)有疑問(wèn)，用了Elastic APM，其它日志基本都可以不用采集了。還要用filebeat干嘛？

是的，Elastic APM采集的信息確實(shí)能幫我們定位80%以上的問(wèn)題，但是它不是所有的語(yǔ)言都支持的比如：C。

其二、它無(wú)法幫你采集你想要的非error日志和所謂的關(guān)鍵日志，比如：某個(gè)接口調(diào)用時(shí)出了錯(cuò)，你想看出錯(cuò)時(shí)間點(diǎn)的前后日志；還有打印業(yè)務(wù)相關(guān)方便做分析的日志。

其三、自定義的業(yè)務(wù)異常，該異常屬于非系統(tǒng)異常，屬于業(yè)務(wù)范疇，APM會(huì)把這類(lèi)異常當(dāng)成系統(tǒng)異常上報(bào)，如果你后面對(duì)系統(tǒng)異常做告警，那這些異常將會(huì)干擾告警的準(zhǔn)確度，你也不能去過(guò)濾業(yè)務(wù)異常，因?yàn)樽远x的業(yè)務(wù)異常種類(lèi)也不少。

3、同時(shí)我們對(duì)agent進(jìn)行了二開(kāi)。采集更詳細(xì)的gc、堆棧、內(nèi)存、線程信息。

4、服務(wù)器采集我們采用普羅米修斯。

5、由于我們是saas服務(wù)化，服務(wù)N多，很多的服務(wù)日志做不到統(tǒng)一規(guī)范化，這也跟歷史遺留問(wèn)題有關(guān)，一個(gè)與業(yè)務(wù)系統(tǒng)無(wú)關(guān)的系統(tǒng)去間接或直接地去對(duì)接已有的業(yè)務(wù)系統(tǒng)，為了適配自己而讓其更改代碼，那是推不動(dòng)的。牛逼的設(shè)計(jì)是讓自己去兼容別人，把對(duì)方當(dāng)成攻擊自己的對(duì)象。

很多日志是沒(méi)有意義的，比如：開(kāi)發(fā)過(guò)程中為了方便排查跟蹤問(wèn)題，在if else里打印只是有標(biāo)志性的日志，代表是走了if代碼塊還是else代碼塊。甚至有些服務(wù)還打印著debug級(jí)別的日志。在成本、資源的有限條件下，所有所有的日志是不現(xiàn)實(shí)的，即使資源允許，一年下來(lái)將是一比很大的開(kāi)銷(xiāo)。所以我們采用了過(guò)濾、清洗、動(dòng)態(tài)調(diào)整日志優(yōu)先級(jí)采集等方案。首先把日志全量采集到kafka集群中，設(shè)定一個(gè)很短的有效期。我們目前設(shè)置的是一個(gè)小時(shí)，一個(gè)小時(shí)的數(shù)據(jù)量，我們的資源暫時(shí)還能接受。

6、Log Streams是我們的日志過(guò)濾、清洗的流處理服務(wù)。為什么還要ETL過(guò)濾器呢？因?yàn)槲覀兊娜罩痉?wù)資源有限，但不對(duì)啊，原來(lái)的日志分散在各各服務(wù)的本地存儲(chǔ)介質(zhì)上也是需要資源的哈?，F(xiàn)在我們也只是匯集而已哈，收集上來(lái)后，原來(lái)在各服務(wù)上的資源就可以釋放掉日志占用的部分資源了呀。

沒(méi)錯(cuò)，這樣算確實(shí)是把原來(lái)在各服務(wù)上的資源化分到了日志服務(wù)資源上來(lái)而已，并沒(méi)有增加資源。不過(guò)這只是理論上的，在線上的服務(wù)，資源擴(kuò)大容易，收縮就沒(méi)那么容易了，實(shí)施起來(lái)極其困難。所以短時(shí)間內(nèi)是不可能在各服務(wù)上使用的日志資源化分到日志服務(wù)上來(lái)的。這樣的話，日志服務(wù)的資源就是當(dāng)前所有服務(wù)日志使用資源的量。隨存儲(chǔ)的時(shí)間越長(zhǎng)，資源消耗越大。如果解決一個(gè)非業(yè)務(wù)或非解決不可的問(wèn)題，在短時(shí)間內(nèi)需要投入的成本大于解決當(dāng)前問(wèn)題所帶來(lái)收益的話，我想，在資金有限的情況下，沒(méi)有哪個(gè)領(lǐng)導(dǎo)、公司愿意采納的方案。

所以從成本上考慮，我們?cè)贚og Streams服務(wù)引入了過(guò)濾器，過(guò)濾沒(méi)有價(jià)值的日志數(shù)據(jù)，從而減少了日志服務(wù)使用的資源成本。技術(shù)我們采用Kafka Streams作為ETL流處理。通過(guò)界面化配置實(shí)現(xiàn)動(dòng)態(tài)過(guò)濾清洗的規(guī)則：

•  界面化配置日志采集。默認(rèn)error級(jí)別的日志全量采集
•  以錯(cuò)誤時(shí)間點(diǎn)為中心，在流處理中開(kāi)窗，輻射上下可配的N時(shí)間點(diǎn)采集非error級(jí)別日志，默認(rèn)只采info級(jí)別
•  每個(gè)服務(wù)可配100個(gè)關(guān)鍵日志，默認(rèn)關(guān)鍵日志全量采集
•  在慢sql的基礎(chǔ)上，按業(yè)務(wù)分類(lèi)配置不同的耗時(shí)再次過(guò)濾
•  按業(yè)務(wù)需求實(shí)時(shí)統(tǒng)計(jì)業(yè)務(wù)sql,比如：高峰期階段，統(tǒng)計(jì)一小時(shí)內(nèi)同類(lèi)業(yè)務(wù)sql的查詢(xún)頻率。可為dba提供優(yōu)化數(shù)據(jù)庫(kù)的依據(jù)，如按查詢(xún)的sql創(chuàng)建索引
•  高峰時(shí)段按業(yè)務(wù)類(lèi)型的權(quán)重指標(biāo)、日志等級(jí)指標(biāo)、每個(gè)服務(wù)在一個(gè)時(shí)段內(nèi)日志最大限制量指標(biāo)、時(shí)間段指標(biāo)等動(dòng)態(tài)清洗過(guò)濾日志
•  根據(jù)不同的時(shí)間段動(dòng)態(tài)收縮時(shí)間窗口
•  日志索引生成規(guī)則：按服務(wù)生成的日志文件規(guī)則生成對(duì)應(yīng)的index，比如：某個(gè)服務(wù)日志分為：debug、info、error、xx_keyword，那么生成的索引也是debug、info、error、xx_keyword加日期作后綴。這樣做的目的是為研發(fā)以原習(xí)慣性地去使用日志

7、可視化界面我們主要使用grafana，它支持的眾多數(shù)據(jù)源中，其中就有普羅米修斯和elasticsearch，與普羅米修斯可謂是無(wú)縫對(duì)接。而kibana我們主要用于apm的可視分析。

推薦閱讀：一百期Java面試題匯總

日志可視化