众所周知，监控分为黑盒和白盒监控，黑盒监控是通过模拟外部用户对其可见的系统功能进行监控的一种监控方式。作为监控的重要一环，黑盒监控提供了让系统或者服务在发生故障时能够快速通知相关人员的能力。
通常情况下白盒监控的数据来自服务或系统自身（例如 CPU 负载、堆栈信息、连接数······），所以易于采集。而相对而言，黑盒监控的数据通常来自系统和服务外部，需要我们自己开发相关功能监控模块来完成采集。那么，黑盒监控如何做？如何才能在及时发现服务故障的同时不会引起其它问题？
本文将分享京东云在 Kafka 黑盒监控方面的一些实践经验，其中着重对 Kafka Monitor 监控逻辑的部分代码进行解读，以便大家能够对其优秀的设计有一个更为深入的了解。然后再结合我们在其它服务中的黑盒监控实践，来试图回答上面提出的问题。
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
Kafka Monitor 模块组成
1.kafka Monitor 由以下五个服务组成
-
Jetty Service：提供用于 Web UI 展示的 HTTP 服务
-
Jolokia Service：提供 JMX 的 HTTP 接口
-
Produce Service: 生产者服务，汇报生产速率和生产可用性
-
Consumer Service: 消费者服务，汇报消费速率和可用性、消息的延迟、丢失率和重复率
-
Metrics Service：接受 Produce Service 和 Consumer Service 汇报的监控指标
2. 各服务之间的结构图如下
监控工作流程及代码解读
1.Producer Service 启动后以一定的时间为周期（配置项： produce.record.delay.ms ，默认值：100ms）生产数据。
需要注意的是，Producer Service 会为每个 Partition 启动一个单独的生产任务，目的是为了让每个周期内生产的数据能够覆盖到所有 Partition 上。
- 每条消息由以下内容组成：
-
消息序列号，用于在消费时检查消息是否丢失或重复
-
时间戳，用于计算消息从生产到消费的时延
-
消息的大小，用于指定序列化后的数据大小（配置项：produce.record.size.byte，默认值：100 byte）
-
Topic 和 Producer ID，用于确保消费到的数据是来自同一 Topic 和 Producer
每条消息序列化后提交到 Kafka 的指定 Topic 上，然后通过 _sensors 对象汇报失败或成功状态
3.Consumer Service 从指定 Topic 消费读取消息，每条消息经过反序列化和校验后，计算出消息的延迟、错误或重复等监控指标，通过 _sensors 对象汇报到 Metrics Service。
Kakfa Monitor 优势总结
1. 通过为每个 Partition 启动单独的生产任务，确保监控覆盖所有 Partition。
这里需要注意的一点是：Kafka Monitor 仅能够保证监控覆盖所有 Partition，但不能保证覆盖所有 Broker。所以，为保证监控覆盖所有 Broker，利用 Kafka 对 Partition 在 Broker 的均衡分配原则，我们需要为 Kafka Monitor 的 Topic 配置与 Broker 相同（或整数倍）数量的 Partition。
2. 在生产的消息中包含了时间戳、序列号，Kafka Monitor 可以依据这些数据对消息的延迟、丢失率和重复率进行统计。
3. 通过设定消息生成的频率，来达到控制流量的目的。
4. 生产的消息在序列化时指定为一个可配置的大小，这样做的好处有：
-
便于通过可配置的消息长度来验证 Kafka 对不同大小数据的处理能力
-
相同的消息大小可以减少 Kafka 对因每次处理不同大小数据的性能不均带来的监控误差
5. 通过设定单独的 Topic 和 Producer ID 来操作 Kafka 集群，可避免污染线上数据，做到一定程度上的数据隔离。
如何做黑盒监控
通过上面的内容，相信大家对 Kafka Monitor 的黑盒监控实现方式有了一定认识。结合我们在做黑盒监控工作实践中遇到的问题，大致总结出黑盒监控需要注意的事项以及一些建议：
监控指标的采集
黑盒监控所采集的监控指标主要有两大类：性能和可用性，这两类监控项的采集可参考以下建议：
-
在读写类操作中，通过在消息体中携带 Timestamp 进行延时监控
-
使用固定字符串进行语义正确性的监控，避免仅仅针对返回的状态码来判断
样本覆盖率
黑盒监控的采集样本应尽可能覆盖所有节点，以便能够及时发现因节点宕机引起的故障。样本覆盖率应该是可以采集并可量化的。在实践中，我们建议在监控样本的请求中携带特定的可在服务端节点上识别的标签（可以是特定的源 IP、用户名、请求头等等），这样便于统计样本覆盖率。
必要的流控
黑盒监控不是压力测试，应该避免过高的流量对线上服务产生冲击。必要时，流控的设定需要结合节点覆盖率和功能覆盖率两个指标进行。例如，我们在 Zookeeper 的黑盒监控实践中，考虑到 Zookeeper 的读写逻辑不同，承受的压力上限也不同，所以我们需要分别对读和写两个功能设定不同的监控样本数，这样就能够让两种功能的监控样本既能满足样本覆盖率，又不会对线上服务产生冲击。
数据隔离
受其特点决定，黑盒监控直接模拟用户行为对线上服务进行读写操作，所以必要的数据隔离是非常有必要的。具体的隔离方法需要视不同业务场景而定。例如，在 HDFS 的黑盒监控实践中，我们使用单独的与业务隔离的非特权账号，在指定的路径下读写数据。
功能覆盖率
黑盒监控应尽量覆盖所有（重要的）功能场景。此项需要我们对服务和线上使用场景有比较充分的了解。
超时处理
应对每个监控请求设定超时时间，避免因服务响应慢导致请求堆积而影响服务。
尽量简单
黑盒监控的实现逻辑应该在充分模拟外部用户行为的同时尽量简单，并减少对外部服务的依赖，这样可以降低因依赖方或监控本身的问题导致的监控数据异常。
文章转载自微信公众号京东云。
评论