k8s 日誌收集的那些套路

kubernetes日誌收集方案有幾種方案，都適用於什麼場景？本文對[k8s]經常使用日誌採集方案作了詳細介紹。

關於容器日誌

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 。可是上述配置的日誌收集也是經過Docker Daemon收集，收集日誌的速度依然是瓶頸。

log-driver 日誌收集速度
syslog 14.9 MB/s
json-file 37.9 MB/s

能不能找到不經過Docker Daemon收集日誌直接將日誌內容重定向到文件並自動 rotate的工具呢？答案是確定的採用基底鏡像。

S6-log 將 CMD 的標準輸出重定向到/.../default/current，而不是發送到 Docker Daemon，這樣就避免了 Docker Daemon 收集日誌的性能瓶頸。本文就是採用基底鏡像構建應用鏡像造成統一日誌收集方案。

關於k8s日誌

[k8s]日誌收集方案分紅三個級別：

• 應用(Pod)級別
• 節點級別
• 集羣級別

應用(Pod)級別

Pod級別的日誌 , 默認是輸出到標準輸出和標誌輸入，實際上跟docker 容器的一致。使用

kubectl logs pod-name -n namespace

查看。

節點級別

Node級別的日誌 , 經過配置容器的log-driver來進行管理 , 這種須要配合logrotare來進行 , 日誌超過最大限制 , 自動進行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 ，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/fs... 工具包監聽日誌目錄變化create、delete事件，利用模板渲染的方法更新filebeat配置文件

第二個問題，利用http://github.com/robfig/cron 工具包 建立cronJob，按期rotate日誌文件，注意應用日誌文件所屬用戶，若是不是root用戶所屬，能夠在配置中設置切換用戶

/var/log/xxxx/xxxxx.log {
      su www-data www-data
      missingok
      notifempty
      size 1G
      copytruncate
    }

總結

本文只是對k8s日誌收集提供了一個簡單的思路，關於日誌收集能夠根據公司的需求，因地制宜。