一條日誌訊息的現代生活 | Linux 中國

混沌系統往往是不可預測的。在構建像分散式系統這樣複雜的東西時，這一點尤其明顯。如果不加以控制，這種不可預測性會無止境的浪費時間。因此，分散式系統的每個元件，無論多小，都必須設計成以簡化的方式組合在一起。

Kubernetes 為抽象計算資源提供了一個很有前景的模型 —— 但即使是它也必須與其他分散式平臺（如 Apache Kafka）協調一致，以確保可靠的資料傳輸。如果有人要整合這兩個平臺，它會如何運作？此外，如果你透過這樣的系統跟蹤像日誌訊息這麼簡單的東西，它會是什麼樣子？本文將重點介紹來自在 OKD 內執行的應用程式的日誌訊息如何透過 Kafka 進入資料倉庫（OKD 是為 Red Hat OpenShift 提供支援的 Kubernetes 的原初社群發行版）。

OKD 定義的環境

這樣的旅程始於 OKD，因為該容器平臺完全改寫了它抽象的硬體。這意味著日誌訊息等待由駐留在容器中的應用程式寫入 stdout 或 stderr 流。從那裡，日誌訊息被容器引擎（例如 CRI-O）重定向到節點的檔案系統。

在 OpenShift 中，一個或多個容器封裝在稱為 pod（豆莢）的虛擬計算節點中。實際上，在 OKD 中執行的所有應用程式都被抽象為 pod。這允許應用程式以統一的方式操縱。這也大大簡化了分散式元件之間的通訊，因為 pod 可以透過 IP 地址和負載均衡服務進行系統定址。因此，當日誌訊息由日誌收集器應用程式從節點的檔案系統獲取時，它可以很容易地傳遞到在 OpenShift 中執行的另一個 pod 中。

在豆莢裡的兩個豌豆

為了確保可以在整個分散式系統中四處傳播日誌訊息，日誌收集器需要將日誌訊息傳遞到在 OpenShift 中執行的 Kafka 叢集資料中心。透過 Kafka，日誌訊息可以以可靠且容錯的方式低延遲傳遞給消費應用程式。但是，為了在 OKD 定義的環境中獲得 Kafka 的好處，Kafka 需要完全整合到 OKD 中。

執行 Strimzi 操作子將所有 Kafka 元件實體化為 pod，並將它們整合在 OKD 環境中執行。這包括用於排隊日誌訊息的 Kafka 代理，用於從 Kafka 代理讀取和寫入的 Kafka 聯結器，以及用於管理 Kafka 叢集狀態的 Zookeeper 節點。Strimzi 還可以將日誌收集器實體化兼做 Kafka 聯結器，允許日誌收集器將日誌訊息直接提供給在 OKD 中執行的 Kafka 代理 pod。

在 OKD 內的 Kafka

當日誌收集器 pod 將日誌訊息傳遞給 Kafka 代理時，收集器會寫到單個代理分割槽，並將日誌訊息附加到該分割槽的末尾。使用 Kafka 的一個優點是它將日誌收集器與日誌的最終標的分離。由於解耦，日誌收集器不關心日誌最後是放在 Elasticsearch、Hadoop、Amazon S3 中的某個還是全都。Kafka 與所有基礎設施連線良好，因此 Kafka 聯結器可以在任何需要的地方獲取日誌訊息。

一旦寫入 Kafka 代理的分割槽，該日誌訊息就會在 Kafka 叢集內的跨代理分割槽複製。這是它的一個非常強大的概念；結合平臺的自愈功能，它建立了一個非常有彈性的分散式系統。例如，當節點變得不可用時，（故障）節點上執行的應用程式幾乎立即在健康節點上生成。因此，即使帶有 Kafka 代理的節點丟失或損壞，日誌訊息也能保證存活在盡可能多的節點上，並且新的 Kafka 代理將快速原位取代。

儲存起來

在日誌訊息被提交到 Kafka 主題後，它將等待 Kafka 聯結器使用它，該聯結器將日誌訊息中繼到分析引擎或日誌記錄倉庫。在傳遞到其最終目的地時，可以分析日誌訊息以進行異常檢測，也可以查詢日誌以立即進行根本原因分析，或用於其他目的。無論哪種方式，日誌訊息都由 Kafka 以安全可靠的方式傳送到目的地。

OKD 和 Kafka 是正在迅速發展的功能強大的分散式平臺。建立能夠在不影響效能的情況下抽象出分散式計算的複雜特性的系統至關重要。畢竟，如果我們不能簡化單一日誌訊息的旅程，我們怎麼能誇耀全系統的效率呢？
分享