概要 ​

Part 4-1・4-2 で Prometheus のアラートルール定義と AlertManager のルーティング設定を学びました。ここからは「3 つのコンポーネントが一体となった統合運用」という実務の段階に進みます。

本番環境でアラートシステムを実際に運用するには、設定知識だけでは不十分です。アラート疲れ（alert fatigue）という実務課題への対策、Grafana との連携、テスト・検証、ドキュメント化といった実践的なテクニックが求められます。

統合アーキテクチャのデータフロー ​

3 つのコンポーネントがどのように連動するかを確認しましょう。

Prometheus はメトリクスを定期的に収集し、alerting_rules に基づいて alert を判定します。alert が Firing 状態に達すると HTTP POST で AlertManager に送信されます。

AlertManager はそのアラートを受け取り、ルーティングルール（route）に基づいて通知先（receiver）を決定します。同時にグループ化・重複排除・通知スケジューリングを行い、運用チームが実際に「受け取る」通知のタイミングと形式を制御します。

Grafana は Prometheus をデータソースとして参照し、メトリクスをダッシュボードで可視化します。同時に、Prometheus alerting_rules で定義したアラートの状態をダッシュボード上に表示し、アラート履歴も記録します。

アラート疲れ（Alert Fatigue）と対策 ​

実務運用で最も困る問題が「アラート疲れ」です。これは、過剰なアラート通知によって運用チームが麻痺し、本来対応すべき重大な問題を見落とす現象です。

アラート疲れの原因 ​

「アラートを多く定義すれば問題を見落とさない」という誤解から、数百件のアラートが組織内に蓄積されることがあります。しかし、1 日に数百件のアラートを受け取れば、運用チームは重要度の判断ができなくなります。

また、不正確な閾値設定によって、正常な状態でも頻繁にアラートが発火することも大きな要因です。例えば、CPU 80% を超えたら alert というルールでも、バッチ処理の夜間実行で毎晩 CPU が 90% に達するなら、そのアラートに価値はありません。

対策：必要なアラートの厳選 ​

実務的な対策の第一歩は「本当に対応が必要なアラートだけを残す」という厳選です。本番環境のアラート数は「1 日あたり数十件」程度に抑えるべきです。

判定基準は「実際に人間が対応する必要があるか」です。対応できないアラートは定義する価値がありません。運用を開始したら、定期的に「実際に対応したアラートの件数」「無視されたアラートの件数」を分析し、ルール設計を継続的に改善することをお勧めします。

Silence 機能による一時的な抑止 ​

AlertManager の silence 機能は、特定のラベル条件に合致するアラートを一定期間、通知から除外する機能です。これは「アラートルール自体を無効化する」のではなく「通知を抑止する」という限定的な操作です。

Silence は計画的なメンテナンスやデプロイ時に活用します。例えば、テスト環境で誤検知が多い場合、「テスト期間中は warning 以下のアラートを抑止」といった設定ができます。

AlertManager の Web UI（デフォルトで http://alertmanager:9093）から silence を設定できます。「Silence」ボタンをクリックし、ラベル条件と期間を指定します。

Inhibition ルールによる条件付き抑止 ​

Inhibition（保留）は、特定のアラートが Firing 状態にある場合、他のアラートを自動的に抑止する機能です。これはアラート間の依存関係を管理するうえで有効です。

例えば、「サーバーがダウンしている」という critical アラートが出ている場合、「CPU が高い」「メモリが足りない」といった warning アラートを自動的に抑止する設計ができます。なぜなら、サーバーがダウンしていれば、CPU やメモリの詳細は無関係になるからです。

inhibition は alertmanager.yml で定義します。

yaml
inhibit_rules:
  - source_match:
      severity: critical
      alert_type: infrastructure
    target_match:
      severity: warning
    equal:
      - instance

この例では、「severity が critical で alert_type が infrastructure」というアラートが Firing 状態にあるとき、同じ instance の「severity が warning」のアラートを抑止します。これにより、重大な問題が発生している際の関連する警告を自動的に非表示にし、運用チームの焦点を絞ることができます。

Grafana との統合 ​

Grafana は Prometheus のデータを可視化するだけでなく、独立したアラート生成・通知機能も備えています。ここで重要なのは「役割分担の理解」です。

Prometheus alerting_rules がメインの役割 ​

実務では、Prometheus の alerting_rules がアラート検知の中心的な役割を担うべきです。Prometheus は「メトリクス評価の専門家」であり、複雑な PromQL 条件を処理できるため、柔軟で正確なアラート定義ができるからです。

また、AlertManager による集約・グループ化・抑止といった運用機能も、Prometheus alerting_rules と組み合わせることで初めて真の力を発揮します。

Grafana alerting の補助的な役割 ​

Grafana alerting は補助的な役割として活用できます。具体的には以下のようなケースが考えられます。

  • ダッシュボード独立判定: ダッシュボード上の特定のパネルにのみ関連する判定
  • 可視化と連動した判定: ダッシュボード内で複数のパネルの組み合わせに基づいて判定を行うケース
  • 権限管理を活用した分散運用: チームごとに異なるダッシュボード上で異なるアラートを管理するケース

通常は Prometheus alerting_rules をメインとし、Grafana alerting は補助的に使うという方針をお勧めします。

ダッシュボード上でのアラート状態表示 ​

Grafana では、Prometheus alerting_rules で定義したアラートの状態をダッシュボード上に表示できます。設定は比較的シンプルです。

ダッシュボードパネルのクエリに、alerting_rules で定義したアラート名を参照する設定を加えるだけで、alert の Firing/Pending/Inactive 状態が色分けされて表示されます。これにより、ダッシュボードを見るだけで「現在どのアラートが active か」を一目で把握できます。

運用ベストプラクティス ​

ルール設計の原則を実践する ​

Part 4-1 で学んだルール設計の原則を、実運用で実践することが重要です。特に「適切な粒度」と「重複の排除」はアラート疲れを防ぐうえで不可欠です。

新しいアラートルールを追加する前に「実際にこのアラートで対応できるか」を問い直すことです。もし対応方法が曖昧であれば、そのアラートは定義すべきではありません。

ラベル戦略の一貫性確保 ​

Part 4-1・4-2 で設計したラベル戦略は、組織全体で一貫性を保つことが重要です。新しいルールを追加するたびに「このアラートにはどのラベルを付けるべきか」を判定する基準を整めておきましょう。

具体的には、以下のようなラベル定義テンプレートをドキュメント化することをお勧めします。

システムリソース系：severity（warning/critical）、resource_type（compute/memory/storage）、instance

アプリケーション系：severity（critical/warning）、service（サービス名）、alert_type（application/performance/quota）

ビジネス系：severity（info/warning）、business_unit（部門名）、impact（影響範囲）

テスト・検証方法 ​

本番環境に投入する前に、ルールが正しく機能するかを検証することは、後々のトラブル防止に不可欠です。

amtool による route 検証 ​

AlertManager には amtool というコマンドラインツールが付属しており、ルーティングルールが正しく機能するか検証できます。

bash
amtool config routes

このコマンドでルーティングツリーの全体構造を確認できます。

特定のラベルを持つアラートがどの receiver に流れるかを検証するには以下を使用します。

bash
amtool config routes --label=severity=critical --label=service=api

「severity=critical かつ service=api」というラベルを持つアラートが最終的にどの receiver に振り分けられるかを確認できます。

Prometheus の設定検証 ​

Prometheus のアラートルールをローカルで検証するには、設定チェックコマンドを使用します。

bash
prometheus --config.file=prometheus.yml --rules.files=alert-rules.yml --check-config

--check-config フラグで設定ファイルの文法をチェックできます。

実際のルール動作をテストする場合は、テスト用の小規模 Prometheus インスタンスを起動し、テストメトリクスを inject して、アラートが正しく Firing 状態に遷移するか確認することをお勧めします。

ドキュメント化の重要性 ​

運用が長くなるにつれ、「なぜこのアラートが定義されたのか」という背景が失われていきます。これを防ぐため、アラートルールにドキュメントを含めることが重要です。

最も簡潔な方法は、annotations に「runbook_url」フィールドを追加し、対応手順やルール背景をドキュメント化することです。

yaml
- alert: HighCPU
  expr: cpu_usage_percent{instance=~".*"} > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "High CPU detected"
    runbook_url: "https://wiki.example.com/runbooks/high-cpu"

runbook_url に対応手順をドキュメント化することで、アラートが発火した際、運用チームはすぐに対応方法を参照できます。

前のセクション：Part 4-2 - AlertManager設定実践

次のセクション：Part 5 - Prometheus運用の基本