写点什么

开源的 Kafka Monitor

2016 年 8 月 23 日

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 )关注我们。

2016 年 8 月 23 日 17:287692

评论

发布
暂无评论
发现更多内容

小师妹学JavaIO之:文件读取那些事

程序那些事

Java io nio Java 25 周年 小师妹

Kafka系列10:面试题是否有必要深入了解其背后的原理?我觉得应该刨根究底(下)

z小赵

大数据 kafka 面试 实时计算

String五连杀!

Bruce Duan

Java string equals

Week1 总结

TiK

极客大学架构师训练营

架构师训练营 听课总结 -- 第一周

傅晶

极客大学架构师训练营

UML 练习 食堂就餐卡

Mr.hou

极客大学架构师训练营

快速复制文件rsync、tar

唯爱

Char和编码

拾贝

Java

极客时间 - 架构师训练营 - week1 - 课堂笔记

毛聪

极客大学架构师训练营

小师妹学JavaIO之:目录还是文件

程序那些事

Java io nio Java 25 周年 小师妹

食堂就餐卡系统概要设计

小小杨

极客大学架构师训练营

小师妹学JavaIO之:文件File和路径Path

程序那些事

Java io nio Java 25 周年 小师妹

架构师训练营-作业1-食堂就餐卡系统设计

狂奔嘀兔纸

极客大学架构师训练营

【架构师训练营】第 1 周作业1—食堂就餐卡系统设计

花生无翼

极客大学架构师训练营

考虑用静态工厂方法代替构造器

dreamer

Java 互联网 后端 开发

源码分析 | 手写mybait-spring核心功能(干货好文一次学会工厂bean、类代理、bean注册的使用)

小傅哥

spring 源码 源码分析 小傅哥 mybatis

架构师训练营第一周总结

一剑

游戏夜读 | vim一份极简手册

game1night

数据结构与算法之数组链表

shirley

数组 链表

小师妹学JavaIO之:文件写入那些事

程序那些事

Java io nio Java 25 周年 小师妹

架构师训练营 作业 -- 第一周

傅晶

极客大学架构师训练营

架构师0期作业-20200606

caibird1984

极客大学架构师训练营

食堂就餐卡系统设计

TiK

搞定 HTTP 协议(二):HTTP 协议总览

零和幺

HTTP

「架构师训练营」第 1 周作业 - 食堂就餐卡系统设计

旭东(Frank)

架构 极客大学架构师训练营 作业

ARTS-第一周

爱睡的猫

食堂就餐卡系统设计

戴维斯

小师妹学JavaIO之:文件编码和字符集Unicode

程序那些事

io nio Java 25 周年 小师妹

架构师训练营第一周总结

小小杨

极客大学架构师训练营

Chaos is a ladder——近期工作体会

石君

职场 职场成长 工作体会

食堂就餐卡系统架构设计文档

竹森先生

极客大学 架构设计 极客大学架构师训练营

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

开源的Kafka Monitor-InfoQ