摘要：容器化應用日志收集挑戰應用日志的收集分析和監控是日常運維工作重要的部分，妥善地處理應用日志收集往往是應用容器化重要的一個課題。日志來源識別采用統一應用日志收集方案，日志分散在很多不同容器的相互隔離的環境中，需要解決日志的來源識別問題。

應用日志的收集、分析和監控是日常運維工作重要的部分，妥善地處理應用日志收集往往是應用容器化重要的一個課題。

Docker處理日志的方法是通過docker engine捕捉每一個容器進程的STDOUT和STDERR，通過為contrainer制定不同log driver 來實現容器日志的收集，缺省json-file log driver是將容器的STDOUT/STDERR 輸出保存在磁盤上，然后用戶就能使用docker logs 來進行查詢。

在部署一個傳統的應用的時候，應用程序記錄日志的方式通常記錄到文件里， 一般（但不一定）會記錄到/var/log目錄下。應用容器化后，不同于以往將所有日志放在主機系統的統一位置，日志分散在很多不同容器的相互隔離的環境中。

如何收集應用寫在容器內日志記錄，有以下挑戰：

1) 資源消耗

如果在每個容器運行一個日志收集進程， 比如logstatsh/fluentd 這類的日志工具，在主機容器密度高的時候，logstatsh/fluentd這類日志采集工具會消耗大量的系統資源。上面這種方法是最簡單直觀的，也是最消耗資源的。

2) 應用侵入

一些傳統應用，特別是legacy 系統，寫日志機制往往是沒法配置和更改的，包括應用日志的格式，存放地址等等。日志采集機制，要盡量避免要求修改應用。

3) 日志來源識別

采用統一應用日志收集方案，日志分散在很多不同容器的相互隔離的環境中，需要解決日志的來源識別問題。

日志來源識別的功能借助了rancher平臺為container_name的命名的規則特性，可以做到即使一個容器在運行過程中被調度到另外一臺主機，也可以識別日志來源。

下面是我們設計的一個低資源資源消耗、無應用侵入、可以清楚識別日志來源的統一日志收集方案，該方案已經在睿云智合的客戶有成功實施案例。

在該方案中，會在每個host 部署一個wise2c-logger，wise2C會listen docker engine的event，當有新容器創建和銷毀時，會去判斷是否有和日志相關的local volume 被創建或者銷毀了，根據lables，wise2c-logger 會動態配置logstatsh的input、filter 和output，實現應用日志的收集和分發。

1） 應用如何配置

應用容器化時候，需要在為應用容器掛載一個專門寫有日志的volume，為了區別該volume 和容器其它數據volume，我們把該volume 定義在容器中，通過volume_from 指令share 給應用容器，下面是一個例子：demo應用的docker-compose file

web-data 容器使用一個local volume，mount到/var/log目錄(也可以是其它目錄)，在web-data中定義了幾個標簽， io.wise2c.logtype說明這個容器中包含了日志目錄，標簽里面的值elasticsearch、kafka可以用于指明log的output或者過濾條件等。

那么我們現在來看下wiselogger大致的工作流程：

監聽新的日志容器->獲取日志容器的type和本地目錄->生成新的logstash配置：

1）wise2c-looger 偵聽docker events 事件， 檢查是否有一個日志容器創建或者被銷毀；

2）當日志容器被創建后（通過container label 判斷）, inspect 容器的volume 在主機的path；

3）重新配置wise2c-logger 內置的logstatsh 的配置文件，設置新的input, filter 和output 規則。

這里是把wise2c-logger在rancher平臺上做成catalog需要的docker-compose.yml的截圖，大家可以配合上面的流程描述一起看一下。

目前我們還在對Wise2C-logger 作進一步的優化：

1）收集容器的STDOUT/STDERR日志

特別是對default 使用json-file driver的容器，通過掃描容器主機的json-file 目錄，實現容器STDIN/STDERR日志的收集。

2）更多的內置日志收集方案

目前內置缺省使用logstatsh 作日志的收集，和過濾和一些簡單的轉碼邏輯。未來wise2C-logger 可以支持一些更輕量級的日志收集方案，比如fluentd、filebeat等。

Q：有沒有做過性能測試？我這邊模塊的日志吞吐量比較大。比如在多少量級的日志輸出量基礎上，主要為logger模塊預留多少系統資源，保證其正常穩定工作？

A：沒有做過很強的壓力，但是我們現在正常使用倒沒碰上過性能上的瓶頸。我們現在沒有對logger做資源限制，但是能占用300～400M內存，因為有logstash的原因。

Q：「生成日志容器」是指每個應用容器要對應一個日志容器？這樣資源消耗不會更大嗎？k8s那種日志采集性能消耗會比這樣每個應用容器對應一個日志容器高么？

A：是指每個應用容器對應一個日志容器。雖然每個應用有一個日志容器，但是，日志容器是start once的，不會占用運行時資源。

Q：你說的start once是什么意思？我說占資源是大量日志來的時候，那么多日志容器要消耗大量io的吧，CPU使用率會上升，不會影響應用容器使用CPU么？

A：不會，日志容器只生成一下，不會持續運行。

Q：怎么去監聽local volume？

A：可以監聽文件目錄，也可以定時請求docker daemon。

Q：直接用syslog driver，能做到對應用無侵入么？

A：啟動容器的時候 注明使用Syslog driver的參數即可，這樣幾乎沒有額外資源占用。

Q：這種方案是不是要保證應用容器日志要輸出到/var/log下啊？

A：不是，可以隨意定義，logstah可以抓syslog。

Q：syslog driver能收集容器內的日志文件么？容器內不同流向的日志能區分么？

A：容器內應用的本地日志syslog可以收集，分流同樣可以完成，但是容器內的本地日志這個我個人覺得跟容器環境下的應用無本地化、無狀態化相悖吧。

Q：最后你說到，重新配置logstash中配置文件，看上去感覺你又是通過wiselog這個容器去采集所有日志的？只不過是動態配置logstash里面參數。

A：是的，現在收集工作是logstash來完成的，單純的文件收集，可選的方案還挺多的，也沒有必要再造輪子了。

Q：那這個方案其實有個疑問，為什么不學k8s那種，直接固定那目錄，通過正則表達式去采集日志文件，而要動態這么做？有什么好處嗎？目前我感覺這兩套方案幾乎一樣。

A：為了減少對應用的侵入。因為很多用戶的現有系統不能再修改了，這樣做也是為了減少用戶現有程序的修改，為了最重要的“兼容現有”。

Q：除了kibana還有沒別的可視化方案？

A：針對es來說，還沒有別的更好的方案。

Q：如果是掛載log目錄，logstash就可以去宿主機收集了，還需要別的插件做什么？

A：通過容器可以識別出來這個應用的業務上的邏輯，可以拿到service名稱。

Q：有的應用輸出的log名都是一樣的，不會有沖突嗎，比如我啟動2個容器在一個宿主機上，都往xx.log里寫入會有問題。

A：不會，給每一個應用容器配一個日志卷容器就可以解決這個問題。這個問題也是我們出方案時一個棘手的問題。所以這個方案的一個好處就是，每一個應用的都可以隨意設置日志目錄，不用考慮和別的應用沖突，也不會和同宿主機同一應用沖突。

Q：上次聽別人說全部把日志扔到標準輸出里，不知道靠譜不？

A：有人報過這種處理方式，日志量大時，docker daemon會崩潰。