轉載 https://cloud.tencent.com/developer/article/1846304
准備
關於容器日志
Docker的日志分為兩類，一類是 Docker引擎日志；另一類是容器日志。引擎日志一般都交給了系統日志，不同的操作系統會放在不同的位置。本文主要介紹容器日志，容器日志可以理解是運行在容器內部的應用輸出的日志，默認情況下，docker logs 顯示當前運行的容器的日志信息，內容包含 STOUT(標准輸出) 和 STDERR(標准錯誤輸出)。日志都會以 json-file 的格式存儲於/var/lib/docker/containers/<容器id>/<容器id>-json.log，不過這種方式並不適合放到生產環境中。
- 默認方式下容器日志並不會限制日志文件的大小，容器會一直寫日志，導致磁盤爆滿，影響系統應用。(docker log-driver 支持log文件的rotate)
- Docker Daemon 收集容器的標准輸出，當日志量過大時會導致Docker Daemon 成為日志收集的瓶頸，日志的收集速度受限。
- 日志文件量過大時，利用docker logs -f 查看時會直接將Docker Daemon阻塞住，造成docker ps等命令也不響應。
Docker提供了logging drivers配置，用戶可以根據自己的需求去配置不同的log-driver，可參考官網 Configure logging drivers[1] 。但是上述配置的日志收集也是通過Docker Daemon收集，收集日志的速度依然是瓶頸。
log-driver 日志收集速度 syslog 14.9 MB/s json-file 37.9 MB/s
能不能找到不通過Docker Daemon收集日志直接將日志內容重定向到文件並自動 rotate的工具呢？答案是肯定的采用S6[2]基底鏡像。
S6-log 將 CMD 的標准輸出重定向到/…/default/current，而不是發送到 Docker Daemon，這樣就避免了 Docker Daemon 收集日志的性能瓶頸。本文就是采用S6[3]基底鏡像構建應用鏡像形成統一日志收集方案。
關於k8s日志
k8s日志收集方案分成三個級別：
1、應用(Pod)級別 2、節點級別 3、集群級別
- 應用(Pod)級別
Pod級別的日志 , 默認是輸出到標准輸出和標志輸入，實際上跟docker 容器的一致。使用 kubectl logs pod-name -n namespace 查看，具體參考[4]。
- 節點級別
Node級別的日志 , 通過配置容器的log-driver[5]來進行管理 , 這種需要配合logrotare[6]來進行 , 日志超過最大限制 , 自動進行rotate操作。
- 集群級別
集群級別的日志收集 , 有三種
- 節點代理方式，在node級別進行日志收集。一般使用DaemonSet部署在每個node中。這種方式優點是耗費資源少，因為只需部署在節點，且對應用無侵入。缺點是只適合容器內應用日志必須都是標准輸出。
- 使用sidecar container作為容器日志代理，也就是在pod中跟隨應用容器起一個日志處理容器，有兩種形式：
一種是直接將應用容器的日志收集並輸出到標准輸出（叫做Streaming sidecar container），但需要注意的是，這時候，宿主機上實際上會存在兩份相同的日志文件：一份是應用自己寫入的；另一份則是 sidecar 的 stdout 和 stderr 對應的 JSON 文件。這對磁盤是很大的浪費 , 所以說，除非萬不得已或者應用容器完全不可能被修改。
另一種是每一個pod中都起一個日志收集agent（比如logstash或fluebtd）也就是相當於把方案一里的 logging agent放在了pod里。但是這種方案資源消耗(cpu，內存)較大，並且日志不會輸出到標准輸出，kubectl logs 會看不到日志內容。
- 應用容器中直接將日志推到存儲后端，這種方式就比較簡單了，直接在應用里面將日志內容發送到日志收集服務后端。
日志架構
通過上文對k8s日志收集方案的介紹，要想設計一個統一的日志收集系統，可以采用節點代理方式收集每個節點上容器的日志，日志的整體架構如圖所示。
解釋如下：
- 所有應用容器都是基於s6基底鏡像的，容器應用日志都會重定向到宿主機的某個目錄文件下比如/data/logs/namespace/appname/podname/log/xxxx.log
- log-agent 內部 包含 filebeat[7] ，logrotate 等工具，其中filebeat是作為日志文件收集的agent
- 通過filebeat將收集的日志發送到kafka
- kafka在講日志發送的es日志存儲/kibana檢索層
- logstash 作為中間工具主要用來在es中創建index和消費kafka 的消息
整個流程很好理解，但是需要解決的是
- 用戶部署的新應用，如何動態更新filebeat配置，
- 如何保證每個日志文件都被正常的rotate，
- 如果需要更多的功能則需要二次開發filebeat，使filebeat 支持更多的自定義配置。
付諸實踐
解決上述問題，就需要開發一個log-agent應用以daemonset形式運行在k8s集群的每個節點上，應用內部包含filebeat，logrotate，和需要開發的功能組件。
第一個問題，如何動態更新filebeat配置，可以利用http://github.com/fsnotify/fsnotify[8] 工具包監聽日志目錄變化create、delete事件，利用模板渲染的方法更新filebeat配置文件
第二個問題，利用http://github.com/robfig/cron[9] 工具包 創建cronJob，定期rotate日志文件，注意應用日志文件所屬用戶，如果不是root用戶所屬，可以在配置中設置切換用戶
/var/log/xxxx/xxxxx.log { su www-data www-data missingok notifempty size 1G copytruncate }
第三個問題，關於二次開發filebeat，可以參考博文 https://www.jianshu.com/p/fe3ac68f4a7a[10]
總結
本文只是對k8s日志收集提供了一個簡單的思路，關於日志收集可以根據公司的需求，因地制宜。