本文档介绍了如何监控 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, broker_index, topic_id) ( max_over_time( { "managedkafka.googleapis.com/consumer_lag", monitored_resource="managedkafka.googleapis.com/TopicPartition" }[${__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配置。检查客户端的身份验证、网络和流量控制配置。
如果集群中所有主题或分区都出现过多的延迟,可能表明集群过载,应进行扩容。
如果某个代理中所有主题或分区的延迟时间过长,可能表明该代理已过载。尝试改进密钥分发或将分区重新分配给不同的代理。