Contents
Prometheusアラートルールの基本構造と設計の考え方
Prometheusを活用する際、アラートルールの作成は安定した運用に不可欠です。しかし「exprの書き方がよくわからない」「レコルダブルの役割がよく理解できない」といった悩みを持つDevOpsエンジニアやシステム管理者は少なくありません。本記事では、ステップバイステップでアラートルールを設計する方法と、実務で使える例を解説します。
レコルダブル・エクスプレッション・ラベルの役割
アラートルールの基本構造には3つの必須要素があります。
| 項目 | 役割 |
|---|---|
| record | アラートが記録されるレコード名（例: alert:HighCPUUsage） |
| expr | Prometheusクエリ（PromQL）で定義された条件式 |
| labels | エラーの追跡に使用するメタデータ（例: severity:warning、instance:app1） |
特にrecordはアラートを管理するために重要です。例えば、alert:HighCPUUsageという名前で記録することで、後の通知や監視がスムーズになります。また、labelsには「どのサーバー」「どのような問題」かを示す情報を入れることで、トラブルシューティングの効率化につながります。
シンプルなアラートルールの例で構文を理解する
以下は、CPU使用率が90%を超えた場合にアラートを発火させる基本的な例です。
|
1 2 3 4 5 |
- record: alert:HighCPUUsage expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90 labels: severity: warning |
この例では、exprにPromQLで定義したCPU使用率の計算式が入り、90%を超えた場合にアラートを生成します。また、「severity」というラベルで警戒レベルを示しています。このように、基本構造を理解することで、他のアラートルールも同様の手順で作成できます。
実務で活用する代表的なアラートケース
DevOps現場では「CPU使用率が90%を超えた」「ディスク容量が80%を超えている」といった異常を監視し、迅速な対応が必要です。以下に、こうした実務シーンで使えるアラートルールの例とその設計方法を解説します。
CPU使用率90%を超えた場合のアラート
CPU負荷が高くなると、アプリケーションのレスポンス遅延やサービス停止のリスクが高まります。このケースでは、5分間平均して90%以上になることを条件にアラートを発火させます。
|
1 2 3 4 5 6 |
- record: alert:HighCPUUsage expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90 for: 5m labels: severity: warning |
for: 5m：条件が5分間維持された場合にアラートを発火（一時的なピークだけでは通知しない）severity: warning：重要度を指定（warning、criticalなど）
このようにしきい値と継続時間を設定することで、過剰なアラートの発生を防ぐことができます。
ディスク容量80%超過時の通知設定
ディスク容量が満たされると、データ書き込みが失敗したり、クラッシュする可能性があります。このケースでは、80%を超えると即座にアラートを発火させるようにします。
|
1 2 3 4 5 |
- record: alert:DiskUsageHigh expr: (node_disk_used_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} / node_disk_total_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} * 100) > 80 labels: severity: critical |
critical：このアラートは即時対応が必要な緊急性を示す
また、複数のディスクデバイスについて同時に監視したい場合は、group by (device)やunlessなどのPromQLでフィルタリングを行うことで、不要なアラートを抑制できます。
アラートグループ化と通知チャネルの設定ポイント
アラートルールを作成するだけでは、過剰にアラートが送られたり、同様の問題に対して複数回通知されたりする可能性があります。そこでアラートのグループ化と通知経路（Slackやメールなど）への設定を工夫することが重要です。
複数メトリクスを1つのアラートに集約する方法
たとえば、CPU使用率とディスク容量が同時に異常になった場合、それぞれのアラートルールで通知されることがあります。これを防ぐには、groupsやexprで複数の条件をまとめたアラートを作成します。
|
1 2 3 |
- record: alert:ServerOverload expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90 or (node_disk_used_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} / node_disk_total_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} * 100) > 80 |
or：CPUまたはディスクのいずれかが異常ならアラートを発火
このように複数のメトリクスを1つのルールで管理できると、通知の負荷が減ります。
Slack/メールなどへの通知経路構成
アラートはただ作るだけでなく、実際の通知が届くようにする必要があります。これはAlertmanager（Prometheusの通知用ツール）と連携して設定します。
- Prometheus側でアラートルールを定義し、
labelsに通知先を指定 - AlertmanagerにSlackやメールなどの通知先を登録
- アラートが発火すると、Alertmanagerから通知される
このようにすることで、1つのエラーに対して複数の通知経路（Slack + メール）で同時に送信するなど、柔軟な設定が可能です。
ルールファイルの作成・テスト方法
アラートルールをYAML形式で定義し、Prometheusに読み込ませる必要があります。また、そのルールファイルが正しく動作するか確認するために事前テストが必要です。
YAML形式のルールファイル構成例
以下は、複数のアラートルールを含むルールファイルの例です：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
groups: - name: node-alerts rules: - record: alert:HighCPUUsage expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90 for: 5m labels: severity: warning - record: alert:DiskUsageHigh expr: (node_disk_used_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} / node_disk_total_bytes{device!~"tmpfs|dm-(?:mpath|raid)"} * 100) > 80 labels: severity: critical |
このファイルはprometheus.ymlに以下のように読み込みます：
|
1 2 3 |
rule_files: - "node_alerts.yml" |
Prometheus公式ツールでの事前テスト手順
ルールを作成した後、PrometheusのRule Evaluation Time（評価時間）を確認し、正しく動作するかテストしましょう。手順は以下の通りです：
- UIで「Status」→「Rules」にアクセス
- ルールが表示されていることを確認
- 各ルールに対して「Evaluate Now」を選択して即時評価
- 結果を確認し、アラートが正しく発火しているかを検証
このようにして事前にテストすることで、運用中に問題が起こるリスクを回避できます。
自社環境に応じたアラートルールテンプレートダウンロード
アラートルールの設計は、自社のインフラやアプリケーションの特性により異なります。例えば、Webサーバーとデータベースサーバーでは、監視対象となるメトリクスが異なるため、テンプレートをカスタマイズして使用することが推奨されます。
利用できるテンプレート例
- アプリケーションサーバー向けのアラートルール
- CPU使用率（しきい値90%）
-
メモリ使用量（しきい値85%）
-
データベースサーバー向けのアラートルール
- ストレージ使用率（しきい値75%）
-
DB接続数が上限に達するときのアラート
-
Linuxサーバー向けのアラートルール
- ディスク容量（しきい値80%）
- CPU温度異常検知
カスタマイズと最適化のポイント
テンプレートを導入する際は、以下のような点に注意してください：
- 自社環境で実際に使われているメトリクスに合わせてアラートルールを修正
- 既存の監視ツール（ZabbixやNagiosなど）との連携設定も考慮
- サーバーごとに異なるしきい値を設定する場合、
instanceでフィルタリング
テンプレートダウンロードはこちら
自社環境に最適なアラートルールテンプレートは以下からDL可能です。既存のルールをカスタマイズする際は、メトリクス名としきい値を確認し、必要に応じてPromQLを調整してください。
※ダウンロードリンクはこちら（※仮リンク）
- アラートルールテンプレートDLページ