由於 OKD 資料尚未整理完，這邊先將未來要介紹的章節先 Po 出來待 OKD 資料整理完再來調整。
請各位體諒:"P

Log訊息的重要性

在日常生活上如果有寫日記習慣的人，若是某一天發生重大事故的時候我們可以從日記的內容推敲以前發生什麼事情，日誌可以幫助釐清事情的脈絡與原因。

在 Linux 的世界也是一樣的，應用程式每天會產生入各式各樣的日誌 ( Log ) 訊息，例如 System Log 訊息、 Applecation Log 訊息．．．等等，這些 Log 訊息通常儲存於應用程式所執行的主機 ( Host ) 上，若是某一天機房內的鎮店之寶乖乖無法發揮作用的時候，也就是我們的應用程式非常不幸的發生故障了，維運人員就需要登入伺服器，使用 Linux 提供的 awk / grep / sed ．．．等工具從這些茫茫的 Log 大海裡找尋故障原因。當今天應用程式拆分為微服務 ( Microservice ) 型態並且部署到不同主機上的時候，維運人員需要先定位是哪一個微服務出了狀況再查詢出狀況的微服務是在哪一個主機上，最後透過上面提到的工具找尋相關的 Log 訊息並排除錯誤。

面對海量的數據，又是分佈在各個不同地方，這樣找尋 Log 訊息一系列的動作，對於維運人員需要及時回報故障原因以及排查故障，這樣一個口令一個動作的方法顯得非常笨拙和低效。如果有一套集中式的 Log 系統能把不同來源的 Log 訊息集中式的管理，並且提供查詢的功能的話，不僅可以提高除錯的效率也能大幅度降低服務發生故障事後救火的無力感。

針對本文所提到問題與需求，為了能在 Kubernetes Container 叢集管理系統中提供分散式的即時日誌蒐集和分析監控系統，在這三十天的短跑中我嘗試了業界常見的日誌蒐集和分析與管理解決方案 - 包括三個開源專案 Elasticsearch 、 Fluentd 和 Kibana 三個系統。業界取三個系統名稱開頭的第一個字母，並且將這套架構稱為EFK，我將會針對此一系統做詳細的介紹。