21.4. 分析 Kafka JMX 指标以进行故障排除
JMX 提供了收集有关 Kafka 代理的指标,以监控和管理其性能和资源使用情况。通过分析这些指标,可以诊断和解决高 CPU 用量、内存泄漏、线程争用以及响应时间较慢的代理问题。某些指标可以找出这些问题的根本原因。
JMX 指标还深入了解 Kafka 集群的整体健康状况和性能。它们有助于监控系统吞吐量、延迟和可用性、诊断问题并优化性能。本节探索使用 JMX 指标来帮助识别常见问题,并深入了解 Kafka 集群的性能。
使用 Prometheus 和 Grafana 等工具收集和绘制这些指标,您可以视觉化返回的信息。这在检测问题或优化性能方面特别有用。随着时间的推移图表指标还可帮助识别趋势和预测资源消耗。
21.4.1. 检查已复制分区 复制链接链接已复制到粘贴板!
对于最佳性能,平衡 Kafka 集群非常重要。在均衡集群中,分区和领导层在所有代理中平均分布,I/O 指标则反映了这一点。另外,您还可以使用 kafka-topics.sh
工具获得复制分区列表并识别有问题的代理。如果复制分区的数量波动或多个代理显示高请求延迟,这通常表示集群中需要调查的性能问题。另一方面,集群中许多代理报告的非复制分区数量通常表示集群中的其中一个代理处于离线状态。
使用 kafka-topics.sh
工具中的 describe --under-replicated-partitions
选项来显示集群中当前复制的分区的信息。这些是副本比配置的复制因素少的分区。
如果输出为空,则 Kafka 集群没有复制的分区。否则,输出显示没有同步或可用的副本。
在以下示例中,每个分区只有 3 个中的 2 个副本同步,ISR (同步副本)中缺少一个副本。
从命令行返回重复分区的信息
bin/kafka-topics.sh --bootstrap-server :9092 --describe --under-replicated-partitions Topic: topic-1 Partition: 0 Leader: 4 Replicas: 4,2,3 Isr: 4,3 Topic: topic-1 Partition: 1 Leader: 3 Replicas: 2,3,4 Isr: 3,4 Topic: topic-1 Partition: 2 Leader: 3 Replicas: 3,4,2 Isr: 3,4
bin/kafka-topics.sh --bootstrap-server :9092 --describe --under-replicated-partitions
Topic: topic-1 Partition: 0 Leader: 4 Replicas: 4,2,3 Isr: 4,3
Topic: topic-1 Partition: 1 Leader: 3 Replicas: 2,3,4 Isr: 3,4
Topic: topic-1 Partition: 2 Leader: 3 Replicas: 3,4,2 Isr: 3,4
以下是检查 I/O 和重复分区的一些指标:
检查重复分区的指标
如果为高可用性设置了主题配置,则主题至少为 3 的复制因素,最小同步副本的数量小于复制因素 1 个,没有复制的分区仍然可以使用。相反,低于最低 ISR 的分区会减少可用性。您可以使用 kafka-topics.sh
工具中的 kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount
指标和 under-min-isr-partitions
选项来监控它们。
使用 Cruise Control 自动监控和重新平衡 Kafka 集群的任务,以确保分区负载均匀分布。如需更多信息,请参阅 第 15 章 使用 Cruise Control 进行集群重新平衡。
21.4.2. 识别 Kafka 集群中的性能问题 复制链接链接已复制到粘贴板!
集群指标中的激增可能代表一个代理问题,这通常与存储设备缓慢或故障的其他进程中的计算 restraint 相关。如果操作系统或硬件级别没有问题,则 Kafka 集群的负载是不平衡,一些分区因为与同一 Kafka 主题中的其他流量相比,有些分区接收分散流量。
要预测 Kafka 集群中的性能问题,监控 RequestHandlerAvgIdlePercent
指标非常有用。RequestHandlerAvgIdlePercent
提供有关集群行为的良好总体指示器。此指标的值介于 0 到 1 之间。下面的值 0.7 表示线程在时间忙碌的 30%,性能开始降级。如果值低于 50%,则可能会出现问题,特别是在集群需要扩展或重新平衡时。在 30% 时,集群很少可用。
另一个有用的指标是 kafka.network:type=Processor,name=IdlePercent
,您可以使用它来监控 Kafka 集群中网络处理器闲置的扩展(作为百分比)。指标有助于识别处理器是否已超过或未被充分利用。
为确保最佳性能,请将 num.io.threads
属性等于系统中处理器数量,包括超线程处理器。如果集群是均衡的,但单个客户端更改了其请求模式,并导致问题,减少集群的负载或增加代理数量。
务必要注意,在单个代理上的单个磁盘故障可能会严重影响整个集群的性能。由于生成者客户端连接到所有导致主题的分区的代理,并且这些分区在整个集群中平均分布,因此执行代理会减慢生成请求的速度,并导致生成者中的压力降低到所有代理。RAID (冗余磁盘阵列)存储配置将多个物理磁盘驱动器合并到一个逻辑单元中有助于防止这个问题。
以下是检查 Kafka 集群性能的一些指标:
检查 Kafka 集群性能的指标
- 1
- Kafka 代理线程池中的请求处理器线程的平均空闲百分比。
OneMinuteRate
和FifteenMinuteRate
属性分别显示最后一分钟和十五分钟的请求率。 - 2
- 在 Kafka 代理的特定网络处理器中创建新连接的速率。
listener
属性引用侦听器的名称,networkProcessor
属性则引用网络处理器的 ID。connection-creation-rate
属性显示每秒连接创建的速度。 - 3
- 请求队列的当前大小。
- 4
- 响应队列的当前大小。
- 5
- 指定网络处理器闲置的时间百分比。
networkProcessor
指定要监控的网络处理器的 ID。 - 6
- Kafka 服务器从磁盘读取的字节数。
- 7
- Kafka 服务器写入磁盘的字节数。
21.4.3. 识别 Kafka 控制器中的性能问题 复制链接链接已复制到粘贴板!
Kafka 控制器负责管理集群的整体状态,如代理注册、分区重新分配和主题管理。Kafka 集群中控制器的问题很难诊断,通常属于 Kafka 本身中的错误类别。当代理看起来正常或主题创建没有正确发生时,控制器问题可能会作为代理元数据没有同步、离线副本。
没有多种方法来监控控制器,但您可以监控活跃的控制器计数和控制器队列大小。如果出现问题,监控这些指标会给出一个高级别的指示器。虽然队列大小中的激增是预期的,但如果这个值持续增加,或者保持稳定值且没有丢弃,但它表示控制器可能会卡住。如果您遇到这个问题,您可以将控制器移到不同的代理中,这需要关闭当前控制器的代理。
以下是检查 Kafka 控制器性能的一些指标:
检查 Kafka 控制器性能的指标
kafka.controller:type=KafkaController,name=ActiveControllerCount kafka.controller:type=KafkaController,name=OfflinePartitionsCount kafka.controller:type=ControllerEventManager,name=EventQueueSize
kafka.controller:type=KafkaController,name=ActiveControllerCount
kafka.controller:type=KafkaController,name=OfflinePartitionsCount
kafka.controller:type=ControllerEventManager,name=EventQueueSize
21.4.4. 识别请求的问题 复制链接链接已复制到粘贴板!
您可以使用 RequestHandlerAvgIdlePercent
指标来确定请求是否慢。另外,请求指标可以识别哪些特定请求遇到延迟和其他问题。
要有效地监控 Kafka 请求,收集两个关键指标至关重要: count 和 99th percentile 延迟(也称为 tail 延迟)。
count 指标表示在特定时间间隔内处理的请求数。它可让您了解 Kafka 集群处理的请求卷,并帮助识别流量中的 spikes 或丢弃。
99th percentile 延迟测量请求延迟,这是处理请求的时间。它代表了处理 99% 请求的持续时间。但是,它不会提供有关剩余 1% 请求的确切持续时间的信息。换句话说,99th percentile 的延迟指标告知您在一定时间内处理 99% 的请求,剩余的 1% 可能需要更长时间,但这种剩余 1% 的精确持续时间未知。99%ile 的选择主要侧重于大多数请求,并排除可以偏移结果的排除者。
此指标在识别与大多数请求相关的性能问题和瓶颈时特别有用,但不给出少量请求所遇到的最大延迟的完整列表。
通过收集和分析 count 和 99th percentile 延迟指标,您可以了解 Kafka 集群的整体性能和健康状况,以及正在处理请求的延迟。
以下是检查 Kafka 请求性能的一些指标:
检查请求性能的指标
- 1
- 请求类型以中断请求指标。
- 2
- Kafka 代理每秒处理的速率。
- 3
- 请求在处理代理请求队列前等待的时间(以毫秒为单位)。
- 4
- 请求完成的总时间(以毫秒为单位),从代理接收到响应回客户端的时间。
- 5
- 请求在本地机器上处理由代理处理的时间(以毫秒为单位)。
- 6
- 请求被集群中的其他代理处理的时间(以毫秒为单位)。
- 7
- 请求被代理节流的时间(毫秒)。当代理决定客户端快速发送太多请求时,会进行节流,需要减慢。
- 8
- 在向客户端发送前,响应在代理的响应队列中等待的时间(以毫秒为单位)。
- 9
- 在代理生成响应后,响应需要发送到客户端的时间(以毫秒为单位)。
- 10
- 对于所有请求指标,
Count
和99thPercentile
属性显示已处理的请求总数,以及最慢的 1% 请求完成的时间。
21.4.5. 使用指标检查客户端的性能 复制链接链接已复制到粘贴板!
通过分析客户端指标,您可以监控连接到代理的 Kafka 客户端(producers 和 consumers)的性能。这有助于识别代理日志中突出显示的问题,如用户经常启动其消费者组、高请求故障率或频繁断开连接。
以下是检查 Kafka 客户端性能的一些指标:
检查客户端请求性能的指标
21.4.6. 使用指标检查主题和分区的性能 复制链接链接已复制到粘贴板!
主题和分区的指标有助于诊断 Kafka 集群中的问题。当无法收集客户端指标时,您还可以使用它们调试特定客户端的问题。
以下是检查特定主题和分区性能的一些指标:
检查主题和分区性能的指标