Contents
Prometheusアラートルールの概要と目的
Prometheusはメトリクス収集と異常検知を分離して運用可能な監視ツールです。「いつ」「どの場所で」「どのような状態が発生したか」を明確に定義するアラートルールによって、システムの安定性を維持します。この記事では、アラートルールの作成手順と実装例、レコーディングルールとの違いなどについて解説します。
監視の重要性
ITインフラやアプリケーションの停止はビジネスにも深刻な影響を与えます。事前に異常を検知し、通知・対応を自動化する仕組みが求められます。Prometheusではメトリクス収集とアラート判断を分離して運用でき、柔軟性の高い監視体系を構築できます。
アラートルールの役割
アラートルールは、レコーディングルール（メトリクスの加工）と異なり、条件に合致した場合のみ通知を行う仕組みです。例えば「CPU使用率が80%を超えたとき」を条件にし、Alertmanagerを通じてメールやSlackで通知するように設定します。
YAMLファイルの基本構造と作成手順
アラートルールはrules.yamlというYAMLファイルで定義され、Prometheus Serverに読み込まれます。正しく配置・記述することで、監視範囲を拡張できます。
ファイル配置場所の確認
Prometheus Serverの設定ファイル（prometheus.yml）でrule_filesに指定する必要があります。通常は/etc/prometheus/rules/ディレクトリ内に配置します。
ファイル名は任意ですが、
node_*.yamlやapp_*.yamlなど用途に応じた命名規則を整えると管理が楽になります。
例: prometheus.ymlへの記述
|
1 2 3 4 |
rule_files: - "rules/node_rules.yaml" - "rules/app_rules.yaml" |
rule_filesの設定方法
複数のルールファイルをまとめることで、管理がしやすくなります。たとえば、ノード監視用とアプリケーション監視用に分離するなど、目的ごとにファイルを分割するのがベストプラクティスです。
アラート条件式の書き方とレコーディングルールとの違い
アラートルールではexprフィールドでPromQLによる評価条件を記述します。レコーディングルール（record）との使い分けに注意が必要です。
アラートルール vs レコーディングルールの比較
| 項目 | アラートルール | レコーディングルール |
|---|---|---|
| 目的 | 条件を満たしたときのみ通知 | メトリクスに加工を施す（例：合計値の計算） |
| 動作タイミング | 常時評価 | 定期的に評価される |
| 使用場面の例 | CPU使用率が80%を超えたとき通知 | 同じジョブのメトリクスを統一する名称で再定義 |
レコーディングルールは、アラートルールと混同されやすいですが、メトリクスの加工目的でのみ使用します。条件式が評価結果に影響しない限りは、レコーディングルールをアラートルールとして誤って利用しないように注意してください。
exprフィールドの基本構文
exprは「何が異常か」を判定する式です。例えば、ノードの負荷を監視する場合：
|
1 2 |
expr: (node_load1{job="node"} > 0.8) |
- 比較演算子（
>や<など）を使用 andやorで複数条件を組み合わせることも可能
Alertmanager連携設定の具体例
Alertmanagerは、Prometheusが検出したアラートを通知するためのツールです。prometheus.ymlに設定情報を記述します。
基本的なroute定義
Alertmanagerは、ルーティング規則でアラートを振り分ける仕組みを持っています。
例: すべてのアラートをSlackに通知する設定（公式ドキュメント参照）
|
1 2 3 4 |
route: receiver: 'slack-notifications' group_by: ['job'] |
詳細なAlertmanagerの設定については、Prometheus公式ドキュメントを参照してください。
アラートラベルによるフィルタリング
matchやmatch_reでラベルを指定し、特定のアラートのみ処理させることも可能です。
例: jobが"node"以外のアラートは無視
|
1 2 3 4 5 |
- match: job: "app" match_re: severity: "critical|warning" |
ノード負荷監視アラートの実装例
Prometheusのノード監視にはnode_load1メトリクスを活用します。具体的なアラートルールを紹介します。
node_load1メトリクスの確認
node_load1は、1分間平均負荷を表すメトリクスです。ノードが過負荷になる前に検知できるよう、しきい値を設定します。
PromQLで確認する例:
|
1 2 |
node_load1{job="node"} |
しきい値設定のベストプラクティス
| 条件 | しきい値 | 説明 |
|---|---|---|
| 高負荷の警告 | > 0.8 | ノードが過負荷になる前の段階で通知 |
| 緊急事態の検知 | > 1.5 | システム全体に影響を及ぼしそうな場合 |
アラートテストとトラブルシューティング
アラートルールを実装後は、動作確認が必須です。ダミー値注入やメトリクスのログチェックなどで問題点を探します。
テスト用のダミー値注入
/api/v1/queryエンドポイントを使って、テストデータを注入できます。
例: curlコマンドでダミー値を注入（疑似環境）
|
1 2 |
curl -X POST http://localhost:9090/api/v1/query --data-urlencode 'query={__name__="node_load1"} + 2' |
アラートログの確認手順
rule_evaluation_time_secondsというメトリクスを監視することで、アラートルールの評価状況がわかります。
PromQLで確認:
|
1 2 |
rule_evaluation_time_seconds{job="prometheus"} |
よくあるエラーの解決策
| 状況 | 対処法 |
|---|---|
| アラートが発火しない | exprフィールドの条件式を確認。メトリクス名に誤りがないか。 |
| ファイル読み込みエラー | rule_files設定とYAMLファイルの場所を再確認。権限もチェック。 |
| Alertmanagerへの通知失敗 | URLが正しいか、APIトークンが正しく設定されているかを確認する。 |
まとめ
本記事では、Prometheusアラートルールの作成手順と実装例についてステップバイステップで解説しました。
- YAMLファイルの基本構造と配置場所を理解し、
exprフィールドで条件式を記述する方法 - Alertmanagerとの連携設定やノード負荷監視アラートの具体例
- アラートテストとトラブルシューティングの手順
これらの知識を活用することで、安定した監視体制を構築できます。さらに詳しい設定例やメトリクス一覧については、以下のリンクから公式ドキュメントをご確認ください。