开源的Kafka Monitor-InfoQ

Apache Kafka 已经成为了用于大规模流式数据的标准消息系统。在像 LinkedIn 这样的公司里，它作为用于各种数据管道和支撑各种关键任务服务的骨干。它已经成为一个公司基础架构的核心组件，应该是非常的强壮、容错并且高性能。

在过去，Kafka 站点可靠性工程师（SRE）依赖于 Kafka 服务器报告的度量（例如，字节写入速度、离线分区数、已复制分区数等等）来监控 Kafka 集群的可用性，如果其中的任何一个度量不可用，或者是任何一个度量值不正常，那么就有可能是某些东西出错了，SRE 需要介入来调查问题。但是，从 Kafka 集群的度量中获取可用性并不像它说的那么简单－－字节写入速度或者字节读取速度低并不一定能告诉我们集群是否可用，也不能给终端用户的可用性体验提供一个细致的测量（例如，在只有一部分分区离线的情况下）。当我们的 Kafka 集群变得更大、服务更多的关键服务时，可靠性和精确的测量 Kafka 集群的可用性变得越来越重要。

除了监控可用性，还必须监控主体的稳定性，并尽早捕获功能和性能中的任何恶化情况。Apache Kafka 在虚拟机中包含了一套单元测试和系统测试来发现 bug，然而我们偶尔仍然会看到一些 bug，直到 Kafka 已经部署在真实集群中几天甚至几周之后才会显现出来。这些 bug 会导致大量的操作开销甚至是服务中断，有时候这些问题很难重现，在开发者弄明白原因之前，SREs 可能需要回滚到早期版本，这增加了 Kafka 的开发和运营成本。在许多情况下，如果我们已经在各种故障切换方案中，通过延长持续时间和接入生产环境流量来测试 Kafka 的部署，这些 bug 能够更早被发现。

Kafka Monitor 是用于监控和测试 Kafka 部署的框架，通过提供以下能力来解决上述缺陷：

在生产集群中持续监控 SLAs
在测试集群中持续运行回归测试

在最近的 Kafka 峰会上，我们已经宣布在 Github 上开源了 Kafka Monitor。在未来，我们会继续开发 Kafka Monitor，并用它作为我们事实上的 Kafka 验证解决方案。我们希望它也能让其他想要验证和监控他们自己的 Kafka 部署的公司受益。

设计概述

Kafka Monitor 很容易部署，并在真实集群中长期运行特定的 Kafka 系统测试，和监控用户提供的已经存在的 Kafka 部署的 SLAs。

开发者通过组合可重用的模块能创建新的测试来模拟各种场景（比如，GC 暂停、broker 强制杀掉、反复重启、磁盘故障等）并收集度量，用户可以在测试集群或者生产集群上运行 Kafka Monitor 测试，根据用户定义的计划执行这些场景，验证 Kafka 在这些场景中依然按照预期在工作。为了收集这些目标，Kafka Monitor 是作为一批测试和服务的管理者来建模的。

一个给定的 Kafka Monitor 实例运行在一个 Java 进程中，可以在同一个进程中产生多个测试／服务。下图示范了服务、测试和 Kafka Monitor 实例之间的关系，以及 Kafka Monitor 如何与 Kafka 集群和用户进行交互。

测试

一个典型的测试会在一些预定义的计划中模拟许多的场景，会涉及到启动一些生产者／消费者，报告度量，和根据预定义的断言验证度量。例如，Kafka Monitor 会启动一个生产者、一个消费者，并且每 5 分钟随机重启一个代理（比如，如果它正在监控一个测试集群）。然后 Kafka Monitor 会测量可用性和消息丢失率，并通过 JMX 度量来公布这些，这样用户可以在一个健康仪表盘上实时的显示。如果消息丢失率大于用户指定的可用性模型中确定的一些阈值，它会发送警告。

服务

我们在服务中包含了模拟周期性／长期运行场景的逻辑，以便于更简单的从可复用的模块中组装测试。服务会生产自己的线程来执行场景和测量度量。例如，我们目前有以下服务：

生产服务，生产消息到 Kafka 中，并测量度量，比如生产速率和可用性。
消费服务，从 Kafka 中消费数据，并测量度量，包括消息丢失率、消息重复率和端到端延迟。这个服务依赖生产服务来提供消息内嵌的消息序列号和时间戳。
代理重启服务，根据一些预定义的计划来重启指定的代理。

测试由服务组成，并随着时间验证各种断言。例如，我们可以创建包括一个生产服务，一个消费服务和一个代理重启服务的测试。生产服务和消费服务会被配置成从同一个主题发送和接收消息。然后测试会验证消息丢失率始终为 0。

使用多个 Kafka Monitor 进行跨集群测试

虽然在相同 Kafka Monitor 实例中的服务必须运行在相同的物理机上，但是我们可以在不同的集群中启动多个 Kafka Monitor 实例，共同协调来组成一个分布式的端到端测试。在下图描述的测试中，我们在两个集群中启动了两个 Kafka Monitor 实例。第一个 Kafka Monitor 实例包含了一个生产服务来生产消息到 Kafka 集群 1，然后消息从集群 1 镜像到集群 2，最后在第二个 Kafka Monitor 实例中的消费服务从集群 2 中的相同主题消费消息，并报告跨集群管道的端到端延迟。

Kafka Monitor 在 LinkedIn 的使用

监控 Kafka 集群部署

早在 2016 年，我们就部署了 Kafka Monitor 来监控 LinkedIn 的每一个 Kafka 集群的可用性和端到端延迟。项目的 wiki 详细纪录了这些度量是如何被测量的。这些基本而关键的度量对于积极监控我们的 Kafka 集群部署环境的 SLAs 是非常有用的。

使用端到端工作流验证客户端库

就像早先的一篇博客说的那样，我们有一个客户端库，封装了原始的Apache Kafka 生产者和消费者，来提供许多Apache Kafka 所没有的特性，比如Avro 编码、审计和大消息支持。我们还有一个REST 客户端来允许非Java 应用程序生产和从Kafka 消费。为每个新的Kafka 发布版验证这些客户端库的功能是很重要的。Kafka Monitor 允许用户在它的端到端工作流中插入自定义的客户端库来使用。我们已经在测试中部署了使用封装的客户端和REST 客户端的Kafka Monitor 实例，来验证它们的性能和功能符合每一个新发布的客户端库和Apache Kafka 的要求。

保证新的Apache Kafka 内部版本的发布

一般我们脱离Apache Kafka 主干代码，每个季度裁剪一个新的内部发行版，或者从Apache Kafka 上收集新功能。脱离主干最显著的好处是部署在LinkedIn 生产环境的Kafka 集群能够在Apache Kafka 官方发行版之前，修复那些在Apache Kafka 主干中发现的问题。

鉴于脱离Apache Kafka 主干的风险，在部署新版本到生产环境的前几周，需要格外小心的在测试集群中－－从生产集群中接受镜像流量－－去证明每一个内部发行版。例如，我们重启或者直接停止代理，同时检查JMX 度量来验证这里确实有个控制器，并且没有离线的分区，为了在故障场景下验证Kafka 的可用性。在过去，这些步骤都是手动的，这非常耗时，并且不能很好的随着我们想要测试的事件数量和类型进行扩展。我们选择Kafka Monitor 来自动化这个过程，在持续的基础上涵盖更多的故障场景。

入门

Kafka Monitor 的源码放在Github 上，采用Apache 2.0 许可。使用说明、设计和未来的工作都记录在README 和项目 wiki 中。我们想听听你对项目的反馈意见。

虽然 Kafka Monitor 设计成一个测试和监控 Kafka 部署的框架，我们已经实现了一个基本的但是有用的测试，你可以直接使用它来监控你的 Kafka 部署。这个测试通过运行一个生产者和一个消费者，从同一个主题生产／消费消息，来测量可用性、端到端延迟、消息丢失率和消息重复率。你可以在终端、编写程序使用 HTTP GET 请求抓取，甚至是在如下屏幕截图的一个基于时间的简单（快速启动）GUI 中显示度量。请参考项目网站的使用说明，关于如何运行这个测试和显示各种度量。

(点击放大图像)