日志消息的一天

混沌系统往往是不可预测的。在构建像分布式系统这样复杂的东西时，这一点尤其明显。如果不加以控制，这种不可预测性会浪费大量的时间。这就是为什么分布式系统的每个组件，无论多么小，都必须设计成以一种简化的方式组合在一起。

Kubernetes 为抽象计算资源提供了一个有前景的模型——但即使它也必须与诸如 Apache Kafka 等其他分布式平台协调，以确保可靠的数据交付。如果有人要集成这两个平台，它将如何工作？此外，如果要跟踪像日志消息这样简单的东西通过这样的系统，它会是什么样子？本文将重点介绍来自运行在 OKD（为 Red Hat OpenShift 提供支持的 Kubernetes 的 Origin 社区发行版）中的应用程序的日志消息如何通过 Kafka 到达数据仓库。

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 brokers、用于从 Kafka brokers 读取和写入的 Kafka connectors 和用于管理 Kafka 集群状态的 Zookeeper 节点。Strimzi 还可以实例化日志收集器以兼作 Kafka connector，从而允许日志收集器将日志消息直接馈送到在 OKD 中运行的 Kafka broker Pod。

OKD 内部的 Kafka

当日志收集器 Pod 将日志消息传递到 Kafka broker 时，收集器会写入单个 broker 分区，并将消息追加到分区的末尾。使用 Kafka 的一个优势是它将日志收集器与日志的最终目标分离。由于解耦，日志收集器不关心日志最终是否位于 Elasticsearch、Hadoop、Amazon S3 或所有这些中。Kafka 与所有基础设施连接良好，因此 Kafka connectors 可以将日志消息发送到它需要去的地方。

一旦写入 Kafka broker 的分区，日志消息就会在 Kafka 集群内的 broker 分区中复制。这本身就是一个非常强大的概念；与平台的自我修复功能相结合，它创造了一个非常强大的分布式系统。例如，当节点变得不可用时，在该节点上运行的应用程序几乎会立即在健康的节点上生成。因此，即使带有 Kafka broker 的节点丢失或损坏，日志消息也保证像它被复制的次数一样存活，并且一个新的 Kafka broker 将迅速取代原来的位置。

前往存储

在提交到 Kafka topic 之后，日志消息等待被 Kafka connector sink 使用，该 sink 将日志消息中继到分析引擎或日志记录仓库。交付到其最终目的地后，可以研究日志消息以进行异常检测、查询以进行即时根本原因分析或用于其他目的。无论哪种方式，日志消息都由 Kafka 以安全可靠的方式传递到其目的地。

OKD 和 Kafka 是强大的分布式平台，它们正在迅速发展。创建能够抽象分布式计算的复杂性而不影响性能的系统至关重要。毕竟，如果我们不能简化单个日志消息的旅程，我们又如何吹嘘整个系统的效率呢？

Kyle Liberti 和 Josef Karasek 将在 Open Source Summit Europe 上展示 日志消息的一天：导航现代分布式系统，10 月 22 日至 24 日，苏格兰爱丁堡。