摘要：容器內(nèi)文件日志平臺(tái)支持的文件存儲(chǔ)是，避免了許多復(fù)雜環(huán)境的處理。以上是數(shù)人云在實(shí)踐容器日志系統(tǒng)過程中遇到的問題，更高層次的應(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)，然而并不能滿足不同場景需求，本次將結(jié)合實(shí)例分享日志采集、存儲(chǔ)以及告警等方面的實(shí)踐經(jīng)驗(yàn)。

2013年以來Docker迅速火了起來，它的理念帶來了非常大的便利性，不過實(shí)際應(yīng)用中會(huì)發(fā)現(xiàn)還有監(jiān)控、日志、網(wǎng)絡(luò)等問題尚待解決，本文會(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)輸出日志常用的查詢方式是通過Docker命令 docker logs containerid來查看，容器內(nèi)日志受容器隔離性影響不便于收集，因此當(dāng)面對大型系統(tǒng)，用單一命令管理日志是不可行的，需要一個(gè)對于容器日志統(tǒng)一檢索管理的方案。基于ELK實(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)輸出日志可通過該方式傳輸）

Journal

SELF

Fluent

awslogs

Splunk

etwLogs

gcplogs

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

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

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

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

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

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

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

基于上述方式開發(fā)了一款日志采集工具，對日志進(jìn)行統(tǒng)一收集管理，日志通過TCP把JSON格式化的日志輸出到Logstash，包括應(yīng)用ID，容器Name，容器ID，TaskID等，當(dāng)然開發(fā)的過程中也遇到許多問題，如斷點(diǎn)續(xù)傳和錯(cuò)誤日志多行處理等功能，這其中參考了Filebeat（Go語言開發(fā)）對于日志處理的方式，個(gè)人認(rèn)為如果是對于傳統(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)簽，可以通過指定命令把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ù)處理能力，在開發(fā)過程中遇到了性能問題，CPU占用非常高，針對該問題對程序作調(diào)優(yōu)，使用Golang內(nèi)置的包net/http/pprof，對Golang程序調(diào)優(yōu)很好用，可將程序中每個(gè)函數(shù)占用CPU內(nèi)存的比例通過生成SVG的方式直觀的反映出來，如圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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