Prometheus アラート設定：高 CPU 負荷アラートの作成とテスト

はじめに

効果的なモニタリングとは、単にメトリクスを収集することだけではありません。問題が発生したときに通知を受け取ることです。Prometheus には強力な組み込みのアラートシステムがあり、グラフ作成に使用するのと同じ PromQL クエリ言語を使用してアラート条件を定義できます。アラートの条件が満たされると、そのアラートは「発火中 (firing)」状態になります。

この実験 (Lab) では、Prometheus のアラートの基本を学びます。Prometheus と Node Exporter が実行されている事前設定済みの環境から開始します。あなたのタスクは、個別のアラートルールファイルを作成し、高い CPU 使用率を検出するルールを定義し、Prometheus がこのファイルをロードするように設定し、最後に高い CPU 負荷をシミュレートして、Prometheus UI でアラートがトリガーされるのを確認することです。

アラート環境の理解

このステップでは、実験 (Lab) 環境に慣れてもらいます。セットアップスクリプトによって、Prometheus 用と Node Exporter 用の 2 つの Docker コンテナがすでに起動されています。

まず、両方のコンテナが実行中であることを確認しましょう。ターミナルを開き、docker psコマンドを実行します。

docker ps

以下のような出力が表示され、prometheusコンテナとnode-exporterコンテナが「Up」状態になっているはずです。

CONTAINER ID   IMAGE                           COMMAND                  CREATED          STATUS          PORTS                                       NAMES
...            prom/prometheus                 "/bin/prometheus --c…"   15 seconds ago   Up 14 seconds   0.0.0.0:9090->9090/tcp, :::9090->9090/tcp   prometheus
...            prom/node-exporter               "/bin/node_exporter …"   16 seconds ago   Up 15 seconds   0.0.0.0:9100->9100/tcp, :::9100->9100/tcp   node-exporter

node-exporterコンテナはホストシステム（この実験 VM）に関するメトリクスを公開しており、prometheusコンテナはこのメトリクスをスクレイピング（収集）するように設定されています。

次に、Prometheus UI を確認してみましょう。アクセスするには：

LabEx インターフェースで、上部ナビゲーションバーの + (新規タブ) ボタンをクリックします。
ドロップダウンメニューから Web Service を選択します。
ポート番号として 9090 を入力します。
Open をクリックして、Prometheus の Web インターフェースを起動します。

新しいタブが開いたら、Prometheus の Expression Browser のランディングページが表示されるはずです。上部ナビゲーションメニューから Status -> Targets に移動してください。node_exporterジョブが緑色の「UP」状態になっていることを確認し、Prometheus が正常にデータ収集を行っていることを確認します。この接続が、私たちのアラートルールの基盤となります。

Prometheus Targets UI

高 CPU 負荷アラートのための alert-rules.yml の作成

このステップでは、アラートルール専用のファイルを作成します。ルールをメインの Prometheus 設定ファイルから分離することは、整理の観点からベストプラクティスとされています。

プロジェクトディレクトリ内にalert-rules.ymlという名前のファイルを作成します。nanoエディタを使用してファイルを作成・編集します。

nano ~/project/alert-rules.yml

次に、以下の YAML コンテンツをnanoエディタにコピー＆ペーストします。これは、CPU 使用率が高い場合にトリガーされる単一のアラートを含むルールグループを定義します。

groups:
  - name: node_alerts
    rules:
      - alert: HighCpuLoad
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 10
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "High CPU load on {{ $labels.instance }}"
          description: "CPU load is > 10% (current value: {{ $value }}%)"

このルールについて詳しく見てみましょう。

groups: ルールはグループに編成されます。グループ内のすべてのルールは順番に評価されます。
alert: 私たちのアラートの名前、HighCpuLoadです。
expr: 評価される PromQL 式です。これが値を返すと、アラートがトリガーされます。ここでは、過去 1 分間の非アイドル CPU 時間の割合を計算しています。それが 10% より大きい場合、条件が満たされます。
for: この句は、アラートが「発火中 (Firing)」になる前に、条件が継続的な期間（1 分間）真でなければならないことを指定します。これにより、一時的なスパイクによるアラートの誤発動を防ぎます。
annotations: これらはアラートに人間が読める情報（注釈）を追加します。summaryとdescriptionは標準的な注釈です。アラートメッセージに動的なデータを含めるために、{{ $labels.instance }}や{{ $value }}のようなテンプレート変数を使用できます。

内容を貼り付けた後、Ctrl+X、次にY、そしてEnterを押してファイルを保存し、nanoを終了します。

ルールファイルをマウントして Prometheus コンテナを実行する

このステップでは、Prometheus に新しいルールファイルをロードさせ、更新された設定でコンテナを再起動するように指示します。

まず、ルールファイルへの参照を含めるために、メインの設定ファイルであるprometheus.ymlを編集する必要があります。nanoで開きます。

nano ~/project/prometheus.yml

globalセクションの下にrule_filesディレクティブを追加します。変更後のファイルは次のようになります。

global:
  scrape_interval: 15s
  rule_files:
    - "alert-rules.yml"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["prometheus:9090"]
  - job_name: "node_exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

ファイルを保存し、nanoを終了します（Ctrl+X、Y、Enter）。

設定が更新されたので、変更を適用するために Prometheus コンテナを再起動する必要があります。まず、古いコンテナを停止して削除します。

docker stop prometheus

docker rm prometheus

最後に、新しい Prometheus コンテナを実行します。このコマンドはセットアップスクリプトのものと似ていますが、2 つ目の-vフラグが含まれており、alert-rules.ymlファイルをコンテナ内にマウントします。

docker run -d --name prometheus -p 9090:9090 \
  --network monitoring \
  -v /home/labex/project/prometheus.yml:/etc/prometheus/prometheus.yml \
  -v /home/labex/project/alert-rules.yml:/etc/prometheus/alert-rules.yml \
  prom/prometheus

このコマンドにより、メイン設定とアラートルールの両方が Prometheus コンテナ内で利用可能になります。

Prometheus UI でアラートルールがロードされたことを確認する

このステップでは、Prometheus が新しいアラートルールを正常にロードしたことを確認します。

ブラウザで Prometheus UI タブに戻るか（必要であればポート 9090 で新しい Web サービスタブを開きます）、ページがロードされない場合は、新しいコンテナが起動するまで数秒待ってからページを更新してください。

上部のナビゲーションバーから、Alertsメニュー項目をクリックします。

ここで、HighCpuLoadアラートがリストに表示されているはずです。アラートはInactiveセクションにあり、緑色の背景で示されます。これは予期された状態です。なぜなら、システム上の CPU 負荷が現在低いため、アラートの式（expr）が偽（false）と評価されているからです。

Prometheus Inactive Alert

アラートの 3 つの状態を理解することが重要です。

Inactive (緑): アラート条件が偽（false）です。
Pending (黄): アラート条件は真（true）になりましたが、forの継続時間がまだ経過していません。Prometheus は条件が持続するかどうかを待っています。
Firing (赤): アラート条件がforの継続時間全体にわたって真（true）でした。本番環境のセットアップでは、この時点で Prometheus は Alertmanager にアラートを送信します。

現在、あなたのアラートは Inactive であり、これは正しい状態です。次のステップでは、これを発火（Firing）させます。

アラート発報をテストするための負荷をシミュレーションする

この最終ステップでは、アラートが正しく発火するかどうかをテストするために、意図的にシステム上の CPU 負荷を増やします。

単純な無限シェルループを使用して CPU 負荷を生成できます。ターミナルで次のコマンドを実行します。末尾の&はプロセスをバックグラウンドで実行するため、ターミナルを使い続けることができます。

while true; do true; done &

このコマンドは、単一の CPU コアを 100% 消費するプロセスを開始します。次に、Prometheus UI のAlertsページ（ポート 9090 の Web サービスタブからアクセス可能）に素早く戻ります。

HighCpuLoadアラートの状態が変化するのを確認できるはずです。

約 15〜30 秒以内に、アラートの式が真（true）になります。アラートはPendingセクションに移動し、黄色に変わります。これは、Prometheus が高 CPU 負荷を検出しましたが、for句で指定された1mの継続時間を待っていることを意味します。
Pending 状態で 1 分経過した後、アラートはFiringセクションに移動し、赤色に変わります。これにより、アラートルールが期待どおりに機能していることが確認できました！アラートを展開すると、定義したアノテーションが現在の値とともに表示されます。

Prometheus Firing Alert

アラートが発火したのを確認したら、負荷生成を停止できます。ターミナルに戻り、次のコマンドを実行してバックグラウンドのループプロセスを終了します。

重要： LabEx VM サーバーのリソースを節約するため、必ず次のコマンドを実行して負荷生成を停止してください。

kill $!

負荷を停止した後、Prometheus UI を再度監視します。アラートはすぐにInactive（緑色）の状態に戻り、テストサイクルが完了します。

まとめ

おめでとうございます！Prometheus のアラートの設定とテストに成功しました。

この実験（Lab）では、以下の方法を学びました。

アラートルールを別個の YAML ファイルに構造化する方法。
高 CPU 使用率のアラート条件を定義するための PromQL 式を作成する方法。
アノテーションを使用して、意味があり人間が読めるアラートメッセージを作成する方法。
Prometheus がルールファイルをロードするように設定し、変更を適用するために再起動する方法。
Prometheus UI で、アラートが Inactive から Pending、そして Firing へと変化するライフサイクルを観察する方法。
アラートを発火・テストするために条件をシミュレートする方法。

これはアラート設定の半分に相当します。この実験の範囲外となる次の論理的なステップは、Alertmanager インスタンスを設定することです。Prometheus は発火したアラートを Alertmanager に送信し、Alertmanager が重複排除、グループ化、そしてメール、Slack、PagerDuty などの実際の通知チャネルへのルーティングを担当します。