昨天提到了維運團隊在平時就會有監控產品的流程，確認基礎設施運行沒有問題，但在 Devops 的精神結合進來後，監控的目標從「伺服器 A 的 CPU 使用率達 80%」，變為「金流的錯誤率在 10 分鐘內增加了 5%，謢接影響轉單率」。

這也讓監控的數字從分散在各處，轉為將日誌記錄統一集中起來，並讓團隊主動分析後預測接下來要優化的議題，而儀表板也不只有維運單位在看，而是對於團隊成員來說都是重要的。

「日誌」就像是飛機裡的黑盒子，會記錄所有程式碼運行時的每個事件，包含是否成功、發生時間、哪一位使用者及使用的機器等，所以當過往數據都分散在各地時，主動優化的流程也會變得繁複，所以將日誌集中化管理，彙整到中央平台進行儲存跟分析就變得重要。

常用的工具就是 ELK，包含了三個開源工具：Elasticsearch、Logstash、Kibana。

• Elasticsearch:負責的是儲存及搜集日誌。
• Logstash：搜集各個來源的數據後，將資料送到 Elasticsearch。
• Kibana：可以將日誌的數據呈現為圖表的工具。

與昨天提到的 Prometheus 跟 Grafana 不一樣的地方，如果以譬喻來說，Prometheus 跟 Grafana 會比較像是著重在「數值化數據（Metrics）」，用來回答「什麼地方出了問題？」「狀況有多嚴重？」，例如：網站的錯誤率在 15:00 突然從 1% 飆升到 20%。

ELK 則主要處理「文字型態的日誌（Logs）」，例如，用戶 ID 123456 的支付請求因為信用卡資訊無效而失敗，比較偏向故障診斷跟根本原因的分析，處理的是「為什麼會出錯？」

在 Devops 團隊中，這兩類型的工具常會搭配在一起使用，首先由 Prometheus 跟 Grafana 的儀表板上看到異常，再接著到 ELK 中去發現根本問題，讓團隊在最短的時間內解決線上問題。