容器化應(yīng)用日志收集挑戰(zhàn)

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

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

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

如何收集應(yīng)用寫在容器內(nèi)日志記錄，有以下挑戰(zhàn)：

1) 資源消耗

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

2) 應(yīng)用侵入

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

3) 日志來源識別

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

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

容器化應(yīng)用日志收集方案

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

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

1） 應(yīng)用如何配置

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

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

那么我們現(xiàn)在來看下wiselogger大致的工作流程：

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

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

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

3）重新配置wise2c-logger 內(nèi)置的logstatsh 的配置文件，設(shè)置新的input, filter 和output 規(guī)則。

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

優(yōu)化

目前我們還在對Wise2C-logger 作進一步的優(yōu)化：

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

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

2）更多的內(nèi)置日志收集方案

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

Q & A

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

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

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

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

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

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

Q：怎么去監(jiān)聽local volume？

A：可以監(jiān)聽文件目錄，也可以定時請求docker daemon。

Q：直接用syslog driver，能做到對應(yīng)用無侵入么？

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

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

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

Q：syslog driver能收集容器內(nèi)的日志文件么？容器內(nèi)不同流向的日志能區(qū)分么？

A：容器內(nèi)應(yīng)用的本地日志syslog可以收集，分流同樣可以完成，但是容器內(nèi)的本地日志這個我個人覺得跟容器環(huán)境下的應(yīng)用無本地化、無狀態(tài)化相悖吧。

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

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

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

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

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

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

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

A：通過容器可以識別出來這個應(yīng)用的業(yè)務(wù)上的邏輯，可以拿到service名稱。

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的容器内应用日志收集方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。