Kafka 客户机度量入门

通过 Kafka，监视通常涉及与主题，分区，代理和使用者组相关的各种度量。标准 Kafka 度量值包括有关吞吐量，等待时间，复制和磁盘使用情况的信息。请参阅 Kafka 文档和相关监视工具，以了解可用于 Kafka 版本的特定度量以及如何有效解释这些度量。

为什么监视 Kafka 客户机很重要?

监视 Event Streams 实例对于确保数据管道的最佳功能和总体运行状况至关重要。监视 Kafka 客户机有助于识别应用程序故障的早期迹象，例如资源使用率高，使用者滞后和瓶颈。及早识别这些警告信号，有助于主动应对潜在问题，最大程度减少宕机时间，防止业务运营受到任何干扰。

Kafka 客户机 (生产者和使用者) 具有自己的一组度量值，用于监视其性能和运行状况。此外，Event Streams 服务支持服务器生成的一组丰富的度量。有关更多信息，请参阅使用 IBM Cloud Monitoring 监视 Event Streams 服务度量。

要监视的客户机度量

保险销售人指标

生产商指标
指标	描述
记录错误率	此度量值用于度量每秒发送的导致错误的平均记录数。高 `record-error-rate` 或 `record-error-rate` 的增加可能指示数据丢失或未按预期处理数据。所有这些影响都可能损害您正在 Kafka中处理和存储的数据的完整性。监视此度量值有助于确保生产者发送的数据准确可靠地记录在 Kafka 主题中。
请求等待时间平均值	这是每个生成请求的平均等待时间 (以毫秒为单位)。等待时间增加会影响性能，并可能发出问题信号。测量 `request-latency-avg` 度量可以帮助确定实例中的瓶颈。对于许多应用程序而言，低延迟对于确保高质量用户体验至关重要，`request-latency-avg` 中的峰值可能指示您已达到所供应实例的限制。您可以通过更改保险销售人设置 (例如，对计划进行批处理或缩放以优化性能) 来解决此问题。
字节速率	每秒为主题发送的平均字节数是吞吐量的度量。如果定期流式采集数据，那么吞吐量下降可能指示 Kafka 实例中存在异常。 Event Streams Enterprise 套餐从每秒 150 MB 的入口和出口之间的一对一分割开始，了解您用于有效容量规划的使用量非常重要。请勿超过最大吞吐量的三分之二，以考虑操作的可能影响，例如内部更新或故障方式 (例如，失去可用性区域)。

使用者度量

消费者指标
指标	描述
fetch-rate fetch-size-avg	每秒访存请求数 (`fetch-rate`) 和每个请求访存的平均字节数 (`fetch-size-avg`) 是 Kafka 使用者执行情况的关键指标。高 `fetch-rate` 可能发出低效率信号，尤其是在少量消息上，因为这意味着数据不足，或者可能每次都未收到任何数据。 `fetch-rate` 和 `fetch-size-avg` 受三个设置影响: `fetch.min.bytes`，`fetch.max.bytes` 和 `fetch.max.wait.ms`。调整这些设置以实现期望的总体等待时间，同时最大限度地减少访存请求数以及代理程序 CPU 上可能存在的负载。监视和优化这两个度量可确保您高效地处理当前和未来工作负载的数据。
落实等待时间平均值	此度量值度量正在发送的已落实记录与正在接收的落实响应之间的平均时间。与作为生产者度量的 `request-latency-avg` 类似，稳定的 `commit-latency-avg` 表示您的偏移量落实及时发生。高落实等待时间可能指示使用者中存在阻止其快速落实偏移量的问题，这将直接影响数据处理的可靠性。如果使用者必须从先前未落实的偏移量重新启动和重新处理消息，那么可能会导致重复处理消息。高落实等待时间还意味着在管理操作中花费的时间超过实际消息处理时间。此问题可能导致等待处理的消息积压，尤其是在大容量环境中。
字节消耗率	这是使用者访存度量值，用于度量每秒使用的平均字节数。与作为生产者度量的 `byte-rate` 类似，这应该是一个稳定的预期度量。 `bytes-consumed-rate` 的预期趋势突然更改可能表示应用程序存在问题。低速率可能是数据访存或过度供应资源的效率信号。较高的速率可能会使使用者的处理能力不堪重负，因此需要进行缩放，创建更多使用者以平衡负载，或者更改使用者配置 (例如，访存大小)。
每小时重新平衡率	每小时参与的组重新平衡数。每当有新使用者时，或者当使用者离开组并导致处理延迟时，都会发生重新平衡。发生此情况的原因是重新分配了分区，这使 Kafka 使用者在每小时有大量重新平衡时效率较低。由于配置错误导致消费者行为不稳定，可能导致每小时重新平衡率较高。这种重新平衡操作可能会导致等待时间增加，并可能导致应用程序崩溃。通过跟踪低而稳定的 `rebalance-rate-per-hour` 来确保使用者组稳定。