UDN-企业互联网技术人气社区

板块导航

浏览  : 1478
回复  : 0

[其它] 开源的Kafka Monitor

[复制链接]
瞌睡虫的头像 楼主
发表于 2016-8-24 09:30:00 | 显示全部楼层 |阅读模式
  ApacheKafka已经成为了用于大规模流式数据的标准消息系统。在像LinkedIn这样的公司里,它作为用于各种数据管道和支撑各种关键任务服务的骨干。它已经成为一个公司基础架构的核心组件,应该是非常的强壮、容错并且高性能。

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

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

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

  在生产集群中持续监控SLAs

  在测试集群中持续运行回归测试

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

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

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

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

1.png



  测试

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

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

  生产服务,生产消息到Kafka中,并测量度量,比如生产速率和可用性。

  消费服务,从Kafka中消费数据,并测量度量,包括消息丢失率、消息重复率和端到端延迟。这个服务依赖生产服务来提供消息内嵌的消息序列号和时间戳。

  代理重启服务,根据一些预定义的计划来重启指定的代理。

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

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

2.png



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

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

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

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

  相关工作比较对于想要验证他们自己客户端库和Kafka集群的公司,KafkaMonitor是有用的。事实上,Micorosoft在Github上的开源项目也监控Kafka集群的可用性和端到端延迟。同样的,在这篇博客中,Netflix描述了一个持续发送心跳消息并测量消息延迟的监控服务。不同的是,KafkaMonitor更关注于可扩展性、模块化以及支持自定义的客户端库和场景

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

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

  (点击放大图像)

3.png



  未来的工作我们计划做一些改进,让KafkaMonitor更加有用。

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

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

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

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

文章来源:InfoQ
文章作者:Dong Lin

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部