本文档介绍了如何监控在 Managed Service for Apache Kafka 集群中生成或使用数据的客户端的运行状况。
作为整体可靠性策略的一部分,监控客户端应用非常重要。吞吐量、错误率和消费者延迟时间等指标可以告诉您客户端应用是否遇到可靠性问题。问题可能是由客户端配置、键在分区之间的分布不均匀或仅影响特定分区的集群问题引起的。
服务器端指标
虽然直接监控客户端行为很有用,但服务器端指标不需要任何额外的插桩,并且可以帮助您检测影响可靠性的客户端问题。
服务器端指标对于检测代理之间的负载不平衡(热代理)以及正常操作中的偏差(例如延迟时间峰值)特别有用。
吞吐量
监控以下吞吐量指标,并将其与预期吞吐量进行比较:
- 消息速率(按代理和按主题)。
- 字节速率,按代理和主题。
- 请求速率。配置不当的客户端可能会以较高的速率向代理发送大量小型请求(每个请求 0-1000 字节),从而降低吞吐量。
- 请求延迟时间。生产者请求延迟时间激增可能表示负载不均衡或客户端配置存在问题。
Kafka 提供每个主题和集群的吞吐量指标。在针对所有主题进行汇总时,这些指标的值并不总是相同。使用汇总指标进行高级监控和提醒,并在排查吞吐量问题时查看每个主题的指标。将所有问题隔离到特定代理。
请求错误率
topic_error_count 指标用于跟踪服务器端失败的提取和生成请求的数量。不过,某些类型的错误不会反映在此指标中。例如:
授权设置配置不当可能会导致客户端无法向主题生成消息,而此指标中不会显示错误。
集群故障可能会导致代理根本无法响应请求。
因此,您还应监控客户端错误,包括请求超时错误。
消费者延迟
消费者延迟时间用于衡量消费者客户端与特定偏移量之间的差距。按主题、分区和代理汇总此指标有助于确定延迟是否由特定代理或分区引起。
考虑根据对工作负载至关重要的主题子集的最大延迟时间创建提醒。
自定义信息中心查询
我们建议您创建自定义信息中心和提醒来监控这些信号。下表显示了可用于监控客户端运行状况的 Prometheus 查询语言 (PromQL) 查询。
| 信号 | PromQL 查询 |
|---|---|
| 吞吐量:每个代理的消息速率 | sum by (resource_container, location, cluster_id, broker_index) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 吞吐量:每个代理每个主题的消息速率(针对最大的 5 个主题) | topk(5, sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) ) |
| 吞吐量:每个主题和代理的带宽 | sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/byte_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 请求速率 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/request_count", monitored_resource="managedkafka.googleapis.com/Cluster", "request"="Produce" }[${__interval}] ) ) |
| 请求速率,集群总计 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/topic_request_count", monitored_resource="managedkafka.googleapis.com/Topic", "request"="Produce" }[${__interval}] ) ) |
| 请求延迟时间 | sum by (resource_container, location, cluster_id, broker_index, request) ( avg_over_time( { "managedkafka.googleapis.com/request_latencies", monitored_resource="managedkafka.googleapis.com/Cluster", "percentile"="95", "request"="Produce" }[${__interval}] ) ) |
| 请求错误计数 | sum by (resource_container, location, cluster_id, broker_index, request) ( rate( { "managedkafka.googleapis.com/topic_error_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 消费者延迟:按偏移延迟时间排名前 5 的分区 | topk(5, max by (resource_container, location, cluster_id, topic_id, partition_index) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
| 消费者延迟:偏移延迟最高的 5 个消费者群组 | topk(5, max by (resource_container, location, cluster_id, consumer_group_id) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
客户端指标
有时,客户端问题不会显示在服务器指标中。例如:
如果身份验证或网络配置不正确,消息可能会在客户端的内部队列中累积。当请求超时时,消息会重新加入队列并重试。
如果流控制配置不正确,客户端生成的消息数量可能会超过分配的线程数可以发送的消息数量。虽然吞吐量可能保持一致,但越来越多的积压请求在发送之前就已过期。
如果您的客户端在 Compute Engine、Google Kubernetes Engine 或 Cloud Run 上运行,则可以使用 Cloud Monitoring 中的基于日志的指标来检测日志中的高错误率。不过,除非您配置更高的日志级别,否则某些 Kafka 客户端会隐藏导致长时间重试的异常。因此,您还应监控请求延迟时间是否增加。
Java 客户端通过 Java Management Extensions (JMX) 公开许多指标。如需了解详情,请参阅 Apache Kafka 文档中的监控。如果可能,请优先检测客户端以报告以下指标:
- 请求错误率 (
kafka.producer:type=producer-metrics,client-id="{client-id}") - 请求平均延迟时间 (
kafka.producer:type=producer-metrics,client-id="{client-id}")
如果可能,请将这些指标发送到监控解决方案。如果您可以连接到运行客户端实例的机器上的 JMX 端口,则还可以以交互方式读取这些指标。
缓解措施
如果您在客户端应用中发现问题,请考虑采取以下缓解措施:
查找代理之间的负载不均衡(热代理)。确保在集群中启用了自动重新平衡。
如果请求速率似乎异常高,请检查客户端是否发送了大量小型请求。检查提供方上的
max.request.size和batch.size配置。检查客户端配置,包括身份验证、网络和流量控制。
集群中所有主题或分区的延迟时间过长可能表示集群过载,应进行扩容。
如果代理中的所有主题或分区都存在过度延迟,则可能表示代理过载。请尝试改进密钥分布或将分区重新分配给不同的代理。