任何系統運作後，都會產出系統記錄Log，Kubernetes Container環境下產出的log，經過標準輸出stdout後，存放於K8s worker node的目錄下/var/log/../*.log。
每個 node 都個別執行不同的 AP應用服務，並且隨著Pod的變動，Log屬性與目錄相對會隨著變動。
因此需要透過Log架構來特別處理此事。

Log架構

K8s 叢集環境中，worker node會隨著應用需求而異動、增減，因此我們在每個worker node上藉由DaemonSet方式來部署圖中的logging-agent-pod。

上述只是收集Log的開端，收集Log後我們還需要一套系統作為收集、分析、儲存、資料圖表等等。目前市面上這類系統，除了 ELK 之外，仍有其他眾多方案，如果是初期導入使用，建議可以先從 ELK 方面著手，等上手後如有更多不同因素需求面向，可以在評估其他可行方案。

ELK簡略

ELK 是三項開源方案的簡稱：Elasticsearch、Logstash 和 Kibana
現在官方有個新名稱：Elastic Stack

• Elasticsearch：簡稱 ES，是一套以Lucene基礎的搜尋引擎，基於Json格式而開發與應用，提供Web接口存放Log資料。ES 本身支援分散式架構，引擎是透過Java語言開發的，所以對Java based的服務運行需要有一定的學習與瞭解。
• Logstash：此作為收集Log的logging-agent角色，能夠採集、分析、過濾和傳送資料到 ES 或其他目的地。本身支援Grok語法可將非結構化log數據進行分析與組成結構化，例如IP地址解碼出地理坐標，匿名化或排除敏感字段，並簡化整體處理過程。
• Kibana：此為 ES 的開源數據圖表化方案。它在 ES 集群上所存在的Log索引內容之中提供圖表化功能。

抱歉，我不是故意要擾亂視聽......
因為，ELK名稱比較眾人所知......因此借題做開場說明。
回到環境中，下一篇我要用EFK作為 K8s 環境上Log收集的主要系統。
F = Fluent Bit