一條日誌消息的現代生活

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

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

via: https://opensource.com/article/18/9/life-log-message

作者：Josef Karásek 選題：lujun9972 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive