摘要：容器內文件日志平臺支持的文件存儲是，避免了許多復雜環境的處理。以上是數人云在實踐容器日志系統過程中遇到的問題，更高層次的應用包括容器日志分析等，還有待繼續挖掘和填坑，歡迎大家提出建議，一起交流。

業務平臺每天產生大量日志數據，為了實現數據分析，需要將生產服務器上的所有日志收集后進行大數據分析處理，Docker提供了日志驅動，然而并不能滿足不同場景需求，本次將結合實例分享日志采集、存儲以及告警等方面的實踐經驗。

2013年以來Docker迅速火了起來，它的理念帶來了非常大的便利性，不過實際應用中會發現還有監控、日志、網絡等問題尚待解決，本文會結合實例分享數人云做容器日志系統的經驗。

日志收集是大數據的基礎，業務平臺每天產生大量日志數據，為了實現數據分析，需要將生產服務器上的所有日志收集后進行分析處理；高可用性，高可靠性以及可擴展性是日志收集系統的必備要素。

ELK是目前較流行的日志一體化解決方案，提供日志收集、處理、存儲、搜索、展示等功能。容器標準輸出日志常用的查詢方式是通過Docker命令 docker logs containerid來查看，容器內日志受容器隔離性影響不便于收集，因此當面對大型系統，用單一命令管理日志是不可行的，需要一個對于容器日志統一檢索管理的方案。基于ELK實踐了一套容器日志管理系統，架構如下：

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

None（將日志設置成不再輸出）

json-file（Docker默認的LogDriver，將日志以JSON文件的方式存儲在本地）

Syslog（標準輸出日志可通過該方式傳輸）

Journal

SELF

Fluent

awslogs

Splunk

etwLogs

gcplogs

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

容器的標準輸出日志可從以上驅動中選擇，由于大多數用戶選擇標準化輸出日志，故Docker沒有提供采集功能，如果將日志內的文件掛載出來進行采集，多個實例同名日志則會無法區分，容器內文件日志處理、錯誤日志多行處理等問題時有發生，若想標準輸出日志和容器內文件日志兼得，則需自己動手豐衣足食，以下為數人云日志采集系統實踐。

針對Marathon + Mesos環境開發了一套日志采集工具，Docker的標準輸出日志json-file默認持久化在本地上，Mesos對于標準輸出日志也存了一份在Sandbox下：

因此標準輸出日志也可以通過Mesos文件的方式進行采集。

平臺支持的文件存儲是Overlay，避免了許多復雜環境的處理。關于Overlay盜用一張圖：

容器的存儲驅動運用寫時復制（Copy On Write），Overlay主要分為lower和upper, 當需要修改一個文件時，使用CoW將文件從只讀的Lower層復制到可寫層Upper層進行修改，在Docker中，底部的只讀層是image，可寫層是Container，因此容器內日志在宿主機上通過Upper的文件系統可找到，例如在容器內的/var/log/test.log中寫一個test字符，如圖：

同理，無論是標注輸出的日志還是容器內文件日志，都可以通過文件的方式進行處理，也可以同時把json-file關閉，以減輕Docker本身的壓力。

基于上述方式開發了一款日志采集工具，對日志進行統一收集管理，日志通過TCP把JSON格式化的日志輸出到Logstash，包括應用ID，容器Name，容器ID，TaskID等，當然開發的過程中也遇到許多問題，如斷點續傳和錯誤日志多行處理等功能，這其中參考了Filebeat（Go語言開發）對于日志處理的方式，個人認為如果是對于傳統文件日志處理，Filebeat是不錯的選擇，日志采集功能第一步支持：

容器標準輸出日志采集

容器內文件日志采集，支持同時采集多個文件

斷點續傳 （如果Agent崩潰，從上次offset采集）

多行日志合并 （如：多行錯誤日志合并）

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

TCP傳輸

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

Prometheus指標數據

日志處理需要提供快速的數據處理能力，在開發過程中遇到了性能問題，CPU占用非常高，針對該問題對程序作調優，使用Golang內置的包net/http/pprof，對Golang程序調優很好用，可將程序中每個函數占用CPU內存的比例通過生成SVG的方式直觀的反映出來，如圖：

Golang內置包encoding/json json的序列化、正則、反射、字節轉字符串對于資源的消耗也比較高，可針對以上幾方面以及程序本身進行調整。

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

--pipeline-workers （命令行參數）

--pipeline-batch-size （命令行參數）

LS_HEAP_SIZE=${LS_HEAP_SIZE} （根據自己的實際情況填寫，可以寫到環境變量活著命令行參數里面）

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

flush_size => 3000（根據自己的實際情況測試）

以上參數僅供參考，可根據實際環境進行調試。如果日志量較大，為了確保架構的穩定性，可以在中間加一層消息隊列，比較常用的有Kafka、Redis等，相信大家對這方面應用比較多，不再贅述。

ES應該是索引存儲的不二選擇，整個架構的緩解包括ES通過Docker的方式部署，壓測時用Marvel對ES的索引方式監控等，網上有很多調優資料，可自行實驗。日志的展示是通過自己定制的，Kibana本身的功能比較強大的同時也略微有些學習成本，最終客戶想要的是很簡單的東西。

壓測工具選擇的是分布式壓測工具Tsung，通過壓測一個應用產生日志然后通過Log-Agent對日志進行采集，模擬真實環境日志采集。

日志處理中，關鍵字報警是一個重要功能，對于監控報警主要用Prometheus + Alertmanager實現。應用運行過程中，根據日志關鍵字告警部的應用場景，從Logstash部分對日志做分流（具體方案可以看上面圖的報警部分），自研grok_export對日志進行過濾分析生成Prometheus格式的數據，然后從Prometheus配置報警策略通過alertmanager報警。Log-Agent本身也支持Prometheus數據，Prometheus通過特定的規則查看日志的統計信息。

Prometheus：
Prometheus是開源的監控告警系統，通過pull的方式采集時間序列，以及用http傳輸，數據存儲在本地，支持豐富的查詢語法和簡單的Dashboard展示。

Alertmanager：
Alertmanager作為Prometheus的組件，所有達到閥值的時間都通過Alertmanager報警，Alertmanager支持非常強大的告警功能，包括http、email通知，以及靜默重復報警屏蔽等功能。

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

Q：Overlay 是沒有實現 inotify 接口的，是咋獲取文件日志增量數據的？

A：通過循環讀取文件的方式，記錄文件offset。

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

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

Q：自研的日志系統，打出來的每條日志格式都是規定好的嗎？開發中每個人都要按這個規范來做嗎？不管是什么級別的日志？

A：其實并沒有，但是如果是內部使用，能規約好當然更好，可以更方便的處理，而且可以做更細粒度的分析。

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

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

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

A：用過Syslog后來因為容器內的文件日志需求重新開發的。