从Kafka Monitor源码解读看如何做好黑盒监控

众所周知，监控分为黑盒和白盒监控，黑盒监控是通过模拟外部用户对其可见的系统功能进行监控的一种监控方式。作为监控的重要一环，黑盒监控提供了让系统或者服务在发生故障时能够快速通知相关人员的能力。

通常情况下白盒监控的数据来自服务或系统自身（例如CPU负载、堆栈信息、连接数······），所以易于采集。而相对而言，黑盒监控的数据通常来自系统和服务外部，需要我们自己开发相关功能监控模块来完成采集。那么，黑盒监控如何做？如何才能在及时发现服务故障的同时不会引起其它问题？

重点对Kafka Monitor监控逻辑的部分代码进行解读

Kafka Monitor是由Linkedin开源的一款非常优秀的针对Kafka的黑盒监控软件。它通过模拟客户端行为，生产和消费数据并采集消息的延迟、错误率和重复率等性能和可用性指标，来达到黑盒监控的目的。

Kafka的主要概念

在介绍Kafka Monitor功能监控之前，我们先了解下Kafka的几个主要概念：

• Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker

• Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处

• Partition：Partition是物理上的概念，每个Topic包含一个或多个Partition

• Producer：消息生产者，负责发布消息到Kafka broker的客户端

• Consumer：消息消费者，读取Kafka broker消息的客户端

• Consumer Group：消费者组，每个Consumer属于一个特定的Consumer Group

图1 Kafka架构图

Kafka Monitor模块组成

kafka Monitor由以下五个服务组成

• Jetty Service：提供用于Web UI展示的HTTP服务

• Jolokia Service：提供JMX的HTTP接口

• Produce Service: 生产者服务，汇报生产速率和生产可用性

• Consumer Service: 消费者服务，汇报消费速率和可用性、消息的延迟、丢失率和重复率

• Metrics Service：接受Produce Service和Consumer Service汇报的监控指标

各服务之间的结构图如下

图2 Kafka monitor 结构图

监控工作流程及代码解读

Producer Service启动后以一定的时间为周期（配置项：produce.record.delay.ms，默认值：100ms）生产数据。需要注意的是，Producer Service会为每个Partition启动一个单独的生产任务，目的是为了让每个周期内生产的数据能够覆盖到所有Partition上。

图3 Producer Service代码解读

每条消息由以下内容组成：

• 消息序列号，用于在消费时检查消息是否丢失或重复

• 时间戳，用于计算消息从生产到消费的时延

• 消息的大小，用于指定序列化后的数据大小（配置项：produce.record.size.byte，默认值：100 byte）

• Topic和Producer ID，用于确保消费到的数据是来自同一Topic和Producer

每条消息序列化后提交到Kafka的指定Topic上，然后通过_sensors对象汇报失败或成功状态

图4 Producer Service代码解读2

Consumer Service从指定Topic消费读取消息，每条消息经过反序列化和校验后，计算出消息的延迟、错误或重复等监控指标，通过_sensors对象汇报到Metrics Service。

图5 Consumer Service代码解读

Kakfa Monitor优势总结

通过为每个Partition启动单独的生产任务，确保监控覆盖所有Partition。

这里需要注意的一点是：Kafka Monitor仅能够保证监控覆盖所有Partition，但不能保证覆盖所有Broker。所以，为保证监控覆盖所有Broker，利用Kafka对Partition在Broker的均衡分配原则，我们需要为Kafka Monitor的Topic配置与Broker相同（或整数倍）数量的Partition。

在生产的消息中包含了时间戳、序列号，Kafka Monitor可以依据这些数据对消息的延迟、丢失率和重复率进行统计。

通过设定消息生成的频率，来达到控制流量的目的。

生产的消息在序列化时指定为一个可配置的大小，这样做的好处有：

• 便于通过可配置的消息长度来验证Kafka对不同大小数据的处理能力

• 相同的消息大小可以减少Kafka对因每次处理不同大小数据的性能不均带来的监控误差

通过设定单独的Topic和Producer ID来操作Kafka集群，可避免污染线上数据，做到一定程度上的数据隔离。

通过上面的内容，相信大家对Kafka Monitor的黑盒监控实现方式有了一定认识。结合我们在做黑盒监控工作实践中遇到的问题，大致总结出黑盒监控需要注意的事项以及一些建议：

监控指标的采集

黑盒监控所采集的监控指标主要有两大类：性能和可用性，这两类监控项的采集可参考以下建议：

• 在读写类操作中，通过在消息体中携带Timestamp进行延时监控

• 使用固定字符串进行语义正确性的监控，避免仅仅针对返回的状态码来判断

样本覆盖率

黑盒监控的采集样本应尽可能覆盖所有节点，以便能够及时发现因节点宕机引起的故障。样本覆盖率应该是可以采集并可量化的。在实践中，我们建议在监控样本的请求中携带特定的可在服务端节点上识别的标签（可以是特定的源IP、用户名、请求头等等），这样便于统计样本覆盖率。

必要的流控

黑盒监控不是压力测试，应该避免过高的流量对线上服务产生冲击。必要时，流控的设定需要结合节点覆盖率和功能覆盖率两个指标进行。例如，我们在Zookeeper的黑盒监控实践中，考虑到Zookeeper的读写逻辑不同，承受的压力上限也不同，所以我们需要分别对读和写两个功能设定不同的监控样本数，这样就能够让两种功能的监控样本既能满足样本覆盖率，又不会对线上服务产生冲击。

数据隔离

受其特点决定，黑盒监控直接模拟用户行为对线上服务进行读写操作，所以必要的数据隔离是非常有必要的。具体的隔离方法需要视不同业务场景而定。例如，在HDFS的黑盒监控实践中，我们使用单独的与业务隔离的非特权账号，在指定的路径下读写数据。

功能覆盖率

黑盒监控应尽量覆盖所有（重要的）功能场景。此项需要我们对服务和线上使用场景有比较充分的了解。

超时处理

应对每个监控请求设定超时时间，避免因服务响应慢导致请求堆积而影响服务。

尽量简单

黑盒监控的实现逻辑应该在充分模拟外部用户行为的同时尽量简单，并减少对外部服务的依赖，这样可以降低因依赖方或监控本身的问题导致的监控数据异常。