容器内应用日志收集方案
容器化應(yīng)用日志收集挑戰(zhàn)
應(yīng)用日志的收集、分析和監(jiān)控是日常運(yùn)維工作重要的部分，妥善地處理應(yīng)用日志收集往往是應(yīng)用容器化重要的一個(gè)課題。
Docker處理日志的方法是通過docker engine捕捉每一個(gè)容器進(jìn)程的STDOUT和STDERR，通過為contrainer制定不同log driver 來實(shí)現(xiàn)容器日志的收集，缺省json-file log driver是將容器的STDOUT/STDERR 輸出保存在磁盤上，然后用戶就能使用docker logs <container>來進(jìn)行查詢。
在部署一個(gè)傳統(tǒng)的應(yīng)用的時(shí)候，應(yīng)用程序記錄日志的方式通常記錄到文件里， 一般（但不一定）會(huì)記錄到/var/log目錄下。應(yīng)用容器化后，不同于以往將所有日志放在主機(jī)系統(tǒng)的統(tǒng)一位置，日志分散在很多不同容器的相互隔離的環(huán)境中。
如何收集應(yīng)用寫在容器內(nèi)日志記錄，有以下挑戰(zhàn)：
1) 資源消耗
如果在每個(gè)容器運(yùn)行一個(gè)日志收集進(jìn)程， 比如logstatsh/fluentd 這類的日志工具，在主機(jī)容器密度高的時(shí)候，logstatsh/fluentd這類日志采集工具會(huì)消耗大量的系統(tǒng)資源。上面這種方法是最簡單直觀的，也是最消耗資源的。
2) 應(yīng)用侵入
一些傳統(tǒng)應(yīng)用，特別是legacy 系統(tǒng)，寫日志機(jī)制往往是沒法配置和更改的，包括應(yīng)用日志的格式，存放地址等等。日志采集機(jī)制，要盡量避免要求修改應(yīng)用。
3) 日志來源識(shí)別
采用統(tǒng)一應(yīng)用日志收集方案，日志分散在很多不同容器的相互隔離的環(huán)境中，需要解決日志的來源識(shí)別問題。
日志來源識(shí)別的功能借助了rancher平臺(tái)為container_name的命名的規(guī)則特性，可以做到即使一個(gè)容器在運(yùn)行過程中被調(diào)度到另外一臺(tái)主機(jī)，也可以識(shí)別日志來源。
容器化應(yīng)用日志收集方案
下面是我們?cè)O(shè)計(jì)的一個(gè)低資源資源消耗、無應(yīng)用侵入、可以清楚識(shí)別日志來源的統(tǒng)一日志收集方案，該方案已經(jīng)在睿云智合的客戶有成功實(shí)施案例。
在該方案中，會(huì)在每個(gè)host 部署一個(gè)wise2c-logger，wise2C會(huì)listen docker engine的event，當(dāng)有新容器創(chuàng)建和銷毀時(shí)，會(huì)去判斷是否有和日志相關(guān)的local volume 被創(chuàng)建或者銷毀了，根據(jù)lables，wise2c-logger 會(huì)動(dòng)態(tài)配置logstatsh的input、filter 和output，實(shí)現(xiàn)應(yīng)用日志的收集和分發(fā)。
1） 應(yīng)用如何配置
應(yīng)用容器化時(shí)候，需要在為應(yīng)用容器掛載一個(gè)專門寫有日志的volume，為了區(qū)別該volume 和容器其它數(shù)據(jù)volume，我們把該volume 定義在容器中，通過volume_from 指令share 給應(yīng)用容器，下面是一個(gè)例子：demo應(yīng)用的docker-compose file
web-data 容器使用一個(gè)local volume，mount到/var/log目錄(也可以是其它目錄)，在web-data中定義了幾個(gè)標(biāo)簽， io.wise2c.logtype說明這個(gè)容器中包含了日志目錄，標(biāo)簽里面的值elasticsearch、kafka可以用于指明log的output或者過濾條件等。
那么我們現(xiàn)在來看下wiselogger大致的工作流程：
監(jiān)聽新的日志容器->獲取日志容器的type和本地目錄->生成新的logstash配置：
1）wise2c-looger 偵聽docker events 事件， 檢查是否有一個(gè)日志容器創(chuàng)建或者被銷毀；
2）當(dāng)日志容器被創(chuàng)建后（通過container label 判斷）, inspect 容器的volume 在主機(jī)的path；
3）重新配置wise2c-logger 內(nèi)置的logstatsh 的配置文件，設(shè)置新的input, filter 和output 規(guī)則。
這里是把wise2c-logger在rancher平臺(tái)上做成catalog需要的docker-compose.yml的截圖，大家可以配合上面的流程描述一起看一下。
優(yōu)化
目前我們還在對(duì)Wise2C-logger 作進(jìn)一步的優(yōu)化：
1）收集容器的STDOUT/STDERR日志
特別是對(duì)default 使用json-file driver的容器，通過掃描容器主機(jī)的json-file 目錄，實(shí)現(xiàn)容器STDIN/STDERR日志的收集。
2）更多的內(nèi)置日志收集方案
目前內(nèi)置缺省使用logstatsh 作日志的收集，和過濾和一些簡單的轉(zhuǎn)碼邏輯。未來wise2C-logger 可以支持一些更輕量級(jí)的日志收集方案，比如fluentd、filebeat等。
Q & A
Q：有沒有做過性能測試？我這邊模塊的日志吞吐量比較大。比如在多少量級(jí)的日志輸出量基礎(chǔ)上，主要為logger模塊預(yù)留多少系統(tǒng)資源，保證其正常穩(wěn)定工作？
A：沒有做過很強(qiáng)的壓力，但是我們現(xiàn)在正常使用倒沒碰上過性能上的瓶頸。我們現(xiàn)在沒有對(duì)logger做資源限制，但是能占用300～400M內(nèi)存，因?yàn)橛衛(wèi)ogstash的原因。
Q：「生成日志容器」是指每個(gè)應(yīng)用容器要對(duì)應(yīng)一個(gè)日志容器？這樣資源消耗不會(huì)更大嗎？k8s那種日志采集性能消耗會(huì)比這樣每個(gè)應(yīng)用容器對(duì)應(yīng)一個(gè)日志容器高么？
A：是指每個(gè)應(yīng)用容器對(duì)應(yīng)一個(gè)日志容器。雖然每個(gè)應(yīng)用有一個(gè)日志容器，但是，日志容器是start once的，不會(huì)占用運(yùn)行時(shí)資源。
Q：你說的start once是什么意思？我說占資源是大量日志來的時(shí)候，那么多日志容器要消耗大量io的吧，CPU使用率會(huì)上升，不會(huì)影響應(yīng)用容器使用CPU么？
A：不會(huì)，日志容器只生成一下，不會(huì)持續(xù)運(yùn)行。
Q：怎么去監(jiān)聽local volume？
A：可以監(jiān)聽文件目錄，也可以定時(shí)請(qǐng)求docker daemon。
Q：直接用syslog driver，能做到對(duì)應(yīng)用無侵入么？
A：啟動(dòng)容器的時(shí)候 注明使用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)的本地日志這個(gè)我個(gè)人覺得跟容器環(huán)境下的應(yīng)用無本地化、無狀態(tài)化相悖吧。
Q：最后你說到，重新配置logstash中配置文件，看上去感覺你又是通過wiselog這個(gè)容器去采集所有日志的？只不過是動(dòng)態(tài)配置logstash里面參數(shù)。
A：是的，現(xiàn)在收集工作是logstash來完成的，單純的文件收集，可選的方案還挺多的，也沒有必要再造輪子了。
Q：那這個(gè)方案其實(shí)有個(gè)疑問，為什么不學(xué)k8s那種，直接固定那目錄，通過正則表達(dá)式去采集日志文件，而要?jiǎng)討B(tài)這么做？有什么好處嗎？目前我感覺這兩套方案幾乎一樣。
A：為了減少對(duì)應(yīng)用的侵入。因?yàn)楹芏嘤脩舻默F(xiàn)有系統(tǒng)不能再修改了，這樣做也是為了減少用戶現(xiàn)有程序的修改，為了最重要的“兼容現(xiàn)有”。
Q：除了kibana還有沒別的可視化方案？
A：針對(duì)es來說，還沒有別的更好的方案。
Q：如果是掛載log目錄，logstash就可以去宿主機(jī)收集了，還需要?jiǎng)e的插件做什么？
A：通過容器可以識(shí)別出來這個(gè)應(yīng)用的業(yè)務(wù)上的邏輯，可以拿到service名稱。
Q：有的應(yīng)用輸出的log名都是一樣的，不會(huì)有沖突嗎，比如我啟動(dòng)2個(gè)容器在一個(gè)宿主機(jī)上，都往xx.log里寫入會(huì)有問題。
A：不會(huì)，給每一個(gè)應(yīng)用容器配一個(gè)日志卷容器就可以解決這個(gè)問題。這個(gè)問題也是我們出方案時(shí)一個(gè)棘手的問題。所以這個(gè)方案的一個(gè)好處就是，每一個(gè)應(yīng)用的都可以隨意設(shè)置日志目錄，不用考慮和別的應(yīng)用沖突，也不會(huì)和同宿主機(jī)同一應(yīng)用沖突。
Q：上次聽別人說全部把日志扔到標(biāo)準(zhǔn)輸出里，不知道靠譜不？
A：有人報(bào)過這種處理方式，日志量大時(shí)，docker daemon會(huì)崩潰。
總結(jié)
以上是生活随笔為你收集整理的容器内应用日志收集方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： javascript 模块化机制
- 下一篇： 限制对web路径的访问