在2016年4月份举行的 Kafka峰会 上,LinkedIn在 Apache 2.0许可协议 下 开源 了 Kafka Monitor,并于近日 详细介绍 了该监控工具的 架构 以及他们最初的构建动机。在年初的时候,LinkedIn曾在一篇有关Kafka整体应用的文章中简单地 提及 过Kafka Monitor,但并没有详细介绍该项目的语义组成或者背后的动机。
Kafka Monitor项目的动机有三个:
网站可靠性工程部门过去已经监控了输入速率、离线分区数和正在复制的分区数等指标,以确定Kafka集群的可用性和系统整体的健康状况。然而,问题在于,这类原始的值本身无法表明集群在终端用户体验方面是否真的可用。
在LinkedIn的 公开出版物 Keystone Pipeline里,他们提到了两个潜在的Kafka候选监控方案,微软的一个 项目 和Netflix Kafka监控,但最终确定它们不适合自己的应用场景。
Kafka Monitor允许开发人员组合模拟各种故障场景的模块,如GC中断、broker硬杀及“滚动弹出(rolling bounces)”、磁盘故障,并随着场景进行收集有关服务运行时行为的指标。每次当生产者创建消息时抛出的异常被捕获,衡量生产者服务错误率的指标就会增加。消费者服务会跟踪一个由Kafka分区分割的增量索引计数器以及消息净荷的时间戳,以便度量消息丢失率、重复率以及端到端延迟。
Kafka Monitor实例运行在一个单独的Java进程中,运行多个测试,介于用户或消费者服务与Kafka集群之间。Kafka Monitor收集的运行时指标包括生产者服务的生产效率、消费者服务的消费效率、消息丢失、消息重复和端到端延迟。多个Kafka Monitor跨多个Kafka集群运行大量的测试场景,这可以由一个 复制 服务通过镜像方式捕获跨集群的总体延迟指标。
Kafka Monitor原生支持Java,但也为非JVM语言提供了一个 REST 接口。这对开源社区有着特殊的意义,LinkedIn的 Dong Lin 表示:
我们一般会脱离Apache Kafka主干,并每季度生成一个新的内部版本,或者吸收Apache Kafka的新特性。脱离主干的一个显著的好处是,部署在LinkedIn生产集群中的Kafka经常有已经在Apache Kafka主干中检测到的问题,他们可以在Apache Kafka正式版本发布之前进行修复。
Kafka项目本身包含一些系统测试,每次代码捡入时都会运行,鉴于和Kafka主干的紧密关系,LinkedIn计划实现类似的系统测试。他们希望将Kafka Monitor和类似 Simoorg 这样的错误注入框架以及 Graphite 或类似的框架集成,以便能够通过一个单独的Web服务查看Kafka Monitor集群生成的所有指标。
LinkedIn还简单地提到了如何设置基本的监控,生成并 可视化 核心指标。他们的 GitHub 页面提供了详细的信息。
查看英文原文: LinkedIn Details Open-Sourced Kafka Monitor