DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Kafkaの健全性を監視・アラートするための効果的な戦略

この記事では、Apache Kafkaクラスターを効果的に監視し、アラートを設定するための包括的なガイドを提供します。コンシューマーラグ、アンダーレプリケーションパーティション、ブローカーのリソース使用率などの重要なメトリクスを追跡する方法を学びます。PrometheusやGrafanaなどのツールを使用した実践的な戦略や、ダウンタイムを防止しイベントストリーミングプラットフォームの健全性を確保するためのプロアクティブなアラート設定の重要なヒントを紹介します。

Kafkaの健全性を監視・アラートするための効果的な戦略

Kafkaの障害は、事後的に見ればめったに謎ではありません。ブローカーのディスクがいっぱいになった、コンシューマーグループが遅れをとった、トピックのリーダーシップが正常に失われた、コントローラーがフラッピングを始めた、ネットワーク経路が遅くなりクライアントがタイムアウトしたなどです。難しいのは、無害なスパイクごとに人を呼び出すことなく、これらのシグナルを早期にキャッチすることです。

優れたKafka監視は、少数の健全性に関する質問から始まります。ブローカーはリクエストを処理できるか、パーティションはリーダーを選出できるか、レプリカは追いついているか、コンシューマーは十分な速度で処理しているか、クラスターのCPU、メモリ、ネットワーク、ディスクが不足していないか。以下のメトリクスは、これらの質問にマッピングできるため有用です。

Kafka監視が重要な理由

Kafkaの分散アーキテクチャは、いくつかの潜在的な障害点とパフォーマンス低下の原因を導入します。これらの潜在的な問題とその監視方法を理解することは、健全なクラスターを維持するための鍵です：

  • データレイテンシー： 高いコンシューマーラグは、コンシューマーがプロデューサーのレートに追いついていないことを示し、古いデータを引き起こし、ダウンストリームアプリケーションに影響を与える可能性があります。
  • リソース使用率： ブローカーのCPU、メモリ、ディスク容量の不足は、パフォーマンス低下、応答不能、さらにはブローカーのクラッシュにつながる可能性があります。
  • パーティションの不均衡： ブローカー間でのパーティションの不均等な分散は、一部のブローカーが過負荷になり、他のブローカーが十分に活用されず、スループットと可用性に影響を与える可能性があります。
  • ブローカーの可用性： ブローカーの障害は、適切に処理されない場合、データの利用不可や損失につながる可能性があります。フォールトトレランスには、ブローカーの健全性を監視することが最も重要です。
  • ネットワークの問題： ブローカー間またはクライアントとブローカー間のネットワークパーティションや高レイテンシは、クラスターのパフォーマンスと安定性に深刻な影響を与える可能性があります。

監視すべき主要なKafkaメトリクス

効果的な監視は、適切なメトリクスを追跡することに依存します。これらは大まかに、ブローカーレベル、トピックレベル、クライアントレベルのメトリクスに分類できます。

ブローカーレベルのメトリクス

これらのメトリクスは、個々のKafkaブローカーの健全性とパフォーマンスに関する洞察を提供します。

  • リクエストメトリクス：

    • kafka.network.RequestMetrics.RequestsPerSec（受信リクエストのレート）
    • kafka.network.RequestMetrics.TotalTimeMs（リクエスト処理にかかった合計時間）
    • kafka.network.RequestMetrics.ResponseQueueTimeMs（応答キューで費やされた時間）
    • kafka.network.RequestMetrics.LocalTimeMs（ブローカーで費やされた時間）
    • kafka.network.RequestMetrics.RemoteTimeMs（他のブローカーとの通信に費やされた時間）
    • kafka.network.RequestMetrics.TotalBytesInPerSec & TotalBytesOutPerSec（ネットワークスループット）

  • ログメトリクス：

    • kafka.log.Log.Size（ディスク上のログセグメントのサイズ）
    • kafka.log.Log.N.MessagesPerSec（ログセグメントに書き込まれるメッセージのレート）
    • kafka.log.Log.N.BytesPerSec（ログセグメントに書き込まれるバイトレート）
    • kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs（ログセグメントのフラッシュのレートと時間）

  • コントローラーメトリクス：（リーダー選出とパーティション管理に重要）

    • kafka.controller.Controller.ControllerStateChangesPerSec
    • kafka.controller.Controller.LeaderChangesPerSec

  • JVMメトリクス：（ブローカーのリソース使用率を理解するために不可欠）

    • kafka.server:type=jvm,name=HeapMemoryUsage
    • kafka.server:type=jvm,name=NonHeapMemoryUsage
    • kafka.server:type=jvm,name=GarbageCollection
    • kafka.server:type=jvm,name=Threads

トピックレベルのメトリクス

これらのメトリクスは、特定のKafkaトピックのパフォーマンスと健全性に焦点を当てています。

  • アンダーレプリケーションパーティション：

    • kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions（希望よりもレプリカが少ないパーティションの数）
    • このメトリクスに対するアラートは、データの耐久性と可用性にとって重要です。

  • オフラインパーティション：

    • kafka.cluster.PartitionState.OfflinePartitionsCount（利用できないパーティションの数）
    • 高い数値は、パーティションのリーダーシップまたはブローカーの可用性に深刻な問題があることを示します。

  • リーダー選出レート：

    • kafka.controller.Controller.LeaderChangesPerSec（リーダーの再選出のレート）
    • スパイクは、不安定性やブローカーの障害を示している可能性があります。

コンシューマーグループのメトリクス

これらのメトリクスは、コンシューマーラグとアプリケーションの処理速度を理解するために不可欠です。

  • コンシューマーラグ： これは多くの場合、直接的なKafkaメトリクスではなく、トピックに生成された最新のオフセットとグループによって消費された最新のオフセットを比較することで計算されます。監視ツールは通常、この計算を提供します。

    • 重要なアラート： 高いコンシューマーラグ（例：定義されたしきい値を一定期間超えている）は、コンシューマーが遅れていることを示します。

  • フェッチリクエストメトリクス（コンシューマーの観点から）：

    • kafka.consumer.Fetcher.MaxLag
    • kafka.consumer.Fetcher.MinFetchWaitMs
    • kafka.consumer.Fetcher.MaxFetchWaitMs

監視ソリューションの実装

Kafkaを監視するために、いくつかのツールとアプローチを使用できます。選択は、既存のインフラストラクチャと運用上のニーズに依存することがよくあります。

JMXとPrometheus

Kafkaブローカーは、JMX（Java Management Extensions）を介して豊富なメトリクスを公開します。Prometheusのようなツールは、jmx_exporterのようなアダプターを使用してこれらのJMXメトリクスをスクレイピングできます。

  1. JMXを有効にする： Kafkaは通常、デフォルトでJMXが有効になっています。JMXポートにアクセスできることを確認してください。
  2. jmx_exporterを設定する： jmx_exporterをダウンロードして設定し、KafkaのJMXメトリクスをPrometheus互換の形式で公開します。スクレイピングするMBeanを指定する設定YAMLファイルが必要です。 Kafka JMXのjmx_exporter設定スニペットの例： jmx_exporter/example_configs/kafka-2-0-0.yml（多くの場合、jmx_exporterリポジトリにあります）
  3. Prometheusを設定する： Prometheus設定に、Kafkaブローカーと一緒に実行されているjmx_exporterによって公開されたエンドポイントをスクレイピングするターゲットを追加します。
    scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['<kafka-broker-ip>:9404'] # jmx_exporterのデフォルトポート
  4. Grafanaで可視化する： Grafanaを使用して、これらのPrometheusメトリクスを表示するダッシュボードを構築します。事前構築済みのKafkaダッシュボードは、Grafana Labsで入手できます。

Kafka固有の監視ツール

  • Kafka Manager（旧Yahoo Kafka Manager）： Kafkaクラスターを管理するための人気のあるWebベースのツール。ブローカーのステータス、トピックの検査、コンシューマーラグの監視、パーティション管理を提供します。
  • CMAK（Cluster Manager for Apache Kafka）： Kafka Managerのフォークで、積極的にメンテナンスされており、同様の機能を提供します。
  • Lenses.io / Confluent Control Center： 高度なKafka監視、管理、データ可視化機能を提供する商用製品。
  • オープンソースのKafka監視スタック： Kafkaログを使用したELKスタック（Elasticsearch、Logstash、Kibana）、または時系列データ用のTICKスタック（Telegraf、InfluxDB、Chronograf、Kapacitor）などの組み合わせ。

効果的なアラートの設定

メトリクスが収集されたら、次のステップは重要な状態に対するアラートを設定することです。アラート戦略は、アプリケーションの可用性、データの整合性、またはパフォーマンスに直接影響を与える問題に焦点を当てる必要があります。

設定すべき重要なアラート：

  • アンダーレプリケーションパーティション > 0： これは、データ損失または利用不可の可能性を示す優先度の高いアラートです。即時の調査が必要です。
  • オフラインパーティション数 > 0： アンダーレプリケーションパーティションと同様に、完全に利用できないパーティションを示します。
  • 高いコンシューマーラグ： 古いデータに対するアプリケーションの許容度に基づいてしきい値を定義します。ラグが特定の期間（例：5分間）このしきい値を超えた場合にアラートを発します。 PromQLの例（Prometheus/Grafanaの概念）：
    avg_over_time(kafka_consumergroup_lag_max{group="your-consumer-group"}[5m]) > 1000
    注：正確なメトリクス名とラグの計算方法は、監視設定（例：Kafka独自のメトリクス、kafka-exporter、またはクライアント側のメトリクスの使用）によって異なります。
  • ブローカーのCPU/メモリ/ディスク使用率： 使用率が事前定義されたしきい値（例：CPU/メモリは80%、ディスクは90%）を超えた場合にアラートを発します。ディスク容量はKafkaにとって特に重要です。
  • 高いリクエストレイテンシ： RequestMetrics.TotalTimeMsまたは特定のリクエストタイプ（例：Produce、Fetch）の持続的な増加に対してアラートを発します。
  • ブローカーの再起動/利用不可： Kafkaブローカーが到達不能になったり、メトリクスの報告を停止したりした場合にアラートを設定します。
  • リーダー選出レートのスパイク： 異常に高いリーダー選出レートに対してアラートを発します。これは不安定性を示している可能性があります。

アラートツールの統合

Prometheusのセットアップは、Alertmanagerなどのアラートマネージャーと統合できます。Alertmanagerは、重複排除、グループ化、およびアラートの電子メール、Slack、PagerDutyなどのさまざまな通知チャネルへのルーティングを処理します。

  • Alertmanager設定の例（alertmanager.yml）：
    route:
  group_by: ['alertname', 'cluster', 'service']
  receiver: 'default-receiver'
  routes:
    - receiver: 'critical-ops'
      match_re:
        severity: 'critical'
      continue: true

receivers:
  - name: 'default-receiver'
    slack_configs:
      - channel: '#kafka-alerts'

  - name: 'critical-ops'
    slack_configs:
      - channel: '#kafka-critical'
    pagerduty_configs:
      - service_key: '<your-pagerduty-key>'

Kafka監視とアラートのベストプラクティス

  • ベースラインを確立する： Kafkaクラスターの通常の動作を理解します。これは、意味のあるアラートしきい値を設定し、異常を特定するのに役立ちます。
  • アラートを階層化する： 即時の対応が必要な重要なアラートと、レビューは必要だが緊急対応を必ずしも必要としない情報提供アラートを区別します。
  • アクションを自動化する： 一般的な問題（例：ディスク容量の警告）については、安全な場合に是正手順の自動化を検討します。
  • メタデータレイヤーを監視する： 古いKafkaクラスターは一般的にZooKeeperに依存していますが、新しいデプロイメントではKRaftモードを使用する場合があります。クラスターが実際に使用しているメタデータクォーラムを監視します。
  • ネットワークを監視する： ブローカーとクライアント間のネットワーク接続とレイテンシが許容範囲内であることを確認します。
  • 定期的にダッシュボードをレビューする： アラートだけに依存しないでください。監視ダッシュボードを定期的にレビューして、アラートがトリガーされる前に傾向と潜在的な問題を特定します。
  • アラートをテストする： 定期的にアラートシステムをテストして、通知が正しく送信され、適切な担当者に届いていることを確認します。

読者が行動できる症状にアラートを設定する

Kafkaは多くのメトリクスを公開しており、印象的だがインシデント時に役に立たないダッシュボードを構築するのは簡単です。明確なオペレーターアクションがあるアラートから始めましょう。

UnderReplicatedPartitions > 0は、少なくとも1つのパーティションの同期中のレプリカが予想よりも少ないことを意味するため、アクション可能です。最初のチェックはブローカーの健全性、次にディスク、ネットワーク、レプリカフェッチャーラグです。ローリング再起動中にすぐに解消される場合は、予想される範囲内かもしれません。ゼロ以外のままの場合は、耐久性と可用性のリスクとして扱います。

OfflinePartitionsCount > 0はより緊急です。アクティブなリーダーがないパーティションは、通常のプロデュースやフェッチトラフィックを処理できません。このアラートにはクラスターとブローカーのコンテキストを含め、本番クラスターではページングする必要があります。

コンシューマーラグは重要ですが、ニュアンスが必要です。10,000レコードのラグは、優先度の低い夜間バッチトピックでは無害ですが、不正検出パイプラインでは深刻です。コンシューマーグループの目的に関連してラグにアラートを設定します：持続的なラグ、コンシューマーが回復できる速度よりも速く増加するラグ、またはツールが計算できる場合の推定遅延時間。

ディスクアラートは、Kafkaに書き込む余地がなくなる前に発動する必要があります。Kafkaブローカーは設計上ディスクを大量に使用するシステムであり、ディスクがいっぱいになると連鎖的な問題を引き起こす可能性があります。ディスク使用率のアラートとログディレクトリのコンテキストを組み合わせて、オンコール担当者が問題が1つのブローカー、1つのマウント、またはクラスター全体の保持ポリシーの問題であるかを確認できるようにします。

実用的なダッシュボードレイアウト

有用なKafkaダッシュボードには通常、レイヤーがあります。最上行は、クラスターがトラフィックを処理しているかどうかを示す必要があります：ブローカー数、オフラインパーティション、アンダーレプリケーションパーティション、コントローラーの変更、リクエストレイテンシ、プロデュース/フェッチエラーレート。

次の行は、スループットとプレッシャーを示す必要があります：バイトイン、バイトアウト、プロデュースリクエスト、フェッチリクエスト、ネットワークプロセッサアイドル、リクエストハンドラアイドル、CPU、メモリ、ディスク使用率、ディスクI/O。これらのパネルは、レイテンシのスパイクが実際のリソース制約と一致しているかどうかを確認するのに役立ちます。

3行目は、レプリケーションに焦点を当てる必要があります：レプリカフェッチャーラグ、同期中レプリカの縮小/拡大イベント、リーダー選出レート、ブローカーごとのパーティション分布。1つのブローカーが他のブローカーよりもはるかに多くのリーダーまたはホットパーティションを持っている場合、クラスター全体は健全に見えても、1つのノードが過負荷になっている可能性があります。

4行目は、コンシューマーに焦点を当てる必要があります：グループとトピックごとのラグ、1秒あたりに消費されたレコード、利用可能な場合はリバランスレート、アプリケーションの計装からのコンシューマーエラーメトリクス。ブローカーメトリクスは、コンシューマーがメッセージをフェッチした後、遅いデータベース書き込み内でスタックしているかどうかを教えてくれません。

コマンドラインチェックが依然として役立つ場面

ダッシュボードがあっても、Kafkaのコマンドラインツールは、クラスターが何を信じているかを確認するのに役立ちます。

トピックのパーティション状態を確認する：

kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic orders

リーダーがないパーティション、ISRにないレプリカ、または不均等なリーダー配置を探します。

コンシューマーラグを確認する：

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --describe \
  --group billing-worker

出力は、「グループ全体が遅れている」のか「1つのパーティションがスタックしている」のかを区別するのに役立ちます。1つのパーティションがスタックしている場合、多くの場合、ポイズンメッセージ、ホットキー、または健全でない単一のコンシューマーインスタンスを指しています。

クライアントの動作がおかしい場合にブローカーのAPIバージョンを確認する：

kafka-broker-api-versions.sh --bootstrap-server broker1:9092

バージョンの不一致は、ヘルスインシデントの最も一般的な原因ではありませんが、アップグレードや混合バージョンのロールアウト後のクライアントの動作を説明できます。

ノイズの多いKafkaアラートを避ける

ノイズの多いアラートは、通常、別のクラスターからコピーされたしきい値から発生します。Kafkaのワークロードは、普遍的な数値にはあまりにも多様です。支払いストリーム、メトリクスのファイアホース、バッチインポートトピックでは、レイテンシ許容度、スループット、パーティション数、保持期間の期待値が異なります。

自然にスパイクする可能性のあるアラートには、持続的なウィンドウを使用します。たとえば、コンシューマーラグは、ページングする前に数分間しきい値を超えている必要があるかもしれません。本番環境のアンダーレプリケーションパーティションは、より短いウィンドウに値するかもしれません。ブローカーダウンアラートは計画メンテナンスを考慮する必要がありますが、実際の障害が見逃されるほど積極的に非表示にすべきではありません。

すべてのページには、可能性の高い所有者がいる必要があります。ブローカーのディスク満杯は、プラットフォームまたは運用チームに属します。billing-workerのコンシューマーラグは、アプリケーションチームに属する場合があります。すべてのKafkaアラートが所有権なしに1つのチャネルにルーティングされる場合、人々はそれらを無視することを学びます。

メタデータレイヤーとバージョンのニュアンス

多くの既存のKafkaクラスターは依然としてZooKeeperを使用しており、これらのクラスターはZooKeeperの監視が必要です：クォーラムの健全性、レイテンシ、ディスク、JVMの健全性、接続数。KRaftモードを使用するKafkaクラスターは、代わりにコントローラークォーラムの監視が必要です。運用上の考え方は同じです：メタデータレイヤーが健全でない場合、ブローカーの健全性は最初は無関係に見える方法で低下する可能性があります。

すべてのKafkaクラスターがZooKeeperに依存しているという古いガイダンスに注意してください。それは長年にわたって真実でしたが、新しいKafkaデプロイメントはそれを使用しない場合があります。ランブックは、実際に実行しているクラスターと一致する必要があります。

ランブックは完璧なダッシュボードよりも重要

ランブックのないアラートは、オンコール担当者を推測に任せます。重要なアラートごとに、最初のチェック、一般的な原因、エスカレーションパスを記述します。アンダーレプリケーションパーティションの場合、ランブックには次のように書かれているかもしれません：ブローカーの到達可能性を確認し、ディスク使用率を検査し、ネットワークエラーを検査し、最近のデプロイまたは再起動を確認し、影響を受けるトピックを特定し、メンテナンスを一時停止するかどうかを決定します。

コンシューマーラグの場合、ランブックには次のように書かれているかもしれません：ラグがすべてのパーティションか1つのパーティションかを特定し、コンシューマーのデプロイメントの健全性を確認し、最近のアプリケーションエラーを確認し、ダウンストリームの依存関係を検査し、リバランスを探します。単一のパーティションがスタックしている場合は、現在のオフセットを見つけ、オフセットを盲目的にスキップするのではなく、内部ツールを使用してメッセージを安全に検査します。

優れた監視はインシデントを排除しません。最初のいくつかの決定をより速く、より感情的にしないものにします。

Kafkaの健全性監視は、すべてのメトリクスが運用上の質問に接続されている場合に機能します。パーティションは利用可能ですか？レプリカは追いついていますか？コンシューマーはペースを維持していますか？ブローカーはリソースを使い果たしていますか？コントローラーまたはメタデータサービスは安定していますか？これらの質問を中心にダッシュボードとアラートを構築し、しきい値を他の誰かのデフォルトではなく、自分のワークロードに結び付けてください。