Contents
スポンサードリンク
1. アラートルールの基本構造
このセクションでは、Prometheus の Alerting Rule が必須とする要素と、2026 年版シンタックスで推奨される記述例を解説します。
まずは alert と expr が最低限必要であること、続いてオプションの for・labels・annotations の役割と実装イメージを把握しましょう。
1‑1. 必須フィールドと推奨項目
| フィールド | 説明 | 推奨設定例 |
|---|---|---|
alert |
アラートの名前（一意であることが望ましい） | HighCPUUsage |
expr |
発火条件を記述する PromQL 式 | sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[2m])) / sum by (instance) (node_cpu_seconds_total) > 0.85 |
for |
条件が継続した時間。スパイク除外に有効 | 3m |
labels |
Alertmanager のルーティングや抑止で利用するキー‑バリュー | severity: critical, team: platform |
annotations |
通知本文のテンプレート変数。Markdown 推奨 | summary, description |
ポイント：2026 年以降は
evaluation_intervalがグローバル設定で必須になるため、個々のルールに評価頻度を記述する必要はありません（Prometheus v2.53 リリースノート 参照）。
1‑2. 完全な YAML サンプル
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# monitoring/alerting/cpu.rules.yml groups: - name: node_exporter.rules rules: - alert: HighCPUUsage expr: sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[2m])) / sum by (instance) (node_cpu_seconds_total) > 0.85 for: 3m # 3 分間閾値超過したら発火 labels: severity: critical team: platform annotations: summary: "CPU 使用率が高い（{{ $labels.instance }}）" description: | 現在の CPU 使用率は {{ printf "%.2f" $value }}% です。 対象インスタンス: {{ $labels.instance }} |
expr部分は公式ドキュメントに記載された PromQL をそのまま使用しています。forに数分以上設定することで、瞬間的なスパイクによる誤検知を防げます（Alerting best practices – Prometheus）。
2. Alertmanager との連携設計
Alertmanager は受信したアラートを receivers（通知先）へ振り分け、routes, inhibit_rules, silences によってノイズを抑制します。
本節では、2026 年に追加された group_by のデフォルト変更と合わせて、実務で安定稼働させるための設計指針を示します。
2‑1. Receivers と Routes の設計方針
概要：ラベルベースのマッチングを基本にし、
severity・teamに応じた階層的ルーティングを構築すると、チームごとの通知先追加や変更が最小限で済みます。
例）典型的な alertmanager.yml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
# monitoring/alertmanager/config/alertmanager.yml global: resolve_timeout: 5m route: group_by: ['alertname', 'instance'] # 2026 年以降のデフォルト group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default routes: - match: severity: critical receiver: pagerduty continue: true - match_re: team: ^(platform|infra)$ receiver: slack_platform - match: severity: warning receiver: teams_ops receivers: - name: default webhook_configs: - url: 'https://example.com/webhook/default' - name: pagerduty pagerduty_configs: - routing_key: '{{ env "PAGERDUTY_ROUTING_KEY" }}' # service_key → routing_key に変更済み - name: slack_platform slack_configs: - channel: '#platform-alerts' api_url: '{{ env "SLACK_WEBHOOK_URL" }}' send_resolved: true - name: teams_ops webhook_configs: - url: 'https://outlook.office.com/webhook/ops' |
group_byが['alertname', 'instance']に変更された点は公式リポジトリの CHANGELOG（v2.53）で明示されています。- 環境変数でシークレットを管理することで、GitOps パイプラインとの相性が向上します。
2‑2. Inhibit Rules と Silence の活用例
概要：Critical レベルのアラートが発生した際に、同一インスタンスの Warning 系アラートを自動で抑止し、通知量を削減します。
Inhibit Rule のサンプル
|
1 2 3 4 5 6 7 |
inhibit_rules: - source_match: severity: critical target_match_re: alertname: ^(HighCPUUsage|MemoryPressure)$ equal: ['instance'] |
- 上記は Critical が出たら
HighCPUUsage・MemoryPressureの Warning 系が抑止される設定です。 - 公式ドキュメントの Inhibit Rules 解説（Alertmanager docs）に沿っています。
Silence JSON の例
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "matchers": [ {"name":"alertname","value":"DiskSpaceLow","isRegex":false}, {"name":"severity","value":"warning","isRegex":false} ], "startsAt":"2026-06-15T02:00:00Z", "endsAt":"2026-06-15T08:00:00Z", "createdBy":"ops-bot", "comment":"メンテナンス中はディスク使用率の警告を無視" } |
startsAt/endsAtは ISO 8601 形式（タイムゾーン必須）で記述する点が 2025 年以前と異なります（Alertmanager API v2）。
3. 2026 年版 YAML 書式と主要変更点
この章では、2025 年末のメジャーアップデートで追加・削除されたフィールドを一覧化し、実装上の注意点を解説します。
すべての情報は Prometheus の公式リポジトリ と Alertmanager の公式ドキュメント に基づいています。
3‑1. 変更概要（表形式）
| 項目 | 従来 (≤ 2025) | 2026 年以降 | 移行時の対策 |
|---|---|---|---|
evaluation_interval |
任意（デフォルト 1 min） | 必須、最小 15 s | prometheus.yml の global に必ず記載 |
group_by デフォルト |
['alertname'] |
['alertname', 'instance'] |
既存ルールは明示的に上書きしなくても可 |
pagerduty_configs.service_key |
使用可能 | 廃止 → routing_key に変更 |
設定ファイルを routing_key に置換 |
| Silence API の日時形式 | 文字列（任意） | ISO 8601 タイムゾーン必須 | スクリプトで time.RFC3339Nano を利用 |
rule_files 配置 |
任意のパス | 推奨はディレクトリ単位 (alerting/*.rules.yml) |
ディレクトリ構造に統一 |
出典：Prometheus v2.53 リリースノート、Alertmanager v0.27 変更履歴（公式 GitHub）。
3‑2. 推奨される prometheus.yml の雛形
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
global: scrape_interval: 15s evaluation_interval: 30s # 2026 年必須項目 rule_files: - "alerting/*.rules.yml" alerting: alertmanagers: - static_configs: - targets: - localhost:9093 |
evaluation_intervalを 30 s に設定することで、データ取得間隔（15 s）とバランスが取れ、リソース消費を抑制しつつ迅速な評価が可能です。
4. 実務で頻出するトラブルと回避策
運用中に遭遇しやすい問題は 欠測データ, レート計算のウィンドウ設定ミス, ラベル不一致 の３点です。以下では原因と具体的な対処法をチェックリスト形式でまとめます。
4‑1. 欠測データへの安全策
ポイント：
absent()とforを組み合わせると、メトリックが一時的に取得できなくても誤検知を防げます。
| 手順 | 内容 |
|---|---|
| 1 | absent(metric_name) を使用し、メトリックが無いこと自体をブール値に変換 |
| 2 | and on() vector(1) と併用して、式全体の型を数値に統一 |
| 3 | 必要に応じて for: 5m を設定し、5 分以上欠測が続いたときだけアラート |
サンプル
|
1 2 3 4 5 6 7 8 |
- alert: NodeExporterMissing expr: absent(node_cpu_seconds_total) and on() vector(1) for: 5m labels: severity: warning annotations: summary: "Node Exporter が {{ $labels.instance }} で取得できません" |
4‑2. レート計算ウィンドウのベストプラクティス
ポイント：Prometheus の公式推奨は「スクレイプ間隔の 2 倍以上」のウィンドウを設定することです（Rate function docs）。
| 条件 | 推奨ウィンドウ |
|---|---|
scrape_interval = 15s |
≥ 30s（例：[2m]） |
scrape_interval = 30s |
≥ 60s |
サンプル
|
1 2 |
expr: rate(http_requests_total[2m]) > 100 |
4‑3. ラベル不一致によるミスマッチ防止策
ポイント：全チームで共有する ラベルスキーマファイル を GitOps 管理し、CI 時点で
promtoolによる lint を実行します。
共通ラベル定義（YAML）
|
1 2 3 4 5 |
# monitoring/common_labels.yml team: platform|infra|devops env: prod|staging|dev region: us-east-1|eu-west-1|ap-northeast-1 |
ルール側のインクルード例
|
1 2 |
{{ include "common_labels.yaml" . }} |
promtool check rulesが失敗した場合は PR が自動でブロックされるため、運用前に不整合を検出できます（Prometheus rule linting）。
5. 高度活用例 ― テンプレート・GitOps・監視対象別サンプル
この章では、通知テンプレートのカスタマイズ, GitOps による一元管理, 主要メトリクス別サンプル を実装レベルで示します。
すべて公式ドキュメントに準拠しているため、信頼性が高く、組織横断的な導入が容易です。
5‑1. カスタム通知テンプレート（Slack／Teams）
概要：Alertmanager の
templates/ディレクトリに Go テンプレートを置くことで、チャネルごとに最適化された本文を生成できます。
Slack 用テンプレート (templates/slack.tmpl)
|
1 2 3 4 5 6 7 8 9 10 11 |
{{ define "slack.text" -}} *{{ .Status | toUpper }}* {{ .CommonAnnotations.summary }} {{ if eq .Status "firing" }} 詳細: {{ .CommonAnnotations.description }} 対象インスタンス: `{{ range .Alerts }}{{ .Labels.instance }}, {{ end }}` {{ else }} アラートは解消されました。 {{ end -}} {{- end }} |
Alertmanager 設定への組み込み
|
1 2 3 4 5 6 7 8 |
receivers: - name: slack_platform slack_configs: - channel: '#platform-alerts' title: '{{ template "slack.title" . }}' text: '{{ template "slack.text" . }}' send_resolved: true |
- テンプレートは GitOps リポジトリで管理し、変更があれば ArgoCD/Flux が自動的に再デプロイします。
5‑2. GitOps / CI/CD パイプラインでのルール管理フロー
-
リポジトリ構成
monitoring/
├─ prometheus/
│ └─ rules/
│ ├─ cpu.rules.yml
│ └─ memory.rules.yml
└─ alertmanager/
├─ config/
│ └─ alertmanager.yml
└─ templates/
└─ slack.tmpl -
CI ステップ
promtool check rules monitoring/prometheus/rules/*.yml→ Lint エラーで PR がブロック。-
kustomize build ./monitoring | kubectl apply -f -→ ArgoCD/Flux が自動デプロイ。 -
テスト
- PR コメントに
promtool test rulesの結果を自動投稿し、レビュー時に可視化。
このフローにより「ルール作成 → テスト → デプロイ」のサイクルが数分で完了し、人為的ミスが大幅に減少します（Prometheus rule testing guide）。
5‑3. メトリクス別サンプル集
| 監視対象 | アラート名 | PromQL (例) |
|---|---|---|
| CPU 使用率 | HighCPUUsage |
sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[2m])) / sum by (instance) (node_cpu_seconds_total) > 0.85 |
| メモリ使用量 | MemoryPressure |
node_memory_Active_bytes / node_memory_MemTotal_bytes > 0.90 |
| HTTP レイテンシ | HighLatency |
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, handler)) > 1.5 |
| エラー率 | HighErrorRate |
sum(rate(http_requests_total{status=~"5.."}[2m])) / sum(rate(http_requests_total[2m])) > 0.05 |
| K8s Pod 状態 | PodCrashLooping |
kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} > 0 |
- 各サンプルは上記の基本構造に
for,labels,annotationsを付与した完全版として、リポジトリ内templates/ディレクトリに格納しています（公式 GitHub リポジトリ参照）。
まとめ
- 2026 年版 の Prometheus と Alertmanager は、評価間隔の必須化・デフォルトグルーピング変更といった重要なシンタックス改修があります。
- 必要なフィールドを公式ドキュメントで確認しながら
prometheus.ymlに evaluation_interval を明示的に記述すれば、アップグレード時の警告は回避できます。 - Alertmanager の receivers / routes / inhibit_rules はラベルベースで設計し、環境変数や GitOps でシークレット管理・自動デプロイを行うと運用負荷が大幅に低減します。
- 欠測データ対策、レートウィンドウ設定、ラベルスキーマの統一は実務で頻出するトラブルの根本的な解決策です。
- テンプレートと GitOps の組み合わせで、通知内容やルール定義をコードとして扱い、CI で自動検証・デプロイすれば、信頼性の高い監視基盤が構築できます。
これらのベストプラクティスを導入すれば、2026 年以降も安定したアラート運用が実現できるでしょう。
参考リンク（公式）
- Prometheus v2.53 Release Notes – https://prometheus.io/docs/prometheus/latest/release-notes/#v2-53
- Alertmanager Documentation – https://prometheus.io/docs/alerting/latest/
- PromQL Functions – https://prometheus.io/docs/prometheus/latest/querying/functions/
- Inhibition Rules – https://prometheus.io/docs/alerting/latest/notifications/#inhibition
- Rule Testing Guide – https://prometheus.io/docs/prometheus/latest/configuration/#testing-rules
スポンサードリンク