Kafkaの監視で行き詰まる原因は、取れる指標が多すぎることにあります。ブローカーはJMX経由で数百のMBeanを露出しており、ダッシュボードにひととおり並べた結果、どの線が動いたら人を呼ぶのかが誰にも説明できない状態になりがちです。この記事では、まず見る指標を四系統に絞り、そこから取得経路と閾値を逆算する順番で監視を組み立てます。Apache Kafka本体の構成要素と役割は別記事で扱っているため、ここでは稼働中のクラスタを運用する側の視点に絞りました。
示すMBean名とマネージドサービス側のメトリクス名は、2026年8月30日にApache Kafka公式ドキュメント（AK 4.3.X系）とAWS公式ドキュメントで実測した値です。同日時点でサポート対象のリリースは 4.3.1（2026年6月25日公開）・4.2.1（2026年5月30日公開）・4.1.2（2026年3月17日公開）の3系統でした。
まとめ｜Kafka監視で先に決める四つの指標と取得経路
先に結論を置きます。Kafkaの監視で最初に固めるべきは、コンシューマーラグ・レプリケーションの健全性・ディスク使用率・リクエスト処理の余裕という四つです。この四つが揃っていれば、「データが遅れている」「冗長性が落ちている」「近いうちに書き込めなくなる」「詰まり始めている」という4種類の障害の入口を押さえられます。
取得経路は用途で分かれます。ブローカー側の指標はJMX Exporterをブローカーのプロセスに同居させてPrometheus形式で公開するのが素直な構成で、2026年8月30日時点の最新版は 1.6.0（2026年6月5日公開・Apache License 2.0）でした。一方、コンシューマーラグはブローカーのJMXだけでは組単位で追い切れないため、専用のExporterか管理APIを叩く仕組みを別に置きます。Logstash自身が消費者として動く構成のラグ設計はLogstash Kafka連携の設計で扱っています。
閾値は数値の大きさではなく、放置すると回復不能になるかで割ります。レプリカ不足やオフラインのパーティションは分単位で人を呼ぶ対象、ラグの増加は保持期間を食い潰すまでの猶予から逆算した時間で決める対象です。SaaS監視と自前のPrometheusは、監視対象のホスト数と保存期間の要求で線を引きます。以下、この順に設計手順を追います。
Kafka監視で最初に押さえるメトリクスは四つの系統に分かれる
Kafkaのメトリクスは、ブローカー・コントローラー・プロデューサー・コンシューマーの各層に散らばっています。層ごとに全部並べると数百になるため、「どの障害を早く知りたいか」から逆に必要な指標を引くやり方が現実的です。監視指標の型と収集方式そのものの整理はメトリクス監視の設計方法をまとめた記事に譲り、ここではKafka固有の指標に絞ります。
| 系統 | 知りたい障害 | 代表的な指標 |
|---|---|---|
| ラグ | 処理が追いつかない | records-lag-max |
| 複製 | 冗長性が落ちている | UnderReplicatedPartitions |
| 容量 | 書き込めなくなる | ディスク使用率 |
| 処理 | 詰まり始めている | リクエスト処理スレッド空き率 |
コンシューマーラグは件数と時間の二軸で読むと障害復旧判断が早い
コンシューマーラグは、パーティションの最新オフセットと、消費者グループがコミット済みのオフセットとの差です。Kafkaクライアント側では kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id} の records-lag-max という属性で取得できます。名前のとおり、そのクライアントに割り当てられたパーティションのうち最も遅れている値です。
件数だけを見ていると判断を誤ります。毎秒10万件を処理する構成でラグが50万件あっても5秒遅れに過ぎず、毎秒100件しか処理しない構成の50万件は1時間以上の遅延を意味するからです。監視画面には件数を出しつつ、アラートは「処理し切るまでの時間」に換算した値で鳴らす設計にすると、閾値の見直し回数が減ります。
グループ全体の集計値だけを見る運用も危うい。パーティション単位のラグに偏りが出ていても、集計値は平均に均されて動かないためです。キーの分布が偏る構成では、パーティションごとの最大値も併せて持っておきます。ラグの出方を左右するコミット方式そのものの選び方はKafka Java APIの実装設計で解説しています。
レプリケーションの崩れはISR関連の主要な三つの指標で捉える
複製の健全性は、次の3つで捉えられます。いずれも2026年8月30日時点のApache Kafka公式ドキュメント（4.3系）に記載のあるMBeanです。
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions：レプリカが規定数に届いていないパーティション数kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount：ISRがmin.insync.replicasの指定を下回ったパーティション数kafka.controller:type=KafkaController,name=OfflinePartitionsCount：リーダー不在で読み書きが止まっているパーティション数
この3つは深刻度が違います。1つ目は冗長性が落ちた状態で、書き込みはまだ通ります。2つ目は acks=all のプロデューサーが書き込みを拒否され始める段階です。3つ目はそのパーティションが完全に停止しています。同じ「レプリケーション異常」の括りで1本のアラートにまとめると、緊急度の違いが通知から消えてしまう。
補助として kafka.server:type=ReplicaManager,name=IsrShrinksPerSec と対になる IsrExpandsPerSec を見ると、ISRが縮んだまま戻らないのか、縮小と復帰を繰り返しているのかを区別できます。後者はネットワークの一時的な不安定さやブローカーのGC停止を示すことが多く、対処の方向が変わるためです。また kafka.controller:type=KafkaController,name=ActiveControllerCount はクラスタ全体で常に1になる指標で、0や2が続く状態はコントローラーの選出に問題が起きています。KRaftへ移行した構成ではコントローラーが専用ノードに分かれるため、この指標の監視対象ノードも合わせて見直します。
ディスク使用率とリクエスト処理の余裕は先行指標として監視に置く
Kafkaの障害で復旧が長引きやすいのがディスク枯渇です。ログセグメントが書けなくなったブローカーは停止し、パーティションのリーダーが移動して連鎖的に負荷が動きます。ディスク使用率はJMXではなくホスト側のメトリクスとして取得することになりますが、Kafkaの監視セットに含めておく指標です。保持期間の設定変更が効き始めるまでに時間がかかるため、80%を超えた段階で気づける位置に閾値を置きます。
処理の余裕は kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent で見ます。リクエスト処理スレッドの空き時間の割合で、1.0が完全な空き、0に近づくほど詰まった状態です。あわせて kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce のようにリクエスト種別ごとの所要時間を持っておくと、書き込みと読み出しのどちらが遅いのかを切り分けられます。流量そのものは kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec と BytesOutPerSec で追えます。
JMXからメトリクスを取り出す経路はブローカー側と利用側で分かれる
指標が決まったら、次は取り出し方です。ここを先に決めてしまうと、あとから「その指標はその経路では取れない」という手戻りが起きます。Kafkaの場合、ブローカー側とクライアント側で経路が別になる点が設計上の分岐点になります。
ブローカー側はJMX Exporterをjavaagentとして同居させる
ブローカーのJMXをPrometheus形式に変換する定番が、Prometheusコミュニティが公開しているJMX Exporterです。2026年8月30日にGitHubで確認した最新版は 1.6.0（2026年6月5日公開）で、ライセンスはApache License 2.0でした。ブローカーの起動オプションにjavaagentとして読み込ませ、各ブローカーが自分のメトリクスをHTTPで公開する構成にします。
この方式ならKafkaが露出するMBeanをそのまま拾えます。裏返せば、変換ルールを書かずに全部公開すると系列数が膨れ上がる。トピックやパーティション単位のメトリクスは対象数に比例して増えるため、収集の前段で絞らないと保存先の負荷と費用が想定を超えます。Prometheusがどういう設計思想で生まれたかを押さえておくと、pull型の収集間隔と保持設計の判断がしやすくなります。
Kubernetes上で動かすなら、Strimzi（2026年8月30日時点の最新は8月20日公開の 1.2.0）のようなオペレーターがメトリクス公開の設定ごと構成を管理するため、Exporterの配置とルール定義もその管理下へ寄せ、手作業の設定を残さない方針にします。
コンシューマーラグはブローカー側のJMX単独では取り切れない
ラグを組単位で追うには、ブローカーのJMXでは足りません。records-lag-max はコンシューマー側のクライアントが持つ指標であり、アプリケーションからメトリクスを送出する実装が必要になるからです。アプリの言語やフレームワークがまちまちな環境では、全アプリに同じ計装を入れる調整コストが無視できません。
そこで使われるのが、管理APIを叩いて消費者グループのオフセットと最新オフセットの差を計算する外部のExporterです。代表例のひとつが kafka_exporter で、2026年8月30日時点の最新リリースは v1.9.0（2025年2月17日公開・リポジトリへの最終pushは2026年4月13日）でした。もうひとつ、ラグの推移から状態を判定する仕組みを持つBurrowは v1.9.6（2026年5月11日公開）まで進んでいます。どちらも1プロセスを追加するだけで全消費者グループのラグを取れる代わりに、そのプロセス自体が単一障害点になる点は設計に織り込みます。
コネクタ経由のデータ連携を運用している場合、Kafka Connect側のワーカーとタスクの状態も監視対象に加えます。タスクが失敗状態のまま止まっていてもブローカー側の指標は正常に見えるため、ラグの停滞とタスク状態は別々に見る必要があるためです。Kafka Connectの構成要素とコネクタ運用で扱った状態遷移を、そのまま監視項目に落とすと漏れが減ります。日常的な状態確認だけならKafka UIのような管理コンソールでも足りますが、こちらは時系列の蓄積と通知を持たないため、監視基盤の代わりにはなりません。
マネージドのMSKではCloudWatchの監視レベルが先に効く
Amazon MSKを使っている場合、JMXの取り出し方を考える前に監視レベルの選択が来ます。AWS公式ドキュメントで2026年8月30日に確認したところ、プロビジョンド構成では DEFAULT・PER_BROKER・PER_TOPIC_PER_BROKER・PER_TOPIC_PER_PARTITION の4段階が用意され、メトリクスは1分間隔で送られます。DEFAULTレベルのメトリクスは無償で、それより上の段階は有償です。
| レベル | 追加で得られるもの | 費用 |
|---|---|---|
| DEFAULT | 複製・容量・組単位のラグ | 無償 |
| PER_BROKER | 処理時間とスロットリング | 有償 |
| PER_TOPIC_PER_BROKER | トピック別の流量 | 有償 |
| PER_TOPIC_PER_PARTITION | パーティション別のラグ | 有償 |
設計上の要点は、消費者グループのラグがDEFAULTの段階で MaxOffsetLag・SumOffsetLag・EstimatedMaxTimeLag として得られることです。先ほど述べた「時間に換算した閾値」は、MSKでは EstimatedMaxTimeLag をそのまま使えます。パーティション単位の OffsetLag と EstimatedTimeLag は最上位のレベルでしか出ないため、偏りの検知まで必要かどうかで段階を選びます。
アラートの閾値は数値の大きさでなく障害から回復可能かどうかで割る
指標と経路が決まると、次は「どこで人を呼ぶか」です。ここを数値の大きさだけで決めると、夜間に鳴るが翌朝には自然に戻っている通知が積み上がり、やがて誰も見なくなります。
Kafka運用で即時に人を起こす条件と当日中の対応でよい条件を分ける
分ける基準は、放置した場合に自動で回復するかです。オフラインのパーティションやISRが最小値を割った状態は、書き込みが拒否され続けるため自動では戻りません。これは即時通知の対象です。対してレプリカ不足は、ブローカーの再起動中など一時的な要因でも発生し、追いつけば自然に0へ戻ります。数分続いたら通知、という時間の条件を付けるのが実務的です。
通知先とテンプレートの設計は監視ツール側の仕事になります。評価ウィンドウの長さと通知の分岐をどう組むかは、Datadogのモニタータイプと閾値設計で扱った考え方がそのまま当てはまります。ツールが変わっても、「何分続いたら」「誰に」「どの復旧手順へ誘導するか」の3点を必ずセットで決める構造は共通です。
Kafka監視ではラグの閾値を件数でなく処理し切る時間に置き換える
ラグの閾値で失敗しやすいのは、固定の件数で決めてしまうやり方です。トラフィックが日中と夜間で10倍違う構成では、日中に合わせると夜間の異常を見逃し、夜間に合わせると日中に鳴り続けます。
置き換え方は単純で、直近の処理速度でラグを割った値、つまり追いつくのに必要な秒数を計算対象にします。加えて、その秒数がトピックの保持期間に迫っているかを第二の条件に置く。保持期間を超えて遅れた消費者は、読むべきデータが削除されてしまうため、ここがデータ欠損の分岐点になります。保持期間が3日でラグが6時間相当なら余裕があり、保持期間が6時間でラグが3時間相当なら緊急です。
SaaS監視と自前のPrometheusは費用と工数で線を引く
取得経路と閾値が固まったら、どこに預けるかを決めます。ここは技術的な優劣ではなく、監視対象の規模と社内で確保できる運用工数の問題です。
監視サービスのホスト課金とメトリクス数課金で費用が膨らむ場所は変わる
SaaSの監視サービスは、対象ホスト数を基準にした課金にカスタムメトリクス数の加算が乗る形が一般的です。Kafkaはトピックとパーティションの単位でメトリクスが増えるため、ブローカー台数が少なくてもトピック数が多い構成では費用が伸びます。契約前に系列数を概算すると見積りのぶれが減ります。
自前のPrometheusは収集そのものに費用はかかりませんが、保存先のストレージ、長期保存の仕組み、そして監視基盤自体の冗長化が必要です。監視基盤が落ちている間はKafkaの異常も見えないため、Kafkaを止められない構成なら監視側にも同水準の可用性を求めることになります。この作業量を人件費に換算すると、小規模な構成ではSaaSの方が安く収まる場合が多い。
自前のPrometheus構成は保存期間と高可用の設計が別途必要になる
自前で組む場合、Prometheus単体の保存期間はローカルストレージの容量に縛られます。数か月前と比較する事後分析まで想定するなら長期保存の層が別に要る。後回しにすると「先月と比べてラグの傾向が変わったか」に答えられないダッシュボードが残ります。
逆に、SaaSを選んだ場合でも、生のJMXを取り出す部分は自前です。エージェントがKafkaのMBeanをどこまで拾ってくれるかは製品ごとに違うため、四系統の指標が既定の設定で取れるかを検証段階で確認しておきます。取れない指標があれば、JMX Exporterを併用する構成に倒すことになります。
Kafka監視をどこまで作り込むかの投資判断を運用条件で示す
ここまでの内容を、実際に手を動かすかどうかの判断に落とします。監視は作れば作るほど良いものではなく、維持する人がいなければダッシュボードは古くなって嘘をつき始めるためです。
作り込みに踏み切ってよいのは本番環境の停止が業務に直結する構成
四系統すべてを揃え、閾値と通知経路まで作り込む価値が明確に出るのは、次の条件に当てはまる構成です。第一に、Kafkaを流れるデータが業務処理そのもの、たとえば決済や在庫の連携に使われていて、数十分の遅延が業務停止と同義になる場合。第二に、複数のチームが同じクラスタへ相乗りしていて、遅延の原因がどのアプリにあるかを切り分ける必要がある場合。第三に、トピックの保持期間を短く設定していて、遅延がそのままデータ欠損につながる場合です。
この条件に当てはまるなら、監視の設計はKafkaの構築と同時に進めます。稼働後に足す順番だと、閾値を決めるための平常時のデータが手元にないまま勘で数値を置くことになり、結局は運用開始後に何度も調整する羽目になる流れです。データ基盤の設計から運用体制の整備までを含めて進めたい場合は、データ分析基盤構築・MLOps構築支援のような外部の支援を組み合わせる方法もあります。
監視基盤を増やさず見送ってよいのは小規模な検証段階のクラスタ
反対に、作り込みを見送ってよい場面もはっきりしています。検証目的で単一ブローカーを立てているだけの構成では、レプリケーション関連の指標は常に0のままで意味を持ちません。この段階では、既存の監視でホストのCPUとディスクを見て、ラグはコマンドで随時確認する運用で足ります。
マネージドサービスを使っていて消費者が1つか2つしかない構成も同様です。MSKならDEFAULTレベルにアラームを2、3本かけるだけで四系統の要点は押さえられます。ここで自前のPrometheusとダッシュボード一式を立てると、Kafka本体より監視基盤の運用工数が上回る逆転が起きる。監視の構築と維持に月あたり何時間を割けるかを先に決め、その範囲に収まる構成を選ぶのが目安になります。
よくある質問
Kafkaの監視で最初に設定すべきアラートはどれですか？
1本だけ選ぶなら UnderMinIsrPartitionCount です。この値が0より大きい状態は、acks=all の書き込みが拒否されていることを意味し、自動では回復しません。次に OfflinePartitionsCount、その次にディスク使用率の順で足していくと、深刻な障害から順に検知できる並びになります。
コンシューマーラグの監視はコマンドでは代用できませんか？
一時的な確認であれば kafka-consumer-groups.sh の describe で足ります。ただしコマンドは実行した瞬間の値しか返さないため、いつから遅れ始めたのかは追えません。継続的に見るなら、値を時系列で保存する仕組みが必要になります。
JMX ExporterとkafkaのExporterは両方入れるべきですか？
役割が違うため多くの構成では併用します。JMX Exporterはブローカーの内部状態、kafka_exporterのような専用Exporterは消費者グループのラグを担当する。片方だけでは四系統のどれかが欠けます。
マネージドサービスなら監視は不要になりますか？
基盤の障害対応は事業者側が担いますが、アプリケーション起因の遅延やトピック設計の問題は利用者側に残ります。MSKのDEFAULTレベルでもラグと複製の指標は取れるため、無償の範囲でアラームを置くところから始めます。
監視の指標はどのくらいの間隔で見直せばよいですか？
トピックやコンシューマーの構成が変わったときが見直しの機会です。加えて、鳴ったのに対応不要だった通知の件数を四半期ごとに数え、比率の高い閾値から調整していく方法があります。
関連記事
- Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：監視対象となるブローカーとトピックの構造を先に押さえられます。
- Kafka KRaftとは？ZooKeeper廃止後の構成と移行手順を実装視点で解説：コントローラー関連の指標を見る対象ノードの判断に使えます。
- Kafka UIとは？Kafbat UIへの世代交代と権限設計・本番投入の可否を実装視点で解説：日常の状態確認を画面で行う場合の選択肢です。
- Kafka Connectとは？構成要素とコネクタ運用を実装視点で解説【2026年版】：コネクタのタスク状態を監視項目に落とす際の前提になります。
- メトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説：指標の型と収集方式の一般論を確認できます。
- Datadogモニターのタイプ選定と閾値設計：評価ウィンドウと通知テンプレートの実装手順：通知条件の組み方を具体的な設定粒度で確認できます。
