一條紀錄檔訊息的現代生活

從一條紀錄檔訊息的角度來巡覽現代分散式系統。

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

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 是正在迅速發展的功能強大的分散式平台。建立能夠在不影響效能的情況下抽象出分散式計算的複雜特性的系統至關重要。畢竟，如果我們不能簡化單一紀錄檔訊息的旅程，我們怎麼能誇耀全系統的效率呢？