摘要：容器內(nèi)文件日志平臺(tái)支持的文件存儲(chǔ)是，避免了許多復(fù)雜環(huán)境的處理。以上是數(shù)人云在實(shí)踐容器日志系統(tǒng)過(guò)程中遇到的問(wèn)題，更高層次的應(yīng)用包括容器日志分析等，還有待繼續(xù)挖掘和填坑，歡迎大家提出建議，一起交流。

業(yè)務(wù)平臺(tái)每天產(chǎn)生大量日志數(shù)據(jù)，為了實(shí)現(xiàn)數(shù)據(jù)分析，需要將生產(chǎn)服務(wù)器上的所有日志收集后進(jìn)行大數(shù)據(jù)分析處理，Docker提供了日志驅(qū)動(dòng)，然而并不能滿(mǎn)足不同場(chǎng)景需求，本次將結(jié)合實(shí)例分享日志采集、存儲(chǔ)以及告警等方面的實(shí)踐經(jīng)驗(yàn)。

2013年以來(lái)Docker迅速火了起來(lái)，它的理念帶來(lái)了非常大的便利性，不過(guò)實(shí)際應(yīng)用中會(huì)發(fā)現(xiàn)還有監(jiān)控、日志、網(wǎng)絡(luò)等問(wèn)題尚待解決，本文會(huì)結(jié)合實(shí)例分享數(shù)人云做容器日志系統(tǒng)的經(jīng)驗(yàn)。

日志收集是大數(shù)據(jù)的基礎(chǔ)，業(yè)務(wù)平臺(tái)每天產(chǎn)生大量日志數(shù)據(jù)，為了實(shí)現(xiàn)數(shù)據(jù)分析，需要將生產(chǎn)服務(wù)器上的所有日志收集后進(jìn)行分析處理；高可用性，高可靠性以及可擴(kuò)展性是日志收集系統(tǒng)的必備要素。

ELK是目前較流行的日志一體化解決方案，提供日志收集、處理、存儲(chǔ)、搜索、展示等功能。容器標(biāo)準(zhǔn)輸出日志常用的查詢(xún)方式是通過(guò)Docker命令 docker logs containerid來(lái)查看，容器內(nèi)日志受容器隔離性影響不便于收集，因此當(dāng)面對(duì)大型系統(tǒng)，用單一命令管理日志是不可行的，需要一個(gè)對(duì)于容器日志統(tǒng)一檢索管理的方案?；贓LK實(shí)踐了一套容器日志管理系統(tǒng)，架構(gòu)如下：

傳統(tǒng)的日志采集有較成熟的解決方案，如Flume、Logstash等，但傳統(tǒng)的采集方案不適用于容器日志。Docker本身提供了LogDriver功能，可以利用不同的driver把日志輸出到不同地方，LogDriver具體有以下幾種：

None（將日志設(shè)置成不再輸出）

json-file（Docker默認(rèn)的LogDriver，將日志以JSON文件的方式存儲(chǔ)在本地）

Syslog（標(biāo)準(zhǔn)輸出日志可通過(guò)該方式傳輸）

Journal

SELF

Fluent

awslogs

Splunk

etwLogs

gcplogs

對(duì)于這些LogDriver就不一一詳細(xì)介紹了，大家有興趣可以去Docker官網(wǎng)查看。可見(jiàn)Docker對(duì)日志提供了較為豐富的處理方式，供選擇的還有優(yōu)秀的開(kāi)源項(xiàng)目Logspout等，然而這并不能滿(mǎn)足所有的使用場(chǎng)景。

容器的標(biāo)準(zhǔn)輸出日志可從以上驅(qū)動(dòng)中選擇，由于大多數(shù)用戶(hù)選擇標(biāo)準(zhǔn)化輸出日志，故Docker沒(méi)有提供采集功能，如果將日志內(nèi)的文件掛載出來(lái)進(jìn)行采集，多個(gè)實(shí)例同名日志則會(huì)無(wú)法區(qū)分，容器內(nèi)文件日志處理、錯(cuò)誤日志多行處理等問(wèn)題時(shí)有發(fā)生，若想標(biāo)準(zhǔn)輸出日志和容器內(nèi)文件日志兼得，則需自己動(dòng)手豐衣足食，以下為數(shù)人云日志采集系統(tǒng)實(shí)踐。

針對(duì)Marathon + Mesos環(huán)境開(kāi)發(fā)了一套日志采集工具，Docker的標(biāo)準(zhǔn)輸出日志json-file默認(rèn)持久化在本地上，Mesos對(duì)于標(biāo)準(zhǔn)輸出日志也存了一份在Sandbox下：

因此標(biāo)準(zhǔn)輸出日志也可以通過(guò)Mesos文件的方式進(jìn)行采集。

平臺(tái)支持的文件存儲(chǔ)是Overlay，避免了許多復(fù)雜環(huán)境的處理。關(guān)于Overlay盜用一張圖：

容器的存儲(chǔ)驅(qū)動(dòng)運(yùn)用寫(xiě)時(shí)復(fù)制（Copy On Write），Overlay主要分為lower和upper, 當(dāng)需要修改一個(gè)文件時(shí)，使用CoW將文件從只讀的Lower層復(fù)制到可寫(xiě)層Upper層進(jìn)行修改，在Docker中，底部的只讀層是image，可寫(xiě)層是Container，因此容器內(nèi)日志在宿主機(jī)上通過(guò)Upper的文件系統(tǒng)可找到，例如在容器內(nèi)的/var/log/test.log中寫(xiě)一個(gè)test字符，如圖：

同理，無(wú)論是標(biāo)注輸出的日志還是容器內(nèi)文件日志，都可以通過(guò)文件的方式進(jìn)行處理，也可以同時(shí)把json-file關(guān)閉，以減輕Docker本身的壓力。

基于上述方式開(kāi)發(fā)了一款日志采集工具，對(duì)日志進(jìn)行統(tǒng)一收集管理，日志通過(guò)TCP把JSON格式化的日志輸出到Logstash，包括應(yīng)用ID，容器Name，容器ID，TaskID等，當(dāng)然開(kāi)發(fā)的過(guò)程中也遇到許多問(wèn)題，如斷點(diǎn)續(xù)傳和錯(cuò)誤日志多行處理等功能，這其中參考了Filebeat（Go語(yǔ)言開(kāi)發(fā)）對(duì)于日志處理的方式，個(gè)人認(rèn)為如果是對(duì)于傳統(tǒng)文件日志處理，F(xiàn)ilebeat是不錯(cuò)的選擇，日志采集功能第一步支持：

容器標(biāo)準(zhǔn)輸出日志采集

容器內(nèi)文件日志采集，支持同時(shí)采集多個(gè)文件

斷點(diǎn)續(xù)傳 （如果Agent崩潰，從上次offset采集）

多行日志合并 （如：多行錯(cuò)誤日志合并）

日志文件異常處理 （如：日志被rotate可以重新采集）

TCP傳輸

--add-env --add-label標(biāo)簽，可以通過(guò)指定命令把container的env或者label加到日志數(shù)據(jù)里，如(--add-env hostname=HOST --add-env test=ENV_NAME1 --add-label tlabel=label_name)

Prometheus指標(biāo)數(shù)據(jù)

日志處理需要提供快速的數(shù)據(jù)處理能力，在開(kāi)發(fā)過(guò)程中遇到了性能問(wèn)題，CPU占用非常高，針對(duì)該問(wèn)題對(duì)程序作調(diào)優(yōu)，使用Golang內(nèi)置的包net/http/pprof，對(duì)Golang程序調(diào)優(yōu)很好用，可將程序中每個(gè)函數(shù)占用CPU內(nèi)存的比例通過(guò)生成SVG的方式直觀的反映出來(lái)，如圖：

Golang內(nèi)置包encoding/json json的序列化、正則、反射、字節(jié)轉(zhuǎn)字符串對(duì)于資源的消耗也比較高，可針對(duì)以上幾方面以及程序本身進(jìn)行調(diào)整。

日志存儲(chǔ)功能有Logstash、Heka、Fluentd等方案，Logstash基于R uby，支持功能豐富，但性能方面詬病較多；Heka基于Go，性能方面比Logstash好很多，不過(guò)Heka好像已經(jīng)不維護(hù)了。綜合考慮社區(qū)活躍度、迭代速度以及穩(wěn)定性方面最終選擇了Logstash，實(shí)際應(yīng)用過(guò)程中比較重要的參數(shù)如下：

--pipeline-workers （命令行參數(shù)）

--pipeline-batch-size （命令行參數(shù)）

LS_HEAP_SIZE=${LS_HEAP_SIZE} （根據(jù)自己的實(shí)際情況填寫(xiě)，可以寫(xiě)到環(huán)境變量活著命令行參數(shù)里面）

workers => 8（根據(jù)自己實(shí)際情況，一般等于CPU數(shù)，配置文件參數(shù)）

flush_size => 3000（根據(jù)自己的實(shí)際情況測(cè)試）

以上參數(shù)僅供參考，可根據(jù)實(shí)際環(huán)境進(jìn)行調(diào)試。如果日志量較大，為了確保架構(gòu)的穩(wěn)定性，可以在中間加一層消息隊(duì)列，比較常用的有Kafka、Redis等，相信大家對(duì)這方面應(yīng)用比較多，不再贅述。

ES應(yīng)該是索引存儲(chǔ)的不二選擇，整個(gè)架構(gòu)的緩解包括ES通過(guò)Docker的方式部署，壓測(cè)時(shí)用Marvel對(duì)ES的索引方式監(jiān)控等，網(wǎng)上有很多調(diào)優(yōu)資料，可自行實(shí)驗(yàn)。日志的展示是通過(guò)自己定制的，Kibana本身的功能比較強(qiáng)大的同時(shí)也略微有些學(xué)習(xí)成本，最終客戶(hù)想要的是很簡(jiǎn)單的東西。

壓測(cè)工具選擇的是分布式壓測(cè)工具Tsung，通過(guò)壓測(cè)一個(gè)應(yīng)用產(chǎn)生日志然后通過(guò)Log-Agent對(duì)日志進(jìn)行采集，模擬真實(shí)環(huán)境日志采集。

日志處理中，關(guān)鍵字報(bào)警是一個(gè)重要功能，對(duì)于監(jiān)控報(bào)警主要用Prometheus + Alertmanager實(shí)現(xiàn)。應(yīng)用運(yùn)行過(guò)程中，根據(jù)日志關(guān)鍵字告警部的應(yīng)用場(chǎng)景，從Logstash部分對(duì)日志做分流（具體方案可以看上面圖的報(bào)警部分），自研g(shù)rok_export對(duì)日志進(jìn)行過(guò)濾分析生成Prometheus格式的數(shù)據(jù)，然后從Prometheus配置報(bào)警策略通過(guò)alertmanager報(bào)警。Log-Agent本身也支持Prometheus數(shù)據(jù)，Prometheus通過(guò)特定的規(guī)則查看日志的統(tǒng)計(jì)信息。

Prometheus：
Prometheus是開(kāi)源的監(jiān)控告警系統(tǒng)，通過(guò)pull的方式采集時(shí)間序列，以及用http傳輸，數(shù)據(jù)存儲(chǔ)在本地，支持豐富的查詢(xún)語(yǔ)法和簡(jiǎn)單的Dashboard展示。

Alertmanager：
Alertmanager作為Prometheus的組件，所有達(dá)到閥值的時(shí)間都通過(guò)Alertmanager報(bào)警，Alertmanager支持非常強(qiáng)大的告警功能，包括http、email通知，以及靜默重復(fù)報(bào)警屏蔽等功能。

以上是數(shù)人云在實(shí)踐容器日志系統(tǒng)過(guò)程中遇到的問(wèn)題，更高層次的應(yīng)用包括容器日志分析等，還有待繼續(xù)挖掘和填坑，歡迎大家提出建議，一起交流。

Q：Overlay 是沒(méi)有實(shí)現(xiàn) inotify 接口的，是咋獲取文件日志增量數(shù)據(jù)的？

A：通過(guò)循環(huán)讀取文件的方式，記錄文件offset。

Q：既然主要框架是 ELK，采集端不直接用 Filebeat 是因?yàn)?Filebeat 有局限性嗎？

A：Filebeat沒(méi)有滿(mǎn)足我們產(chǎn)品基于Docker的需求，等于上面加了Docker的邏輯。

Q：自研的日志系統(tǒng)，打出來(lái)的每條日志格式都是規(guī)定好的嗎？開(kāi)發(fā)中每個(gè)人都要按這個(gè)規(guī)范來(lái)做嗎？不管是什么級(jí)別的日志？

A：其實(shí)并沒(méi)有，但是如果是內(nèi)部使用，能規(guī)約好當(dāng)然更好，可以更方便的處理，而且可以做更細(xì)粒度的分析。

Q：日志收集有做分析展示處理嗎？用什么處理的。

A：對(duì)于日志內(nèi)容的分析還沒(méi)做，例如Nginx請(qǐng)求日志還是有分析意義的。

Q：采集方面有考慮直接使用系統(tǒng)的Syslog和Logrotate嗎？

A：用過(guò)Syslog后來(lái)因?yàn)槿萜鲀?nèi)的文件日志需求重新開(kāi)發(fā)的。