Kafka モニタリング: 主要メトリクスと見方（CCAAK 対策と実務）

Kafka は高スループットと耐障害性が魅力ですが、正しく監視しないと性能劣化やデータ喪失リスクに気づけません。本稿では、ブローカとクライアントの主要メトリクス、読み解き方、しきい値設計の勘所をまとめます。

内容は Apache Kafka/Confluent ドキュメントに基づく安定概念を中心にし、バージョン差異に依存しにくい指標を選んでいます。試験（CCAAK）で問われやすいポイントも明示します。

監視アーキテクチャの全体像

Kafka ブローカは JMX を通じてメトリクスを公開します。一般的には JMX Exporter（Java Agent）で HTTP エンドポイントに変換し、Prometheus が収集、Grafana で可視化、Alertmanager で通知します。Confluent 環境では Control Center や Metrics API（Confluent Cloud）も利用できます。

収集経路と責務を分離し、メトリクスの鮮度（スクレイプ間隔）と粒度（平均/分位点）を用途別に設計します。レイテンシは高頻度、容量系は低頻度で十分、というのが実務の定石です。

• 露出元: Kafka ブローカの JMX、クライアント（producer/consumer）のクライアントメトリクス
• 変換: JMX Exporter（jmx_prometheus_javaagent）
• 収集/保管: Prometheus（scrape_interval に注意）
• 可視化/通知: Grafana/Alertmanager
• マネージド: Confluent Control Center / Confluent Cloud Metrics API

Kafka メトリクス収集の典型フロー

JMX Exporter + Prometheus 設定例（抜粋）

# Kafka ブローカの起動オプション例（systemd など）
# JMX Exporter を Java Agent として有効化
Environment="KAFKA_OPTS=-javaagent:/opt/jmx/jmx_prometheus_javaagent.jar=7071:/opt/jmx/kafka.yml"

# Prometheus の scrape 設定例
scrape_configs:
  - job_name: 'kafka-brokers'
    scrape_interval: 15s
    static_configs:
      - targets: ['broker-1:7071','broker-2:7071','broker-3:7071']
    relabel_configs:
      - source_labels: [__address__]
        regex: '([^:]+):.*'
        target_label: instance
        replacement: '$1'

ブローカのコアメトリクス（意味と健全値の目安）

まず押さえるのは可用性・整合性に直結するメトリクスです。UnderReplicatedPartitions（URP）、OfflinePartitionsCount、ActiveControllerCount はアラート一次指標として定番です。スループット系（BytesIn/Out、MessagesIn）は容量計画とボトルネック推定に使います。

要求遅延は単一メトリクスではなく、キュー待ち・ネットワーク・ディスク I/O などの合成です。RequestMetrics をリクエスト種別（Produce/Fetch/FetchConsumer）ごとに見るのが試験・実務の双方での正解パターンです。

• 可用性: kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
• 可用性: kafka.controller:type=KafkaController,name=ActiveControllerCount（常に1が正常）
• 可用性: kafka.controller:type=KafkaController,name=OfflinePartitionsCount（0が正常）
• スループット: kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec/BytesOutPerSec
• 遅延分解: kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce/Fetch
• 負荷目安: kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

レイテンシとスループットの分解

Kafka の RequestMetrics では TotalTimeMs を QueueTimeMs、LocalTimeMs、RemoteTimeMs、ResponseQueueTimeMs などに分割して観測できます。Queue が伸びるならスレッド不足や GC、Local が伸びるならディスク I/O、Remote が伸びるならネットワークと解釈できます。

分位点（p95/p99）でアラート候補を作り、平均はダッシュボード参照程度に留めるのが無難です。Produce と Fetch（特に consumer 向けの FetchConsumer）は分けて見るのが試験でも現場でも鉄則です。

• Produce と Fetch は別軸で可視化（混在させない）
• TotalTimeMs の内訳を同時に表示して原因局所化
• p95/p99 を主指標、平均は補助
• Throughput（BytesIn/Out、MessagesIn）と遅延の相関を確認

コンシューマラグの正しい見方

コンシューマラグは各パーティションの Log End Offset と Consumer Group の Committed Offset の差分です。瞬間的なスパイクは正常でも、解消トレンドがない継続ラグは要対応です。auto.commit.interval.ms、max.poll.interval.ms、max.poll.records などの設定が挙動に直結します。

試験（CCAAK）では、lag の解釈ミス（バッチ処理で一時的に膨らむ、コミット遅延で見かけが増える等）を問う設問が定番です。ツールでは kafka-consumer-groups を使い、Group/Member/Partition 単位で把握します。

• 観測単位を Group x Topic x Partition で揃える
• 「増える→減る」周期があるか（処理サイクル由来）を確認
• max.poll.interval.ms 超過はリバランスを招きラグが悪化しがち
• スケールはまずコンシューマ並列度（= パーティション数上限）で判断

kafka-consumer-groups でのラグ確認（例）

# 代表的なコマンド
$ kafka-consumer-groups --bootstrap-server broker-1:9092 \
  --group analytics-app --describe

GROUP           TOPIC      PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG   CONSUMER-ID        HOST            CLIENT-ID
analytics-app   events     0          128345          128400          55    consumer-1-...     /10.0.0.21      analytics-1
analytics-app   events     1          127998          128001          3     consumer-2-...     /10.0.0.22      analytics-2

# 解釈のコツ
# - LAG が波打ちながらも平均的に収束 → 正常範囲
# - LAG が累積的に増える/固定化 → スループット不足 or 停滞

ストレージ・耐障害性メトリクス

ディスク I/O とレプリケーション挙動は遅延と可用性に直結します。LogFlushRateAndTimeMs、Produce/FetchRequestPurgatorySize、IsrShrinksPerSec/IsrExpandsPerSec は安定運用の鍵です。URP が出なくても、IsrShrinks が増える兆候は早めに拾います。

また、パーティション過多はオープンファイル数やメタデータ処理コストを押し上げます。PartitionCount、LeaderCount を定期観測し、無秩序なトピック/パーティション増加を防ぎます。

• kafka.server:type=ReplicaManager,name=IsrShrinksPerSec / IsrExpandsPerSec
• kafka.server:type=BrokerTopicMetrics,name=LogFlushRateAndTimeMs
• kafka.server:type=DelayedOperationPurgatory,name=ProduceRequestPurgatorySize
• kafka.server:type=ReplicaManager,name=PartitionCount / LeaderCount
• OS 指標（ディスク待ち、IOPS、ファイルディスクリプタ枯渇）も併観

アラート設計と CCAAK 観点の要点

アラートは「可用性一次指標」「性能劣化の先行指標」「容量逼迫の傾向」の3層に分けて設計します。一次指標は即時通知、先行指標は連続条件とヒステリシス、容量は予兆検知（傾き監視）がおすすめです。

試験対策では、URP/ActiveController/OfflinePartitions の意味と通常値、RequestMetrics の分解、Lag の正しい読み方、そして Confluent 系ツールでの可視化が頻出です。実務では平常時ベースラインを取り、相対変化率でのアラートも併用すると誤検知が減ります。

• 一次: URP>0、ActiveController!=1、OfflinePartitions>0（即時）
• 先行: p95 Produce/Fetch 遅延の平常比 2–3倍が継続
• 容量: BytesIn/Out の週次増加率、ディスク使用率の傾き
• Lag は「解消するか」をまず見る。スナップショット値のみで判断しない

問題で確認

よくある質問