BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

开源的Kafka Monitor

| 作者 Dong Lin 关注 0 他的粉丝 ,译者 覃璐 关注 0 他的粉丝 发布于 2016年8月24日. 估计阅读时间: 12 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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 集群的公司,Kafka Monitor 是有用的。事实上,Micorosoft 在Github 上的开源项目也监控Kafka 集群的可用性和端到端延迟。同样的,在这篇博客中,Netflix 描述了一个持续发送心跳消息并测量消息延迟的监控服务。不同的是,Kafka Monitor 更关注于可扩展性、模块化以及支持自定义的客户端库和场景

入门

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

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

(点击放大图像)

未来的工作

我们计划做一些改进,让Kafka Monitor 更加有用。

增加测试场景

Apache Kafka 包含一套广泛的系统测试,在每次签入时运行。我们计划在Kafka Monitor 实现类似的测试,部署到LinkedIn 的测试集群中,并持续的运行它们。这会让我们捕获到性能下降和验证特性的功能,比如配额、管理操作和授权,等等。

集成Graphite 和类似的框架

让用户在他们的组织中,通过一个web 服务看到所有的Kafka 相关的度量是很有用的。我们计划改善Kafka Monitor 现有的报告服务,使用户可以导出Kafka Monitor 度量到Graphite 或者他们选择的其他度量框架。

集成故障注入框架

我们还计划为Kafka Monitor 集成一个失败注入框架(名叫Simoorg),在更全面的失败场景下测试Kafka,比如磁盘鼓掌和数据损坏。

致谢

Kafka Monitor 的设计和实现感谢LinedIn 的Kafka 组的努力。

查看英文原文:Open Sourcing Kafka Monitor


感谢陈兴璐对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

错别字 by Terry Berg

磁盘鼓掌什么鬼?应该是磁盘故障

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT