Kafka JMX メトリクス: 重要 MBean と閾値設計

Kafka ブローカーは JMX を通じて多数のメトリクスを公開します。試験でも現場でも、名前空間と属性の粒度を正しく押さえることが重要です。

本稿では、安定して試験・運用に使える MBean と、誤検知を避ける閾値の設計指針をまとめます。ZooKeeper モードと KRaft で細部は変化し得ますが、基本の JMX 名称と Yammer メトリクス属性は一貫しています。

重要 MBean 概観とメトリクス分類

Kafka の JMX は Yammer Metrics ベースです。Gauge は Value、Meter は Count/MeanRate/OneMinuteRate、Timer は 50thPercentile/95thPercentile/99thPercentile などの属性を持ちます。試験では属性名の綴り（99thPercentile など）が問われることがあります。

運用と CCAAK で特に重要なのは次のカテゴリです。可用性（ActiveControllerCount、OfflinePartitionsCount）、複製健全性（UnderReplicatedPartitions、IsrShrinksPerSec）、スループット（BytesIn/OutPerSec、MessagesInPerSec）、レイテンシ（RequestMetrics TotalTimeMs）、スレッド余力（RequestHandlerAvgIdlePercent）、JVM（java.lang:type=Memory, GarbageCollector）。

• kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions（Gauge: Value）
• kafka.controller:type=KafkaController,name=ActiveControllerCount（Gauge: Value）
• kafka.controller:type=KafkaController,name=OfflinePartitionsCount（Gauge: Value）
• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec|BytesOutPerSec|MessagesInPerSec（Meter: Count, OneMinuteRate など）
• kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent（Gauge: Value）
• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce|FetchConsumer（Timer: 95thPercentile, 99thPercentile など）

JmxTool で基本メトリクスをダンプ（安定的な属性名を指定）

kafka-run-class kafka.tools.JmxTool \
  --jmx-url service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi \
  --object-name 'kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec' \
  --attributes Count,OneMinuteRate,FiveMinuteRate,MeanRate \
  --reporting-interval 3000 --duration 15000

レプリケーション健全性: 閾値と運用アクション

UnderReplicatedPartitions は最重要の健全性シグナルです。Value > 0 が継続する場合は、ネットワーク遅延、ブローカー停止、ディスク I/O 劣化などを疑います。OfflinePartitionsCount はさらに重篤で、即時復旧が必要です。

IsrShrinksPerSec / IsrExpandsPerSec は ISR 変動の頻度を示し、スパイクは遅延・GC 停止やディスク輻輳の兆候になり得ます。レプリカラグは ReplicaFetcherManager の MaxLag 系 MBean で把握します（バージョンにより正確なオブジェクト名は変わるため、実機で列挙して確認する習慣を持ちましょう）。

• UnderReplicatedPartitions: warn > 0 が 1〜2 分継続、crit > 0 が 5 分以上
• OfflinePartitionsCount: crit > 0 を即時ページ
• IsrShrinksPerSec: ベースライン比 3× 以上のスパイクで warn
• ReplicaFetcherManager MaxLag: トピック SLA に合わせてしきい値（例: 10 秒超で warn、60 秒超で crit）
• 継続時間でノイズ除去（短時間のリーダー移譲は除外）

jmxterm で URP を即時確認（Gauge: Value）

# jmxterm の例
open localhost:9999
get -b kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions Value
# 応答例: mbean = kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions:
# Value = 0

コントローラとパーティション状態の監視

ActiveControllerCount はクラスター全体でちょうど 1 である必要があります。ZooKeeper モードでも KRaft でも、能動コントローラは常に 1 つです（公開ネームスペースは実装により変化し得るため、実機で列挙して確認）。

PreferredReplicaImbalanceCount はリーダーが優先レプリカから外れている分割の数で、継続的な増加はバランス不良の兆候です。PartitionCount と LeaderCount の比率や急変も健全性確認に使えます。

• ActiveControllerCount: 1 以外は crit（多重化・0 は即時復旧）
• OfflinePartitionsCount: 0 であることを常時監視
• PreferredReplicaImbalanceCount: 継続的増加で warn、再割当や再バランスを検討

Jolokia 経由で ActiveControllerCount を取得

curl -s http://broker1:8778/jolokia/read/kafka.controller:type=KafkaController,name=ActiveControllerCount | jq .value.Value

スループットとレイテンシ: BrokerTopicMetrics と RequestMetrics

BytesInPerSec/BytesOutPerSec と MessagesInPerSec は容量計画と急変検知の基礎です。MeanRate より OneMinuteRate を主監視にすると変化に追従しやすくなります。

RequestHandlerAvgIdlePercent はリクエスト処理スレッドの余力です。低下が継続（例: < 0.2）すると待ち行列増加やレイテンシ悪化に繋がります。RequestMetrics TotalTimeMs の 95thPercentile/99thPercentile でレイテンシ SLO を直接監視します。

• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec|BytesOutPerSec（OneMinuteRate）
• kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec（OneMinuteRate）
• kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent（Value < 0.2 で warn）
• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce|FetchConsumer（99thPercentile を SLO に連動）
• kafka.network:type=Processor,name=IdlePercent,networkProcessor=0..N（ネットワーク処理余力）

クライアント要求からログ書き込み・複製までの経路と主な MBean

Clients --> [NetworkProcessor] --> [RequestQueue] --> [RequestHandler]
                                       |                        |
                                       v                        v
                                   RequestMetrics         BrokerTopicMetrics
                                                                |
                                                                v
                                                          [Log Append]
                                                                |
                                                                v
                                                   ReplicaFetcherManager --> Followers

監視ポイント:
- RequestHandlerAvgIdlePercent (kafka.server:KafkaRequestHandlerPool)
- TotalTimeMs (kafka.network:RequestMetrics)
- BytesIn/OutPerSec・MessagesInPerSec (kafka.server:BrokerTopicMetrics)
- MaxLag (kafka.server:ReplicaFetcherManager)

jmxterm でレイテンシと余力を確認

open localhost:9999
# 99 パーセンタイルのプロデュースレイテンシ
get -b kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce 99thPercentile
# ハンドラ余力（0.0〜1.0）
get -b kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent Value

JVM とディスク I/O のボトルネック検知

JVM ヒープの健全性は java.lang:type=Memory の HeapMemoryUsage で追跡します。used/committed が 0.8 を越え継続する場合は、GC 圧や OOM リスクを疑います。GarbageCollector の CollectionTime/CollectionCount で GC 負荷も補助的に監視します。

ログ書き出しとフラッシュの遅延は kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs のパーセンタイルで把握できます。OS レベルのディスク使用率と併せて相関を見ると原因切り分けが容易です。

• java.lang:type=Memory HeapMemoryUsage.used/committed > 0.8 が 5 分継続で warn
• java.lang:type=GarbageCollector,name=G1 Old Generation CollectionTime が急増で warn
• kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs 99thPercentile がベースラインの 2× 以上で warn

JVM ヒープ状況を JMX で取得

open localhost:9999
get -b java.lang:type=Memory HeapMemoryUsage
# 返値の used, committed を使用率計算に利用

アラート設計: 静的しきい値とベースラインの併用

可用性直結のメトリクス（OfflinePartitionsCount、ActiveControllerCount）は静的かつ即時のしきい値が妥当です。一方でトラフィックやレイテンシは業務ごとのリズムがあるため、ベースライン（移動平均・分位）と組み合わせると誤検知を減らせます。

JMX Exporter（Prometheus）を使う場合、Yammer の属性名をそのまま時系列にマッピングします。Timer の 99thPercentile を SLA に対応させ、継続時間条件でページングの騒音を抑制します。

• 致命系は静的しきい値＋即時ページ（OfflinePartitionsCount > 0, ActiveControllerCount != 1）
• 性能系はベースライン逸脱＋継続時間（p99 レイテンシ、IdlePercent 低下）
• 相関ルールで原因推定（URP 上昇かつネットワーク Idle 低下で帯域ボトルネックを疑う）

Prometheus ルールと JMX Exporter の最小設定例

# jmx_exporter (jmx_prometheus_javaagent) の rules 抜粋
rules:
- pattern: 'kafka.server<type=ReplicaManager, name=UnderReplicatedPartitions><>Value'
  name: kafka_under_replicated_partitions
  type: GAUGE
- pattern: 'kafka.controller<type=KafkaController, name=ActiveControllerCount><>Value'
  name: kafka_active_controller_count
  type: GAUGE
- pattern: 'kafka.network<type=RequestMetrics, name=TotalTimeMs, request=(.+)><>(99thPercentile)'
  name: kafka_request_latency_p99
  labels:
    request: "$1"
  type: GAUGE

# alerting rules (Prometheus)
- alert: KafkaURPCritical
  expr: kafka_under_replicated_partitions > 0
  for: 5m
  labels: {severity: critical}
  annotations:
    summary: "URP が 5 分以上継続"
- alert: KafkaActiveControllerAnomaly
  expr: kafka_active_controller_count != 1
  for: 1m
  labels: {severity: critical}
  annotations:
    summary: "ActiveControllerCount が 1 ではない"
- alert: KafkaProduceLatencyHigh
  expr: kafka_request_latency_p99{request="Produce"} > 200
  for: 10m
  labels: {severity: warning}
  annotations:
    summary: "プロデュース p99 レイテンシが 200ms を 10 分超過"

問題で確認

よくある質問