1、系统指标

类型

java.lang:type=OperatingSystem

指标项

代码示例

public class MBeanOSInfo {
    private long openFileDescriptorCount;
    private long maxFileDescriptorCount;
    private long freePhysicalMemorySize;
    private double processCpuLoad;
    private double systemCpuLoad;
    private double systemLoadAverage;
}

  public MBeanOSInfo operatingSystem() throws Exception {
      String uri = "10.0.1.115:9999";
      String mbean = "java.lang:type=OperatingSystem";
      MBeanOSInfo mBeanOSInfo = new MBeanOSInfo();
      MBeanServerConnection mbeanSvrConn = MBeanConnector.getJmxConnection(uri);
      long freePhysicalMemorySize = (Long) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.FREE_PHYSICAL_MEMORY_SIZE);
      long maxFileDescriptorCount = (Long) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.MAX_FILE_DESCRIPTOR_COUNT);
      long openFileDescriptorCount = (Long) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.OPEN_FILE_DESCRIPTOR_COUNT);
      double processCpuLoad = (Double) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.PROCESS_CPU_LOAD);
      double systemCpuLoad = (Double) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.SYSTEM_CPU_LOAD);
      double systemLoadAverage = (Double) mbeanSvrConn.getAttribute(new ObjectName(mbean), MetricsConstants.OSBean.SYSTEM_LOAD_AVERAGE);
      mBeanOSInfo.setFreePhysicalMemorySize(freePhysicalMemorySize);
      mBeanOSInfo.setMaxFileDescriptorCount(maxFileDescriptorCount);
      mBeanOSInfo.setOpenFileDescriptorCount(openFileDescriptorCount);
      mBeanOSInfo.setProcessCpuLoad(processCpuLoad);
      mBeanOSInfo.setSystemCpuLoad(systemCpuLoad);
      mBeanOSInfo.setSystemLoadAverage(systemLoadAverage);
      return mBeanOSInfo;
  }

mBeanOSInfo内容如下：

{
    "freePhysicalMemorySize": 148860928,
    "maxFileDescriptorCount": 655350,
    "openFileDescriptorCount": 2628,
    "processCpuLoad": 0.09459459459459459,
    "systemCpuLoad": 0.1205400192864031,
    "systemLoadAverage": 0.92
}

监控图表

2、线程指标

类型

java.lang:type=Threading

指标项

监控图表

3、GC指标

类型

java.lang:type=GarbageCollector

指标项

监控图表

比如：java.lang:type=GarbageCollector,name=G1 Young Generation

4、JVM指标

• 通过MemoryMXBean，可以获取堆内存和非堆内存的使用情况。
• 通过MemoryPoolMXBean，可以获取有关内存池的使用情况、峰值、类型等信息。

监控图表

比如：堆内存使用情况（memoryMXBean.getHeapMemoryUsage）：

5、Topic指标

提供了关于 Kafka 主题（Topic）级别的度量指标。这些指标对于监控 Kafka 集群的性能、识别瓶颈以及优化生产者和消费者的行为非常有用。

类型

kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>

指标项

5.1、Topic消息入站速率（Byte）

描述

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=<your-topic-name>

表示每秒从生产者发送到该主题所有分区的字节数。

作用

这个指标对于监控生产者写入Kafka的速率非常有用。如果值持续增长，说明生产者正在以较高的速率写入数据。如果这个值突然下降或变为0，可能表示生产者写入速率降低，或者生产者遇到了问题，如网络延迟、生产者客户端的问题等。

为了充分利用这个指标，你可以：

1. 历史趋势分析：监控BytesInPerSec的历史数据，分析它的趋势，以便了解生产者写入速率的变化。
2. 设置告警：当低于或高于某个阈值时触发告警，以便及时响应可能的生产者写入问题。
3. 与其他指标关联分析：将BytesInPerSec与其他相关指标（如BytesOutPerSec、RequestQueueTimeMs、ProduceRequestsPerSec等）一起分析，以便更全面地了解Kafka集群的性能状态。

示例

下面是一个示例的返回内容，展示了BytesInPerSec针对特定主题的查询结果：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,name=BytesInPerSec",
  "value": 123456
}

字段说明：

• name：指明了Kafka服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、特定的主题（topic=<your-topic-name>）和指标名称（name=BytesInPerSec）。
• value：每秒从生产者发送到该主题的字节数。在这个例子中，每秒有123456字节被写入该主题。

图表

在 Kafka 的监控指标中，MeanRate, OneMinuteRate, FiveMinuteRate, 和 FifteenMinuteRate 是用来表示不同时间窗口内的平均速率的。这些指标帮助用户了解不同时间范围内数据的变化趋势和负载情况。

MeanRate:

MeanRate 是自 JVM 启动以来的平均速率。这个指标通常用于了解系统自启动以来的长期平均行为。因为是从 JVM 启动开始计算的，所以这个值可能会受到系统长时间运行的影响，不能很好地反映近期的变化。

OneMinuteRate:

OneMinuteRate 是过去一分钟内的平均速率。这个指标对于捕捉短期、快速的变化非常有用，如突发流量或性能抖动。它通常用于检测系统的即时性能表现。

FiveMinuteRate:

FiveMinuteRate 是过去五分钟内的平均速率。这个指标比 OneMinuteRate 更平滑，因为它考虑了更长的时间范围。它适用于检测中等时间尺度内的行为变化或趋势。

FifteenMinuteRate:

FifteenMinuteRate 是过去十五分钟内的平均速率。这个指标是最平滑的，因为它考虑了最长的时间范围。它适用于检测长时间尺度内的系统行为或长期趋势。

这些速率指标通常用于监控系统的吞吐量、延迟、错误率等，帮助用户了解系统在不同时间范围内的表现。例如，如果 OneMinuteRate 突然上升而 FifteenMinuteRate 保持稳定，那么可能是一个短暂的流量高峰或临时性能问题。如果 FiveMinuteRate 和 FifteenMinuteRate 都持续上升，那么可能是一个更持久的性能问题或负载增加。

5.2、Topic消息出站速率（Byte）

描述

kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=<your-topic-name>

表示每秒从该主题的所有分区发送到所有消费者的字节数。

作用

这是衡量主题生产者到消费者之间数据传输速率的一个重要指标。如果 BytesOutPerSec 的值持续增长，说明消费者正在以较高的速率从该主题读取数据。如果这个值突然下降或变为0，可能表示消费者读取速率降低，或者消费者遇到了问题，如网络延迟、消费者客户端的问题等。

1. 设置告警：当BytesOutPerSec 的值低于或高于某个阈值时触发告警，以便及时响应可能的消费者读取问题。
2. 历史趋势分析：监控BytesOutPerSec 的历史数据，分析它的趋势，以便了解消费者读取速率的变化。
3. 与其他指标关联分析：将BytesOutPerSec与其他相关指标（如BytesInPerSec、RequestQueueTimeMs、ConsumerFetchRequestsPerSec 等）一起分析，以便更全面地了解 Kafka 集群的性能状态。
4. 优化消费者配置：如果BytesOutPerSec 的值较低，可能需要调整消费者的配置，如增加消费者的并行度、优化消费者的拉取策略等，以提高数据的读取速率。

示例

下面是一个示例的返回内容，展示了 BytesOutPerSec 针对特定主题的查询结果：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,name=BytesOutPerSec",
  "value": 123456
}

在这个示例中：

• name ：指明了 Kafka 服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、特定的主题（topic=<your-topic-name>）和指标名称（name=BytesOutPerSec）。
• value：每秒从该主题发送到消费者的字节数。在这个例子中，每秒有 123,456字节从该主题发送到消费者。

图表

5.3、Topic消息入站速率（message）

描述

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec,topic=<your-topic-name>

表示每秒写入到特定主题的消息数。这个指标可以帮助你了解主题的入站消息速率，从而评估 Kafka 集群的吞吐量以及生产者的发送速率。

作用

如果 MessagesInPerSec 的值持续上升，这通常意味着生产者正在以更高的速率向主题发送消息。如果这个值超过了 Kafka Broker 的处理能力，可能会导致性能问题或消息堆积。

为了保持 Kafka 集群的健康运行，你可能需要：

1. 监控生产者发送速率：确保生产者的发送速率与集群的处理能力相匹配。
2. 调整 Broker 配置：如果集群的处理能力是瓶颈，考虑增加 Broker 数量、提高磁盘 I/O 性能或优化网络设置。
3. 监控消费者处理速率：确保消费者能够及时消费消息，避免消息堆积。
4. 考虑分区策略：如果某个主题的消息量特别大，可能需要重新考虑分区的数量和设计，以更好地平衡负载。

示例

{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,name=MessagesInPerSec",
  "value": 100.0
}

在这个示例中：

• name 字段包含了 JMX 对象的名称，指明了这是 Kafka Broker 的指标（kafka.server），类型是 Broker 主题指标（type=BrokerTopicMetrics），并且包含了特定的主题名称（topic=<your-topic-name>）和分区 ID（partition=<your-partition-id>），以及指标名称（name=MessagesInPerSec）。
• value字段是MessagesInPerSec 的值，表示特定主题和分区的每秒入站消息数，在这个例子中是 100.0 条/秒。

图表

5.4、Topic请求被拒速率

描述

kafka.server:type=BrokerTopicMetrics,name=BytesRejectedPerSec,topic=<your-topic-name>

表示针对特定主题的生产者每秒被 Broker 拒绝的字节数。

作用

这个指标可以帮助你诊断特定主题是否遇到了生产者的发送限制。如果 BytesRejectedPerSec 的值持续上升，那么可能需要检查以下几个方面：

1. 消息大小：确保发送到该主题的消息大小没有超过 Broker 配置的最大允许值。
2. 生产者配置：检查生产者的配置，确保它们的发送速率和批次大小适合 Broker 的处理能力。
3. Broker 资源：确保 Broker 有足够的磁盘空间和网络资源来处理生产者的请求。
4. 主题和分区配置：检查主题和分区的配置，确保它们没有设置不当的限制，如分区数量过少或分区大小限制过低。

示例

下面是一个示例的返回结果，展示了 BrokerTopicMetrics 中 BytesRejectedPerSec 指标的值：

{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,name=BytesRejectedPerSec",
  "value": 1024.0
}

在这个示例中：

• name ：指明了这是 Kafka Broker 的指标（kafka.server），类型是 Broker 主题指标（type=BrokerTopicMetrics），并且包含了主题名称（topic=<your-topic-name>）、分区 ID（partition=<your-partition-id>）和指标名称（name=BytesRejectedPerSec）。
• value ：表示针对特定主题和分区的生产者每秒被拒绝的字节数，在这个例子中是 1024.0 字节/秒。

图表

5.5、Topic失败拉去请求速率

描述

kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec,topic=<your-topic-name>

Broker 每秒接收到的失败的 fetch 请求的数量。Fetch 请求是 Kafka 消费者用来从 Broker 拉取消息的一部分。当消费者尝试拉取消息但出于某种原因失败时，这个指标就会增加。

作用

如果 FailedFetchRequestsPerSec 的值持续上升或保持在较高水平，这通常意味着消费者拉取消息时存在问题。可能的原因包括：

• 消费者和 Broker 之间的网络连接问题。
• 消费者端的 fetch 请求配置不当（例如，fetch 超时时间设置太短）。
• Broker 端的问题，如磁盘故障、网络问题或处理延迟。
• 主题或分区的数据量过大，导致消费者在拉取时超时。

要解决这个问题，你可能需要采取以下步骤：

1. 检查消费者和 Broker 的网络连接：确保消费者和 Broker 之间的网络连接稳定可靠。
2. 调整消费者配置：考虑增加 fetch 超时时间或调整其他相关配置，以适应当前的负载和延迟。
3. 监控 Broker 性能：检查 Broker 的磁盘、网络和 CPU 使用情况，确保它们没有成为瓶颈。
4. 优化主题和分区设计：如果主题或分区过大，考虑重新设计主题和分区策略，以减少消费者的拉取延迟。

示例

以下是 BrokerTopicMetrics,name=FailedFetchRequestsPerSec 指标的一个返回结果示例：

{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,name=FailedFetchRequestsPerSec",
  "value": 0.5
}

在这个示例中：

• name ：指明了这是 Kafka Broker 的指标（kafka.server），类型是 Broker 主题指标（type=BrokerTopicMetrics），并且包含了特定的主题名称（topic=<your-topic-name>）和分区 ID（partition=<your-partition-id>），以及指标名称（name=FailedFetchRequestsPerSec）。
• value ：表示特定主题和分区的 Broker 每秒接收到的失败的 fetch 请求数，在这个例子中是 0.5，即每两秒钟有一个 fetch 请求失败。

图表

5.6、Topic发送请求失败速率

描述

kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec,topic=<your-topic-name>

Broker 每秒接收到的失败的 produce 请求的数量。Produce 请求是 Kafka 生产者用来向 Broker 发送消息的部分。当生产者尝试发送消息到 Broker 但出于某种原因失败时，这个指标就会增加。

作用

如果 FailedProduceRequestsPerSec 的值持续上升或保持在较高水平，这通常意味着生产者发送消息时遇到了问题。可能的原因包括：

• 生产者与 Broker 之间的网络连接问题。
• 生产者端的配置问题，例如生产者尝试发送的消息大小超过了 Broker 允许的最大值。
• Broker 端的问题，如磁盘故障、网络问题或处理延迟。
• 主题或分区的配置问题，如分区数量设置不当，导致某些分区不可用。

要解决这个问题，你可能需要采取以下步骤：

1. 检查生产者与 Broker 的网络连接：确保生产者和 Broker 之间的网络连接稳定可靠。
2. 调整生产者配置：考虑增加重试次数、调整批处理大小或修改其他相关配置，以适应当前的负载和延迟。
3. 监控 Broker 性能：检查 Broker 的磁盘、网络和 CPU 使用情况，确保它们没有成为瓶颈。
4. 优化主题和分区设计：如果主题或分区配置不当，考虑重新设计主题和分区策略，以提高生产者的发送性能。

示例

下面是 BrokerTopicMetrics,name=FailedProduceRequestsPerSec 的一个返回结果示例：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,name=FailedProduceRequestsPerSec",
  "value": 0.1
}

在这个示例中：

• name 字段包含了 JMX 对象的名称，指明了这是 Kafka Broker 的指标（kafka.server），类型是 Broker 主题指标（type=BrokerTopicMetrics），并且包含了特定的主题名称（topic=<your-topic-name>）和分区 ID（partition=<your-partition-id>），以及指标名称（name=FailedProduceRequestsPerSec）。
• value字段是FailedProduceRequestsPerSec 的值，表示特定主题和分区的 Broker 每秒接收到的失败的 produce 请求数，在这个例子中是 0.1，即每十秒钟有一个 produce 请求失败。

图表

6、Broker指标

6.1、日志刷新

描述

kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs

用于度量日志刷新的速率和所花费的时间。这个指标对于理解 Kafka Broker 的磁盘 I/O 性能、磁盘同步策略以及整体性能至关重要。

LogFlushRateAndTimeMs 通常包含两个子指标：

LogFlushRate:

这个指标表示每秒触发的日志刷新次数。日志刷新是将内存中的消息数据写入到磁盘的过程，以确保数据的持久性。LogFlushRate 的值反映了 Broker 刷新日志的频率。

LogFlushTimeMs:

这个指标表示每次日志刷新的平均耗时（以毫秒为单位）。这个值反映了 Broker 在执行磁盘写入操作时的性能。较高的 LogFlushTimeMs 值可能意味着磁盘写入性能瓶颈或者其他与磁盘 I/O 相关的问题。

如果 LogFlushRate 的值非常高，这可能意味着 Broker 频繁地触发日志刷新。这可能是由于日志刷新的间隔设置得太小，或者由于 Broker 试图尽快将消息写入磁盘以确保数据的持久性。

如果 LogFlushRate 的值非常低，这可能表明 Broker 刷新日志的频率较低。这可能是由于日志刷新的间隔设置得太大，或者由于 Broker 试图通过减少磁盘写入来提高性能。

如果 LogFlushTimeMs 的值很高，这可能意味着磁盘写入操作非常耗时。这可能是由于磁盘性能不佳、磁盘 I/O 竞争激烈或者 Broker 的日志刷新策略配置不当。

如果 LogFlushTimeMs 的值持续上升或保持在较高水平，可能需要进一步检查磁盘健康状况、磁盘 I/O 性能以及 Broker 的配置设置。

了解 LogFlushRate 和 LogFlushTimeMs 的关系可以帮助你诊断性能问题。例如，如果 LogFlushRate 很高而 LogFlushTimeMs 也很高，那么可能是磁盘写入性能瓶颈导致的。如果 LogFlushRate 很低而 LogFlushTimeMs 也很高，那么可能是 Broker 的日志刷新策略配置不当。

示例

{
  "name": "kafka.server:type=BrokerTopicMetrics,name=LogFlushRateAndTimeMs,topic=your-topic-name",
  "value": {
    "count": 1234,
    "meanRate": 5.67,
    "oneMinuteRate": 5.55,
    "fiveMinuteRate": 5.44,
    "fifteenMinuteRate": 5.33,
    "mean": 123.45,
    "stdDev": 10.23,
    "min": 100.0,
    "max": 200.0
  }
}

这里的 value 部分包含了多个子字段，每个子字段的含义如下：

• count: 刷新事件的总数。这表示在统计期间发生了多少次日志刷新。
• meanRate: 平均每秒的刷新速率。它表示在统计期间每秒平均发生的日志刷新次数。
• oneMinuteRate: 最近一分钟的平均刷新速率。
• fiveMinuteRate: 最近五分钟的平均刷新速率。
• fifteenMinuteRate: 最近十五分钟的平均刷新速率。
• mean: 每次刷新的平均耗时（以毫秒为单位）。
• stdDev: 每次刷新耗时的标准差。它表示刷新耗时相对于平均值的离散程度。
• min: 刷新耗时的最小值（以毫秒为单位）。
• max: 刷新耗时的最大值（以毫秒为单位）。

请注意，topic=your-topic-name 部分中的 your-topic-name 会根据你实际监控的主题名称而有所不同。如果你没有指定具体的主题，那么该指标可能会以 Broker 的全局视角返回。

图表

6.2、同步失效的副本数

描述

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

用于监控 Kafka 集群中复制因子（replication factor）未满足的分区数量。

{
  "value": 10
}

在这个返回内容中：

• value 字段包含了当前未满足复制因子的分区数量。这个数值应该接近于零，表示所有分区都已经按照配置的复制因子进行了复制。如果数值大于零，那么表示有一些分区没有达到其配置的复制因子，这可能会影响到数据的可用性和容错性。

要正确解读这个指标，你需要了解你的 Kafka 集群的复制因子配置。每个 Kafka 主题（topic）都可以配置一个复制因子，它决定了每个分区在集群中应该有多少个副本。如果一个分区的副本数量少于其配置的复制因子，那么这个分区就会被认为是“欠复制”的。

欠复制的分区可能会导致以下问题：

1. 数据不可用性：如果欠复制的分区所在的 broker 宕机，那么这些数据可能会丢失，导致分区不可用。
2. 集群不均衡：如果一些分区欠复制，而其他分区则正常，那么集群的负载可能会不均衡，影响性能。
3. 延迟恢复：如果分区欠复制，那么在发生故障时需要更长的时间来恢复数据。

6.3、Leader副本数

kafka.server:type=ReplicaManager,name=LeaderCount

6.4、Partition数量

kafka.server:type=ReplicaManager,name=PartitionCount

6.5、下线Partition数量

kafka.controller:type=KafkaController,name=OfflinePartitionsCount

6.6、Broker网络处理线程空闲率

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

用于监控 Kafka Broker 中请求处理器（Request Handler）的平均空闲百分比。这个指标可以帮助了解 Kafka Broker 在处理客户端请求时的负载情况，以及请求处理器的利用率。

RequestHandlerAvgIdlePercent 的值范围通常在 0 到 100 之间。如果值接近 0%，表示请求处理器大部分时间都在忙碌处理请求，Kafka Broker 可能正面临着高负载。如果值接近 100%，则表示请求处理器大部分时间都处于空闲状态，Kafka Broker 的负载可能较低。

这个指标对于监控 Kafka Broker 的性能和容量规划非常有用。如果 RequestHandlerAvgIdlePercent 持续处于较低水平，可能需要考虑增加 Broker 的数量或优化客户端的请求模式，以减轻单个 Broker 的负载。同时，如果这个指标持续处于较高水平，可能意味着 Kafka 集群的容量过大，或者客户端的请求量不足，可以考虑优化资源分配或调整集群规模。

6.7、Leader选举比率

kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs

用于监控主题分区领导者选举的频率以及每次选举所花费的平均时间。这个指标可以帮助你了解集群中领导者选举的健康状况以及潜在的稳定性问题。

LeaderElectionRateAndTimeMs 通常包含两个子指标：electionRate 和 avgTimeMs。

{
  "electionRate": 0.05,
  "avgTimeMs": 5000
}

在这个返回内容中：

• electionRate 字段表示领导者选举的频率，通常以每秒选举次数（elections/sec）来表示。这个值应该保持在较低水平，因为频繁的领导者选举可能意味着集群存在稳定性问题。
• avgTimeMs 字段表示每次领导者选举所花费的平均时间，单位通常是毫秒（ms）。这个值可以帮助你了解领导者选举的性能，较高的值可能表示存在网络延迟、磁盘I/O问题或其他性能瓶颈。

如果 electionRate 值较高或 avgTimeMs 值较大，可能的原因包括：

• Broker 故障：Broker 宕机或网络问题可能导致领导者选举。
• ISR 列表变化：In-Sync Replicas (ISR) 列表的变化也可能触发领导者选举。
• 磁盘故障：如果领导者的磁盘出现问题，可能会触发领导者选举。
• 配置问题：不恰当的配置，如过低的 unclean.leader.election.enable 设置。

6.8、Controller存活数量

kafka.controller:type=KafkaController,name=ActiveControllerCount

当前活跃的控制器（Controller）的数量。在 Kafka 集群中，控制器是一个特殊的 broker，它负责管理集群的元数据和分区领导者选举等任务。

value 字段包含了当前活跃的控制器数量。在正常情况下，Kafka 集群中应该只有一个活跃的控制器。

ActiveControllerCount 的值通常为 1，表示有一个控制器正在积极管理集群的状态。如果值大于 1，这可能意味着集群中存在多个控制器，这通常是不正常的状态。多个控制器可能会导致元数据的不一致和分区领导者选举的问题。

如果 ActiveControllerCount 的值异常，可能需要检查集群的状态和日志，以确定为什么有多个控制器处于活跃状态。可能的原因包括控制器崩溃后未能正确地将控制权转移给其他 broker，或者网络问题导致控制器之间的通信中断。

监控 ActiveControllerCount 可以帮助你及时发现集群中的控制器问题，并采取相应的措施来恢复集群的正常状态。

6.9、Produce请求速率

kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Produce

用于监控特定类型的请求每秒到达 Kafka Broker 的数量。当你针对 request=Produce 查询此指标时，你正在查看生产者端发送到 Kafka Broker 的 Produce 请求的速率。

Produce 请求是生产者用来向 Kafka 主题分区发送消息的请求。监控这些请求的速率可以帮助你了解生产者的吞吐量、集群的写入负载以及可能存在的性能瓶颈。

以下是 RequestsPerSec 针对 request=Produce 的一个示例返回内容：

{
  "value": 567.89
}

在这个返回内容中：

• value 字段包含了 Produce 请求的速率，以每秒的请求数（RPS, Requests Per Second）表示。

RequestsPerSec 对于 Produce 请求的返回值可以帮助你：

1. 评估生产者性能：高 RPS 值可能意味着生产者正在高效地发送消息到 Kafka 集群。
2. 监控写入负载：Produce 请求的速率反映了集群的写入负载。如果 RPS 值持续很高，可能意味着集群正在承受较高的写入压力。
3. 发现性能瓶颈：如果 RPS 值异常低，可能表明生产者或网络存在性能瓶颈，或者 Kafka Broker 的处理能力受限。
4. 调整生产者配置：通过监控此指标，你可以了解生产者的行为，并根据需要调整生产者的配置，例如批处理大小、发送缓冲区大小或重试策略。
5. 资源规划和扩展：如果你发现集群经常达到或超过其处理能力，你可能需要考虑增加更多的 Broker 或优化现有 Broker 的资源配置。

6.10、Consumer拉取速率

kafka.network:type=RequestMetrics,name=RequestsPerSec,request=FetchConsumer

用于衡量特定类型的请求每秒到达 Kafka Broker 的数量。当你指定 request=FetchConsumer 时，你正在查询消费者端的 Fetch 请求的速率，这些请求通常用于从 Kafka Broker 拉取（Fetch）消息。

Fetch 请求是 Kafka 消费者 API 的一部分，消费者使用它们来从它们订阅的主题的分区中拉取数据。Fetch 请求的速率是评估消费者端性能的一个重要指标，因为它直接反映了消费者从 Kafka 集群中获取数据的速度。

value 字段包含了 FetchConsumer 请求的速率，以每秒的请求数（RPS, Requests Per Second）表示。

FetchConsumer 请求的速率可以帮助你了解：

• 消费者端的吞吐量：高 RPS 值可能意味着消费者正在高效地拉取数据。
• 网络带宽使用：Fetch 请求通常涉及网络传输，高 RPS 值可能意味着网络带宽使用较高。
• Broker 负载：高 RPS 值也会增加 Broker 的处理负载，这可能会影响其他类型的请求处理性能。
• 性能瓶颈：如果 FetchConsumer 请求的速率远低于预期，可能表明消费者端或网络存在性能瓶颈。

6.11、Follower拉取速率

kafka.network:type=RequestMetrics,name=RequestsPerSec,request=FetchFollower

用于监控特定类型的请求每秒到达 Kafka Broker 的数量。当你查询 request=FetchFollower 时，你正在查看副本追随者（Follower replicas）的 Fetch 请求的速率。这些请求通常用于从领导者（Leader replicas）复制数据。

Fetch 请求在 Kafka 的复制机制中扮演着重要角色，它们确保了所有副本都保持与领导者相同的数据状态。RequestsPerSec 对于 FetchFollower 的值可以帮助你了解副本复制的健康状态和性能。

value 字段包含了 FetchFollower 请求的速率，以每秒的请求数（RPS, Requests Per Second）表示。

FetchFollower 请求的速率可以帮助你了解：

1. 副本复制性能：高 RPS 值可能意味着副本追随者正在高效地从领导者那里拉取数据。
2. 集群健康状况：如果 FetchFollower 请求的速率异常低，可能表明副本复制存在问题，例如网络延迟、领导者性能瓶颈或副本追随者自身的问题。
3. 资源规划和扩展：如果 FetchFollower 请求的速率持续很高，并且接近或超过 Broker 的处理能力，你可能需要考虑增加更多的 Broker 或优化现有 Broker 的资源配置，以支持更高的复制负载。
4. 监控和告警：通过监控 FetchFollower 请求的速率，你可以设置告警来及时通知你任何潜在的复制问题，从而能够迅速采取行动进行故障排除。

6.12、Produce请求耗时

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce

生产者发送的 Produce 请求所需的总时间。

Produce 请求是生产者用来将消息发送到 Kafka 主题分区的请求。TotalTimeMs 对于 request=Produce 提供了处理这些请求所需时间的汇总信息，这有助于你了解生产者的性能、集群的负载情况以及是否存在潜在的瓶颈。

以下是 TotalTimeMs 针对 request=Produce 的一个示例返回内容：

json{
  "name": "kafka.server:type=KafkaRequestHandlerPool,request=Produce,name=TotalTimeMs",
  "value": 6789
}

在这个返回内容中：

• name 字段包含了 JMX 对象的名称，指明了 Kafka 服务器的类型（kafka.server）、组件类型（type=KafkaRequestHandlerPool）、请求类型（request=Produce）和指标名称（name=TotalTimeMs）。
• value字段包含了处理Produce 请求所需的总时间，单位是毫秒。

TotalTimeMs 对于 request=Produce 的返回值可以帮助你：

1. 评估生产者性能：如果TotalTimeMs 的值较高，可能意味着生产者发送消息到 Kafka 集群的时间较长，这可能是由于网络延迟、Broker 处理延迟或其他因素造成的。
2. 监控集群负载：如果TotalTimeMs 持续增加，可能表明 Kafka 集群正在承受较高的写入负载，这可能导致延迟增加。
3. 发现瓶颈：如果TotalTimeMs 异常高，并且伴随着生产者吞吐量下降，那么可能存在生产者端或 Kafka 集群端的性能瓶颈。
4. 优化配置：通过监控 TotalTimeMs，你可以根据需要对生产者和 Kafka 集群的配置进行优化，以改善性能。

6.13、Consumer拉取耗时

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer

消费者发送的 Fetch 请求所需的总时间。

Fetch 请求是消费者用来从 Kafka Broker 获取存储在特定分区中的消息的记录。这些请求是消费者拉取模型的一部分，其中消费者主动向 Broker 发起请求以获取新的消息。

TotalTimeMs 对于 request=FetchConsumer 提供了处理这些 Fetch 请求所需时间的汇总信息，这有助于你了解消费者的性能、集群的响应能力以及是否存在潜在的延迟问题。

{
  "value": 3456
}

value 字段包含了处理 FetchConsumer 请求所需的总时间，单位是毫秒。

TotalTimeMs 对于 request=FetchConsumer 的返回值可以帮助你：

1. 评估消费者性能：如果TotalTimeMs 的值较高，可能意味着消费者拉取消息所需的时间较长，这可能是由于网络延迟、Broker 处理延迟、磁盘 I/O 问题或其他因素造成的。
2. 监控集群响应能力：高TotalTimeMs 值可能表明 Kafka 集群在响应消费者 Fetch 请求时存在延迟，这可能是由于高负载、资源争用或其他集群级问题导致的。
3. 发现潜在问题：如果TotalTimeMs 持续增加，同时消费者的吞吐量下降，那么可能存在消费者端或 Kafka 集群端的性能瓶颈或配置问题。
4. 优化配置：通过监控 TotalTimeMs，你可以根据需要对消费者和 Kafka 集群的配置进行优化，以提高拉取消息的性能。

6.14、Follower拉取耗时

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchFollower

这个指标衡量的是Follower从Leader获取数据（即 Fetch 请求）所花费的总时间。

Fetch 请求是 Kafka 复制机制中的一个重要组成部分，它允许追随者从领导者那里拉取最新的消息记录，以保持与领导者一致的数据状态。TotalTimeMs 对于 request=FetchFollower 提供了关于这种拉取操作所需时间的汇总信息。

以下是 TotalTimeMs 针对 request=FetchFollower 的一个示例返回内容：

json{
  "name": "kafka.server:type=KafkaRequestHandlerPool,request=FetchFollower,name=TotalTimeMs",
  "value": 2345
}

在这个返回内容中：

• name 字段包含了 JMX 对象的名称，指明了 Kafka 服务器的类型（kafka.server）、组件类型（type=KafkaRequestHandlerPool）、请求类型（request=FetchFollower）和指标名称（name=TotalTimeMs）。
• value 字段包含了处理 FetchFollower 请求所需的总时间，单位是毫秒。

TotalTimeMs 对于 request=FetchFollower 的返回值可以帮助你：

1. 评估复制延迟：如果TotalTimeMs 的值较高，可能意味着追随者从领导者那里拉取数据需要更长的时间，这可能会导致复制延迟。
2. 监控网络性能：高TotalTimeMs 值可能是由于网络延迟或带宽限制造成的，这可能会影响副本之间的数据同步。
3. 识别磁盘 I/O 问题：如果磁盘读写性能不佳，可能会影响 Fetch 请求的处理时间，导致TotalTimeMs 值增加。
4. 优化复制配置：通过监控TotalTimeMs，你可以根据需要调整副本的复制配置，例如增加或减少 Fetch 请求的大小，以优化数据同步的性能。
5. 设置告警和监控：你可以设置基于TotalTimeMs 的告警，当该指标超过某个阈值时，及时通知你，以便你可以迅速采取行动解决问题。

6.15、Time the follower fetch request waits in the request queue

kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=FetchFollower

用于查看与Follower（Follower replicas）的 Fetch 请求在请求队列中等待被处理的时间相关的统计信息。

Fetch 请求是 Kafka 复制机制中的一部分，允许追随者从领导者那里拉取新的消息记录以保持数据同步。RequestQueueTimeMs 衡量的是这些 Fetch 请求在被 Broker 实际处理之前，在请求队列中等待的时间长度。

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,request=FetchFollower,name=RequestQueueTimeMs",
  "value": 123
}

在这个示例中：

• name 字段包含了 JMX 对象的名称，指明了 Kafka 服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、主题名称（topic=<your-topic-name>）、分区ID（partition=<your-partition-id>）、请求类型（request=FetchFollower）和指标名称（name=RequestQueueTimeMs）。
• value 字段包含了 FetchFollower 请求在队列中等待的平均时间，单位是毫秒。

RequestQueueTimeMs 对于 request=FetchFollower 的返回值可以帮助你：

1. 评估复制延迟：如果 FetchFollower 请求在队列中等待的时间较长，这可能会导致复制延迟增加，因为追随者需要等待更长的时间才能从领导者那里获取数据。
2. 监控 Broker 负载：高RequestQueueTimeMs 值可能是 Broker 高负载的迹象，这可能是由于大量的 Fetch 请求同时到达，导致请求队列增长和处理延迟。
3. 识别性能瓶颈：如果RequestQueueTimeMs持续上升，并且与 FetchFollower 相关的其他指标（如TotalTimeMs）也表现出延迟，那么可能存在性能瓶颈，例如网络延迟、磁盘 I/O 问题或 CPU 资源不足。
4. 优化 Kafka 配置：通过监控 RequestQueueTimeMs，你可以根据需要调整 Kafka 的配置，例如增加 Broker 的处理能力、优化网络设置或调整复制策略。

6.16、Time the Consumer fetch request waits in the request queue

kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=FetchConsumer

消费者 Fetch 请求在 Broker 的请求队列中等待被处理的时间。

Fetch 请求是消费者用来从 Kafka 的分区中拉取消息的请求。当 Fetch 请求到达 Broker 时，如果 Broker 当前正在处理其他请求或者资源有限，这些 Fetch 请求可能需要等待才能在 Broker 的处理队列中被处理。

RequestQueueTimeMs 衡量的就是这种等待时间，以毫秒为单位。长时间的等待可能意味着 Broker 负载较高，或者消费者的 Fetch 请求频率过高，导致请求队列增长。

以下是一个示例的返回内容，假设使用 JMX 或类似的监控工具查询 RequestQueueTimeMs 针对 request=FetchConsumer：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,request=FetchConsumer,name=RequestQueueTimeMs",
  "value": 500
}

在这个示例中：

• name 字段包含了 JMX 对象的名称，指明了 Kafka 服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、特定的主题（topic=<your-topic-name>）、分区（partition=<your-partition-id>）、请求类型（request=FetchConsumer）和指标名称（name=RequestQueueTimeMs）。
• value字段是RequestQueueTimeMs 的值，表示 FetchConsumer 请求在队列中等待的平均时间，单位是毫秒。在这个例子中，等待时间是 500 毫秒。

高 RequestQueueTimeMs 值可能表明：

1. 消费者端问题：消费者可能正在以过高的速度发送 Fetch 请求，导致 Broker 的请求队列增长。
2. Broker 端问题：Broker 可能因为资源不足（如 CPU、内存或网络带宽）而无法快速处理请求。
3. 网络延迟：网络延迟可能导致请求在传输过程中花费更多时间。

要优化这个问题，你可以：

• 调整消费者 Fetch 配置：减少 Fetch 请求的频率或大小，以减轻 Broker 的压力。
• 监控 Broker 性能：检查 Broker 的 CPU、内存和网络使用情况，确保它们没有成为瓶颈。
• 优化 Kafka 配置：根据监控结果调整 Kafka 的配置，例如增加 Broker 的处理能力或优化网络设置。
• 设置告警：当 RequestQueueTimeMs 超过某个阈值时触发告警，以便及时响应。

6.17、Time the Produce fetch request waits in the request queue

kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=Produce

生产者发送的Produce请求在Broker的请求队列中等待被处理的时间。Produce请求是生产者用来向Kafka的分区中发送消息的请求。

当Produce请求到达Broker时，如果Broker当前正在处理其他请求或者资源有限，这些请求可能需要等待才能在Broker的处理队列中被处理。RequestQueueTimeMs衡量的就是这种等待时间，以毫秒为单位。

以下是一个示例的返回内容，假设你使用JMX或类似的监控工具查询RequestQueueTimeMs针对request=Produce：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,request=Produce,name=RequestQueueTimeMs",
  "value": 45
}

在这个示例中：

• name字段包含了JMX对象的名称，指明了Kafka服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、特定的主题（topic=<your-topic-name>）、分区（partition=<your-partition-id>）、请求类型（request=Produce）和指标名称（name=RequestQueueTimeMs）。
• value字段是RequestQueueTimeMs的值，表示Produce请求在队列中等待的平均时间，单位是毫秒。在这个例子中，等待时间是45毫秒。

高RequestQueueTimeMs值可能表明：

1. 生产者端问题：生产者可能正在以过高的速度发送消息，导致Broker的请求队列增长。
2. Broker端问题：Broker可能因为资源不足（如CPU、内存或网络带宽）而无法快速处理请求。
3. 网络延迟：网络延迟可能导致请求在传输过程中花费更多时间。
4. 磁盘I/O问题：如果Broker的磁盘性能不佳，可能导致处理请求的速度变慢。

为了优化这个问题，你可以：

• 调整生产者配置：减少生产者的发送速率，通过调整acks、batch.size、linger.ms等参数来优化生产者的性能。
• 监控Broker性能：检查Broker的CPU、内存和网络使用情况，确保它们没有成为瓶颈。
• 优化Kafka配置：根据监控结果调整Kafka的配置，例如增加Broker的处理能力或优化网络设置。
• 设置告警：当RequestQueueTimeMs超过某个阈值时触发告警，以便及时响应。

6.18、Broker I/O工作处理线程空闲率

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

处理器的平均空闲百分比。

网络处理器是 Kafka Broker 中负责处理网络请求和响应的组件。当这个值较高时，表示网络处理器在大部分时间内都是空闲的，没有处理请求，这可能是因为请求量较低，或者网络处理器的处理能力过高。

以下是一个示例的返回内容，假设你使用 JMX 或类似的监控工具查询 NetworkProcessorAvgIdlePercent：

json{
  "name": "kafka.network:type=Processor,name=NetworkProcessorAvgIdlePercent,brokerId=<your-broker-id>",
  "value": 70
}

在这个示例中：

• name 字段包含了 JMX 对象的名称，指明了 Kafka 网络处理器的类型（kafka.network）、组件类型（type=Processor）、特定的网络处理器名称（name=NetworkProcessorAvgIdlePercent）和 Broker 的 ID（brokerId=<your-broker-id>）。
• value字段是NetworkProcessorAvgIdlePercent 的值，表示网络处理器的平均空闲百分比。在这个例子中，平均空闲百分比是 70%，意味着网络处理器有 70% 的时间处于空闲状态。

高 NetworkProcessorAvgIdlePercent 值可能表明：

1. 请求量不足：Kafka Broker 接收到的请求量较低，导致网络处理器大部分时间都处于空闲状态。
2. 网络处理器能力过剩：网络处理器的配置（如线程数或处理能力）相对于实际的请求负载来说过高。
3. 性能瓶颈在其他地方：如果 Kafka 集群的其他部分（如磁盘 I/O、CPU 或内存）成为瓶颈，网络处理器可能会因为等待这些资源而处于空闲状态。

为了优化这个问题，你可以：

• 调整消费者和生产者的请求速率：如果请求量不足，可以考虑增加消费者或生产者的请求速率，以提高网络处理器的利用率。
• 调整网络处理器的配置：如果网络处理器的配置过高，可以考虑减少线程数或调整其他相关配置，以匹配实际的请求负载。
• 监控 Kafka 集群的其他性能指标：确保磁盘 I/O、CPU 和内存等其他资源不是性能瓶颈。
• 设置告警：当 NetworkProcessorAvgIdlePercent 低于或高于某个阈值时触发告警，以便及时响应。

6.19、ISR变化速率

kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

用于监控In-Sync Replicas (ISR)集合的缩小频率。ISR集合是Kafka中用于保证数据可靠性和一致性的一个重要概念，它包含了所有与leader副本保持同步的follower副本。当follower副本因为某些原因（如网络问题、磁盘故障等）无法与leader副本保持同步时，它们会被从ISR集合中移除，这个过程被称为ISR缩小。

IsrShrinksPerSec指标表示每秒ISR集合缩小的次数。这个指标可以帮助你识别集群中可能存在的数据一致性问题或网络问题。如果IsrShrinksPerSec的值较高，可能意味着集群中存在大量的副本同步问题，这可能会影响数据的可靠性和消费者的读取性能。

以下是一个示例的返回内容，展示了IsrShrinksPerSec的监控数据：

json{
  "name": "kafka.server:type=BrokerTopicMetrics,topic=<your-topic-name>,partition=<your-partition-id>,name=IsrShrinksPerSec",
  "value": 0.5
}

在这个示例中：

• name字段包含了JMX对象的名称，指明了Kafka服务器的类型（kafka.server）、组件类型（type=BrokerTopicMetrics）、特定的主题（topic=<your-topic-name>）、分区（partition=<your-partition-id>）和指标名称（name=IsrShrinksPerSec）。
• value字段是IsrShrinksPerSec的值，表示每秒ISR集合缩小的次数。在这个例子中，每秒ISR集合缩小0.5次。

为了优化和解决IsrShrinksPerSec指标较高的问题，你可以考虑以下步骤：

1. 检查网络问题：确保Broker之间的网络连接稳定，并且没有频繁的断开和重连。
2. 检查磁盘问题：确保所有的Broker磁盘都健康，并且没有频繁的I/O错误。
3. 调整副本同步配置：考虑增加replica.fetch.max.bytes和replica.fetch.wait.max.ms等参数的值，以允许follower副本更高效地从leader副本同步数据。
4. 监控ISR集合：使用Kafka提供的工具（如kafka-topics.sh --describe --topic<topic-name> --bootstrap-server<broker-list>）来定期监控ISR集合的状态，以确保所有的副本都能保持同步。
5. 调整生产者和消费者的配置：确保生产者和消费者的配置合理，避免因为生产者发送速率过快或消费者拉取速率过慢而导致ISR集合缩小。

6.20、NumIncrementalFetchPartitionsCached

kafka.server:type=FetchSessionCache,name=NumIncrementalFetchPartitionsCached

消费者端当前缓存的增量获取（incremental fetch）分区的数量。这个指标反映了消费者在进行消息拉取时，哪些分区的偏移量信息被缓存起来，以便进行高效的增量拉取。

当消费者从 Kafka Broker 拉取消息时，它会记住每个分区上次拉取到的消息偏移量，并在下次拉取时请求从这个偏移量之后的新消息。为了优化这个过程，消费者会缓存这些分区的增量获取状态，这样它就不必在每次拉取时都去查询 Broker 获取最新的偏移量。

NumIncrementalFetchPartitionsCached 的值通常是一个非负整数，它表示当前被缓存的分区数量。这个值会随着消费者的运行而动态变化，当新的分区开始被增量拉取时，这个值会增加；当分区完成拉取或消费者关闭时，这个值会减少。

这个返回值表示当前有 5 个分区的增量获取状态被缓存在消费者端。

这个指标对于了解消费者端的性能和优化拉取操作是有帮助的。如果 NumIncrementalFetchPartitionsCached 的值很高，这可能意味着消费者正在有效地利用增量获取机制，避免了不必要的 Broker 请求。如果值很低或者频繁变动，可能表示消费者的拉取模式不够高效，或者分区的消息更新非常频繁，导致缓存的效用不大。

6.21、IncrementalFetchSessionEvictionsPerSec

kafka.server:type=FetchSessionCache,name=IncrementalFetchSessionEvictionsPerSec

衡量的是消费者在进行增量获取（incremental fetch）操作时，每秒因为缓存容量不足而被移除的增量拉取会话（incremental fetch session）的数量。

在 Kafka 的消费者客户端中，增量获取会话是用来跟踪每个分区当前拉取进度的机制。当消费者从 Kafka Broker 拉取消息时，它会为每个分区创建一个增量获取会话，并缓存这些会话以便进行高效的增量拉取。然而，由于缓存容量有限，当达到某个阈值时，一些较旧或不活跃的增量获取会话可能会被移除（即被驱逐），以便为新的或更活跃的会话腾出空间。

IncrementalFetchSessionEvictionsPerSec 指标表示这种驱逐操作的频率，即每秒有多少增量获取会话因为缓存容量不足而被移除。这个指标可以帮助你了解消费者客户端的增量获取缓存的使用情况，以及是否可能由于缓存容量不足而导致性能问题。

返回的内容通常是一个浮点数，表示每秒被移除的增量获取会话的平均数量。

如果 IncrementalFetchSessionEvictionsPerSec 的值较高，可能意味着增量获取缓存的容量不足以满足消费者的需求，或者消费者的拉取模式导致了缓存的频繁使用。这可能会影响消费者的性能，因为它可能导致消费者需要更频繁地向 Broker 发送请求来获取最新的偏移量和消息，而不是利用缓存进行高效的增量拉取。在这种情况下，你可以考虑增加增量获取缓存的容量，或者调整消费者的拉取模式以减少对缓存的需求。

6.22、NumIncrementalFetchSessions

kafka.server:type=FetchSessionCache,name=NumIncrementalFetchSessions

表示消费者客户端当前活动的增量获取会话（incremental fetch sessions）的数量。增量获取会话是消费者用来跟踪每个分区消息拉取进度的机制。

每当消费者开始从 Kafka Broker 增量拉取某个分区的消息时，它会为这个分区创建一个增量获取会话。这个会话会保持活动状态，直到拉取完成或因为某种原因（如缓存容量不足）而被移除。

NumIncrementalFetchSessions 返回的内容通常是一个整数，表示当前消费者客户端正在进行的增量获取会话的数量。

这个指标对于了解消费者客户端的拉取行为以及性能调优是有帮助的。如果 NumIncrementalFetchSessions 的值持续较高，这可能意味着消费者正在同时从多个分区拉取消息，这可能会增加网络和客户端处理的负担。如果值较低，则可能表示消费者的拉取操作比较稀疏，可能是因为分区的消息更新率较低，或者消费者的拉取频率较低。

此外，如果 NumIncrementalFetchSessions 的值频繁增加和减少，这可能意味着消费者的拉取行为不够稳定，可能需要调整拉取策略以减少这种波动。