Part 4-1. アラートルール基礎
概要
Part 4 で学んだアラーティング全体像をもとに、このセクションでは Prometheus がアラート条件をどう定義するかを詳しく解説します。アラートルール(alert rule)は、メトリクス値の異常を検知して通知を発火させるための中核となります。
ルール定義には4つの要素があります:expr(判定式)、for(判定期間)、labels(ラベル)、annotations(説明)です。これらを適切に組み合わせることで、本番環境に適切なアラート精度が実現できます。
ルールファイルの基本構造
Prometheus のアラートルールは YAML ファイルで定義します。groups(ルールグループ)の配列構造で、複数のアラート定義を組織化します。
groups:
- name: system-alerts
interval: 1m
rules:
- alert: HighCPU
expr: cpu_usage_percent > 80
for: 5m
labels:
severity: critical
annotations:
summary: "CPU usage is high"groups はアラートルール群を管理する単位です。グループごとに異なる評価間隔を指定でき、例えば「システムリソース関連」「アプリケーション関連」「ビジネス指標関連」といった分類が可能です。
interval で評価周期を指定します。デフォルトは1分で、15s、1m、5m など Prometheus の期間表記で記述します。短い間隔ほど検知が素早い反面、Prometheus の CPU 使用率が上がります。本番環境では 1~5 分が一般的です。
アラートルール定義の4要素
expr:メトリクス条件式
PromQL で異常条件を定義します。Part 3-2 で学んだ PromQL 知識をそのまま活用できます。
cpu_usage_percent > 80
rate(http_errors_total[5m]) > 1
disk_free_gb < 2for:判定持続時間
メトリクスが閾値超過の状態を「何分間続いたら alert を発火させるか」を指定します。
for: 5mCPU が 80% を一瞬超えるだけではアラートにせず、5 分以上持続した異常状態のみを検知する設定です。ノイズを減らし、実際の問題を正確に検知するために重要です。
labels:ラベル付与
アラート発火時に付与する属性情報です。Part 4-2 の AlertManager で「このラベル値の場合は Slack へ」といった振り分けに使われます。
labels:
severity: critical
resource_type: computeannotations:人間向け説明
通知メッセージに含まれる概要(summary)と詳細(description)を定義します。メトリクスの具体的な値を通知に埋め込むための変数機能も使えます。
annotations:
summary: "High CPU detected"
description: "CPU usage exceeds 80% for 5 minutes"PromQL での条件判定パターン
単純な閾値判定
最もよく使う形式です。
cpu_usage_percent > 80
memory_free_gb < 2
disk_usage_percent >= 90増加率での判定
Counter 型メトリクスの増加速度を判定します。エラー率、スループット、トラフィック量などに適しています。
rate(http_errors_total[5m]) > 1
increase(disk_used_bytes[1h]) > 10*1024*1024*1024複合条件
AND・OR で複数の条件を結合します。
(cpu_usage_percent > 80) and (memory_usage_percent > 90)
(error_rate > 5) or (response_time > 2)実装例:よく使う3パターン
システムリソース監視
CPU・メモリ・ディスク使用率が基本です。
rules:
- alert: HighCPU
expr: cpu_usage_percent > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU detected"
- alert: LowDiskSpace
expr: disk_free_percent < 10
for: 10m
labels:
severity: critical
annotations:
summary: "Disk space below 10%"アプリケーション監視
エラー率やレスポンスタイムです。
- alert: HighErrorRate
expr: rate(http_errors_total[5m]) > 0.05
for: 3m
labels:
severity: warning
annotations:
summary: "Error rate exceeds 5%"
- alert: SlowResponse
expr: histogram_quantile(0.95, http_request_duration_seconds) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "P95 latency above 2s"サービス可用性
ターゲットの UP/DOWN です。
- alert: TargetDown
expr: up == 0
for: 2m
labels:
severity: critical
annotations:
summary: "Target is down"ルール設定のポイント
for の値を適切に:短すぎるとノイズが増え、長すぎると対応が遅れます。リソースは 3~5 分、アプリケーションエラーは 2~3 分が目安です。
labels の命名統一:severity(critical / warning / info)、resource_type、service など、チーム全体で統一することで AlertManager での処理が簡潔になります。
PromQL の効率化:複雑なクエリはパフォーマンスに影響します。記録ルール(recording rules)であらかじめ計算結果を保存することも検討します。
前のセクション: Part 4 - 監視からアラート通知へ
次のセクション: Part 4-2 - AlertManager設定実践