Kafka Monitor项目的动机有三个：
需要监控和测试Kafka部署并跟踪主干稳定性，以便他们能够尽早捕获正在开发的变更集中的问题； 需要不间断地在生产集群上监控SLA，并不断地在测试集群上运行回归测试； 现有的监控框架无法满足其用例的扩展性、模块化需求，他们需要一个自定义的客户端库。
网站可靠性工程部门过去已经监控了输入速率、离线分区数和正在复制的分区数等指标，以确定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页面提供了详细的信息。
本文转自d1net（转载）