容器內應用日誌收集方案

容器化應用日誌收集挑戰

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

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

在部署一個傳統的應用的時候，應用程序記錄日誌的方式一般記錄到文件裏， 通常（但不必定）會記錄到/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 & A

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會崩潰。