LinkedIn开源Kafka Monitor

一个关于Kafka的监控测试框架

原文请查阅连接。

Apache Kafka 已经成为了一个面向大规模流数据的，标准的消息系统。在Linkedin这样的公司， 它被用做各种数据管道的主力，支持一系列关键服务。它已经成为确保企业基础架构健壮、容错和高性能的核心组件。

在过去， Kafka 网站高可用工程师 （SRE）必须依赖Kafka服务器的报告来度量、监控一个Kafka集群 （例如，访问流量，离线分区计数，under-replicated分区计数，等等）。若是任何一个指标不可用，或者任何指标的值是异常的， 都有多是某些方面出错了，SRE则 须要介入问题排查。然而，从一个Kafka集群得到这些指标并不像听起来那么容易—不管集群是否可用， 一个很低的流入流出值并不没有必要告诉咱们，也不能为最终用户提供一个基于可用性经验的、细粒度的参考结果 （好比说，在这个事件中描述道：只是一个分区的子集异常了）。随着咱们的集群增加得越发庞大，为愈来愈多的重要业务提供服务， 可靠、精确地度量Kafka集群可用性的能力，也就变得愈来愈重要。

为了监控可用性，有必要主干的稳定性，从功能上或性能方面尽量早的捕获可回溯的信息。 Apache Kafka 在虚拟机中包含一系列单元测试和系统测试方法，用于检测错误。 到目前为止，咱们仍然能发现一些偶发错误，它们直到Kafka在真实的集群中已经部署不少天甚至几周以后才显现。 这些错误会引发许多运行时开销或者致使服务中断。有些时候该问题很难被重现，SRE工程师只能在开发者找到缘由以前回退到上一个版本， 这显然要增长Kafka的部署和维护成本。在许多状况下，这些错误能够在更早的阶段就被探查出来， 假如咱们能够在一个具有多样化故障转移的环境部署Kafka，同时加载生产规模的流量、延长持续时间。

Kafka Monitor 是一个监控测试Kafka部署状况的框架，能够帮助咱们针对上面的不足提供如下能力： （a）在生产集群持续监测SLA （b）在测试集群持续进行回归测试。 在最近的 KafkaSummit 咱们已经宣布在 Github上开源 Kafka Monitor。 接下来咱们将继续开发 Kafka Monitor 并把它做为咱们事实上的Kafka认证解决方案。 咱们但愿它也能使别的公司从中收益，那些但愿验证和监控它们本身的Kafka部署状况的公司。

设计概览

Kafka Monitor 使得这些事情变得很容易： 在真实的生产集群中，开发和执行长时间运行特定的Kafka系统测试，基于用户提供的SLA监控已经部署的Kafka。

开发者能够建立新的测试，经过组装可复用的组件，用来仿真各类各样的场景（例如 GC 中断，代理被硬杀，回滚，磁盘故障，等等），收集指标；用户能够运行 K afka Monitor测试用例，在这些场景执行的时候能够伴随用户定义的定时任务， 不管是测试集群仍是生产集群，都可以验证，Kafka在这些场景下，是否可以达到预期效果。 为了实现上述目标，Kafka Monitor 的设计模型包含一系列测试结果收集器和服务。

一个Kafka Monitor 实例运行在一个单独的Java进程，在相同的进程里能够再产生多个测试用例和服务。 下面的示意图表达了服务，测试用例和Kafka Monitor实例之间的关系，也能够知道Kafka Monitor 如何在Kafka集群和用户之间相互做用。

测试

一个典型的测试，将仿真一系列场景，基于某些前期已经定义的定时任务，须要启动一些生产者／消费者，上报指标，验证指标值是否符合前期定义的断言。举个例子，Kafka Monitor 可以启动一个生产者，一个消费者，每五分钟反射一个随机代理（比方说，若是说它是监控一个测试集群）。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集群的SLA很是有用。 在端到端工做流中验证客户端库 正如早先发布的一篇BLOG中说明的那样，咱们有一个客户端的库，缠绕在普通的Apache Kafka生产者和消费者， 用于提供一些 Apache Kafka 没法支持的特性，例如Avro编码，审计和大消息支持。咱们也有一个REST客户端， 它容许非JAVA应用程序从Kafka生产和消费数据。这些客户端库和每个新的Kafka release版本，验证它们的功能可用性是很是重要的。 Kafka Monitor容许用户将客户端库做为插件，加入到它的端到端工做流中。咱们已经部署的Kafka Monitor实例， 已经在测试中使用咱们封装的客户端和REST客户端，用于验证它们的性能和功能，使得这些客户端库和Apache Kafka的每个新的release版本都能符合要求。

验证Apache Kafka新的内部Release版本

咱们一般每一个季度都会从Apache Kafka的主干版本复制代码，而后创建一个新的内部release版本，或者吸取Apache Kafka新的特性。 从主干复制代码的一个重要的收益就是，部署Kafka到LinkedIn的生产集群以后，一般能在Apache Kafka的主干版本上探查到一些问题， 这样的话咱们就能在Apache Kafka 官方正式的release发布以前得到修复。 基于复制Apache Kafka主干版本可能存在的风险，咱们作了额外的工做，在一个测试集群中验证每一个内部release版本—从生产集群中得到镜像流量—几周之前生产环境部署新的release。 举例来讲，咱们执行回退或者硬杀掉代理的时候，须要检查JMX指标去验证确实有一个控制进程而且没有离线分区，为了验证Kafka在故障迁移场景中的可用性。 在过去，这些步骤都是手工进行的，很是消耗时间，而且咱们有大量事件和许多场景须要测试，这种方式的伸缩性就很是差。咱们切换到Kafka Monitor以后， 这个过程就自动化了，而且能够覆盖更多故障迁移的场景，并且是能够持续进行的。

相关工做的比较

Kafka Monitor对其它公司而言也是有用的，能够帮助验证他们本身的客户端库和Kafka集群。 固然Microsoft也已经在Github上有了一个开源项目，也是监控室Kafka集群的可用性和端到端时延。 一样地，在这篇发表的博客中，Netflix介绍了一种监控服务，即发送持续的心跳消息，同时度量这些消息的时延。 Kafka Monitor本身的特色就是专一于可扩展性，模块化以及客户端库和多样化场景支持。

开始

Kafka Monitor的源代码能够从Github下载，基于Apache 2.0 受权协议。使用指南，设计文档和将来规划在README文件和项目wiki中能够查阅。咱们很乐于听到你对该项目的反馈意见。当Kafka Monitor被设计用来做为，测试和监控Kafka部署状况的框架的时候，咱们视线了一个基本的可是有用的测试，确保你能开箱即用。这些测试能够度量可用性，端到端时延，消息丢包率以及消息复制速率，经过运行一个生产者和一个消费者，它们使用同一个主题生产／处理消息。你能够在终端看到这些指标，基于HTTP GET请求、程序化地得到它们的值，甚至随着时间查看它们的值，经过一个简单（快速启动）的图形界面，以下面的截图所示。关于如何运行测试、查看指标的详细介绍内容请参阅项目网站。

将来的工做

咱们的计划中有许多工做要作，改进、提高Kafka Monitor，使它更有用。

加强测试场景

每次执行代码check-in的时候，Apache Kafka包含了一大批系统测试。咱们计划在Kafka Monitor中实现一个简单的测试， 而后部署到LinkedIn的测试集群，最终作到持续运行这些测试。这使得咱们能够在问题发生的时候进行性能回溯， 还能够验证各类特性的是否可用，例如限额、管理操做，受权，等等。

整合Graphite和相似的框架

它对用户来讲很是有用，能够在他们的组织内，经过一个简单的web服务查看全部跟Kafka相关的指标。 咱们计划在Kafka Monitor 中提高现有的报表服务，这样用户就可以导出Kafka Monitor的指标到Graphite或者他们选择的其它框架 整合故障注入框架 咱们也计划将Kafka Monitor与故障注入框架整合（名叫 Simoorg），能够测试、收集Kafka在更全面的故障迁移场景中的处理能力，例如磁盘故障或者数据错误。

鸣谢

Kafka Monitor可以被设计和实现出来，应该感谢LinkedIn Kafka 团队的努力。

咱们在招聘

LinkedIn 数据流基础设施群组 正在 招聘Kafka方向的软件开发工程师和网站可用性工程师， 致力于咱们的流数据处理平台（Samza）以及咱们的下一代变化捕获技术。 更多细节请联系 Kartik Paramasivam 。

更多精彩内容扫码关注公众号：RiboseYim's Blog：https://riboseyim.github.io