跳至主要内容

日誌記錄最佳實踐

在本指南中,我們建議叢集級日誌記錄和應用程式日誌記錄的最佳實踐。

在 Rancher v2.5 之前,Rancher 中的日誌記錄一直是相當靜態的整合。有一個固定的聚合器列表可供選擇(ElasticSearch、Splunk、Kafka、Fluentd 和 Syslog),並且只有兩個配置點可供選擇(叢集級和專案級)。

Rancher 為日誌聚合提供靈活的體驗。透過日誌記錄功能,管理員和使用者都可以部署符合細緻收集標準的日誌記錄,同時提供更廣泛的目的地和配置選項。

「在底層」,Rancher 日誌記錄使用 Logging operator。我們提供此運算子(及其資源)的可管理性,並將該體驗與管理你的 Rancher 叢集結合在一起。

叢集級日誌記錄​

叢集範圍抓取​

對於某些使用者來說,抓取叢集中執行的每個容器的日誌是理想的。這通常與你的安全團隊要求(或需求)從所有執行點收集所有日誌相符。

在這種情況下,建議至少建立兩個 ClusterOutput 物件 - 一個用於你的安全團隊(如果你有該需求),另一個用於你自己,即叢集管理員。建立這些物件時,請注意選擇可以處理來自整個叢集的大量日誌流量的輸出端點。同時確保選擇適當的索引來接收所有這些日誌。

一旦你建立了這些 ClusterOutput 物件,建立一個 ClusterFlow 來收集所有日誌。不要在此流上定義任何 Include 或 Exclude 規則。這將確保收集整個叢集的所有日誌。如果你有兩個 ClusterOutputs,請確保將日誌傳送到兩者。

Kubernetes 元件​

ClusterFlows 能夠從 Kubernetes 叢集中所有主機上的所有容器收集日誌。這在這些容器是 Kubernetes pod 一部分的情況下運作良好。

Rancher 的未來版本將包括來源容器名稱,這將啟用這些元件日誌的過濾。一旦進行了這項變更,你將能夠自訂 ClusterFlow 以僅檢索 Kubernetes 元件日誌,並將它們導向適當的輸出。

應用程式日誌記錄​

不僅在 Kubernetes 中,而且在所有基於容器的應用程式中,最佳實踐是將應用程式日誌導向 stdout/stderr。容器執行環境將會捕獲這些日誌並對它們做某些事情 - 通常是將它們寫入檔案。根據容器執行環境(及其配置),這些日誌可能最終出現在任何數量的位置。

在將日誌寫入檔案的情況下,Kubernetes 透過在每個主機上建立一個 /var/log/containers 目錄來提供幫助。此目錄將日誌檔案符號連結到它們的實際目的地(這可能因配置或容器執行環境而異)。

Rancher 日誌記錄將讀取 /var/log/containers 中的所有日誌條目,確保所有容器的所有日誌條目(假設為預設配置)都有機會被收集和處理。

特定日誌檔案​

日誌收集僅從 Kubernetes 中的 pod 檢索 stdout/stderr 日誌。但如果我們想從應用程式生成的其他檔案收集日誌怎麼辦?在這裡,一個(或兩個)日誌串流 sidecar 可能會派上用場。

設定串流 sidecar 的目標是將寫入磁碟的日誌檔案,將其內容串流到 stdout。這樣,Logging Operator 就可以收集這些日誌並將它們傳送到你所需的輸出。

要設定此項,編輯你的工作負載資源(例如 Deployment)並新增以下 sidecar 定義:

...
containers:
- args:
  - -F
  - /path/to/your/log/file.log
  command:
  - tail
  image: busybox
  name: stream-log-file-[name]
  volumeMounts:
  - mountPath: /path/to/your/log
    name: mounted-log
...

這將在你的工作負載定義中新增一個容器,該容器現在將(在此範例中)將 /path/to/your/log/file.log 的內容串流到 stdout。

然後,根據你設定的任何 Flows 或 ClusterFlows,此日誌串流將自動收集。你也可以考慮透過針對容器名稱專門為此日誌檔案建立一個 Flow。請參閱範例:

...
spec:
  match:
  - select:
      container_names:
      - stream-log-file-name
...

一般最佳實踐​

  • 盡可能輸出結構化日誌條目(例如 syslog、JSON)。這使得日誌條目的處理更容易,因為已經為這些格式編寫了解析器。
  • 嘗試在條目本身中提供建立日誌條目的應用程式名稱。這可以使故障排除更容易,因為 Kubernetes 物件並不總是將應用程式名稱作為物件名稱。例如,pod ID 可能是類似 myapp-098kjhsdf098sdf98 的東西,它不提供有關容器內執行的應用程式的太多資訊。
  • 除了在叢集範圍內收集所有日誌的情況外,請嘗試嚴格限定你的 Flow 和 ClusterFlow 物件的範圍。這使得在出現問題時更容易進行故障排除,並且還有助於確保不相關的日誌條目不會出現在你的聚合器中。嚴格範圍的範例是將 Flow 限制為命名空間中的單個 Deployment,或者甚至是 Pod 中的單個容器。
  • 除非進行故障排除,否則請保持日誌詳細程度較低。高日誌詳細程度會造成許多問題,其中最主要的是雜訊:重要事件可能會淹沒在大量的 DEBUG 訊息中。這在某種程度上透過自動警報和腳本得到緩解,但高度詳細的日誌記錄仍然會對日誌記錄基礎設施造成過度的壓力。
  • 盡可能嘗試在日誌條目中提供交易或請求 ID。這可以使跨多個日誌來源追蹤應用程式活動更容易,尤其是在處理分散式應用程式時。