监控 Kafka 客户端应用

本文档介绍了如何监控 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 配置。

  • 检查客户端配置中的身份验证、网络和流控制。

  • 集群中所有主题或分区中的延迟时间过长可能表示集群过载，应进行扩容。

  • 代理中所有主题或分区中的延迟时间过长可能表示代理过载。尝试改进键分布或 将分区重新分配 给不同的代理。

后续步骤