Contents
Grafana 統合アラートの概要と従来版との違い
Grafana 9・10 系で新たに提供された 統合（Unified）アラート は、従来の「Alerting」機能を一つの UI に集約した次世代フレームワークです。
このセクションでは、旧バージョンとの主な相違点と、運用上得られるメリットを概観します。
変更ポイントの全体像
| 項目 | Grafana 8 以下 | Grafana 9/10（統合アラート） |
|---|---|---|
| ルール作成場所 | パネル設定 → アラート | 左メニュー「Alerting」→「Rules」 |
| 通知先管理 | アラートごとに個別設定 | Notification Policies で階層的・一括管理 |
| サイレンス機能 | 手動でアラートを無効化 | Mute timing による時間帯指定サイレンス |
| データソース横断 | 制限が多く、同一パネル内に限定 | 任意のデータソースを組み合わせたクエリが可能 |
上記は、kuttsun さんが 2023 年に執筆したブログでも取り上げられています[^1]。統合アラートは「設定 → 管理 → 運用」の３フェーズを UI 一つで完結させることで、担当者の認知コストとミスリスクを大幅に削減します。
アラートルール作成ステップバイステップ
この章では、統合アラートで実際に CPU 使用率 > 80 % を検知するルールを例に、設定手順とポイントを解説します。各サブセクションは「なぜその操作が必要か」を簡潔に示した導入文から始めます。
クエリ設定とデータソース選択
アラートの根幹はメトリクス取得です。まずは対象データソースを決定し、Grafana のクエリエディタで適切なクエリを書き込みます。
- Alerting → Rules から New alert rule をクリック
- 「Rule name」に CPU 使用率 > 80 % と入力し、対象パネルを選択（必要に応じて直接クエリ作成）
- Data source に CloudWatch／Prometheus／PostgreSQL 等、監視対象に合わせたデータソースを指定
データソースごとに使用できるクエリ言語が異なる点に注意してください。
クエリ例（PostgreSQL）
|
1 2 3 4 5 6 |
SELECT avg("cpu_usage_percent") FROM "metrics" WHERE $__timeFilter GROUP BY time($__interval) fill(null) |
このように、Grafana が提供するマクロ $__timeFilter と $__interval を活用すると、時間範囲と集計粒度が自動的に調整されます。
閾値条件と保持期間（duration）の指定
アラートのトリガー条件は「何を」と「どれだけ続いたら」の二要素で定義します。ここでは具体的な UI 操作とベストプラクティスを示します。
- Condition タブで
WHEN avg() OF query(A, 5m, now) IS ABOVE 80を設定 - 「For」欄に duration（保持期間）を入力。例として 5m とすると、CPU が 80 % 超えの状態が連続して 5 分以上続いた場合にアラートが発火します。
duration が短すぎるとスパイクで誤検知しやすく、長すぎると本当に問題が起きても通知が遅れます。実運用では 5–10 分 程度を目安に調整してください。
- 「Evaluate every」 は評価間隔です。通常は 1m 前後に設定し、過剰な評価負荷と遅延のバランスを取ります。
No data アラートの有効化と挙動
メトリクスが取得できない場合のデフォルト動作は OK と見なされますが、重要システムでは「データ欠損＝障害」とみなす方が安全です。
- ルール編集画面の Details タブへ移動
- 「Evaluation options」セクションにある When no data を Alerting に変更
データ取得間隔が長い環境では、
Forの duration を 10 分以上に設定すると誤検知を抑えられます。
Notification Policies と mute timing の活用例
通知先やサイレンスの条件は Notification Policies と Mute timings で細かく制御できます。以下では実務で頻繁に利用される設定例と手順を示します。
通知先（Slack・メール・Webhook）ルーティング設定
まずは通知対象グループを定義し、条件ごとに自動振り分けできるポリシーを作ります。
- Alerting → Notification policies にアクセス
- 「Add policy」ボタンで新規ポリシーを作成し、受信者グループ（Receiver group）を以下のように設定
| 受信者グループ | 通知チャネル例 |
|---|---|
| Ops‑Team | Slack Webhook https://hooks.slack.com/services/… |
| On‑Call | メール oncall@example.com |
| Webhook‑Alert | 汎用 Webhook https://example.com/alert |
- ポリシーの Matcher で
severity = criticalやalertname = CPU_Usage_Highといった条件を追加し、対象グループへ自動的に割り当てます。
この手順は kefi さんが 2024 年に公開した記事でも紹介されています[^2]。ポイントは Alertmanager 経由ではなく Grafana 側で直接 Slack Webhook を設定する点です。
mute timing による時間帯別サイレンス設定手順
業務時間外だけ通知したいケースや、定期的なメンテナンス時に一括でサイレンスしたい場合は Mute timings が便利です。
- 同じく Notification policies ページ左上の Mute timings タブを開く
- 「Add mute timing」 → 名称
BusinessHoursを入力し、以下の JSON 形式で時間帯を定義
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "name": "BusinessHours", "time_intervals": [ { "days_of_week": ["monday","tuesday","wednesday","thursday","friday"], "start_time": "09:00", "end_time": "18:00" } ] } |
- 作成した mute timing を対象ポリシーの Silence 欄に割り当てれば、平日 9 時〜18 時は通知が自動的に抑制されます。逆に夜間や週末だけアラートを受け取りたい場合は別途
Weekendタイミングを作成すると良いでしょう。
まとめ：Notification Policies が「誰へ」「どの条件で」通知するかを決め、Mute timing が「いつ除外するか」を管理します。これによりオンコール体制のノイズが大幅に削減されます。
Amazon Managed Grafana 特有の設定ポイント
マネージド版は AWS の IAM と連携してデータソースへのアクセス権を付与する必要があります。この章では最小権限例と、環境固有で追加が必要になる可能性のある項目について解説します。
IAM ロールとデータソース連携
以下は CloudWatch と Amazon Managed Service for Prometheus (AMP) を利用する際の 最小権限 ポリシーです。ただし、実際の環境ではログ取得やタグベースの制御が必要になることがありますので、コメントで注意点を付記しています。
|
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 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:GetMetricData", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "aps:QueryMetrics" ], "Resource": "arn:aws:aps:*:*:workspace/*" } /* 追加が必要になるケース例 - CloudWatch Logs を参照する場合は logs:GetLogEvents 等 - 特定タグのリソースだけに絞る場合は Condition ブロックで aws:ResourceTag を使用 */ ] } |
手順
- AWS コンソール → IAM → Roles で新規ロールを作成し、上記ポリシー（または環境に合わせた拡張版）をアタッチ
- 作成したロールの ARN を Amazon Managed Grafana ワークスペース の「Permissions」画面で紐付ける
- データソース追加時に Use IAM role を選択し、ロールが正しく適用されていることを確認
IAM ロールは最小権限の原則（Least Privilege）に従い、不要なリソースへのアクセスは絶対に付与しないようにしてください。
Managed Grafana で統合アラートを有効化するフロー
- ワークスペース設定画面の Alerting タブで Enable unified alerting にチェック
- UI が切り替わったら、オンプレミス版と同様に Alerting → Rules からルール作成が可能です
- 外部通知先は AWS SNS 経由で設定するケースが多いです。SNS トピック ARN を受信者として登録すれば、Slack やメールへのブリッジもシームレスに機能します
注意点：SNS のポリシーでも同様に最小権限を守り、
Publish権限だけを対象ロールに付与してください。
アラートテスト・トラブルシューティングと実務サンプルダッシュボード
運用開始前に必ずテストと検証を行うことで、本番環境での誤検知や通知遅延を防げます。この章では UI からのテスト手順、よくある障害例、そしてローカル環境で動作確認できるサンプルダッシュボードを紹介します。
テスト方法とステータス確認手順
- Alerting → Rules の一覧画面で対象ルール右側の Test rule をクリック
- ポップアップの Evaluate now ボタンを押すと、現在のデータに基づく評価結果が即座に表示されます
- 結果は OK / Alerting / No data のいずれかで示され、右上の View alerts から過去のトリガーログも確認可能です
テスト実行時に「Alerting」になる場合は、duration が短すぎるケースが多いため、5 分以上に伸ばして再評価してください。
一般的なトラブルケースと対処法
| 症状 | 典型的な原因 | 推奨対策 |
|---|---|---|
| 常に「Alerting」になる | duration が 0 または極端に短い |
duration を 5 m〜10 m に設定し、評価間隔と合わせる |
| 通知が届かない | Matcher 条件が厳しすぎてマッチしない | Matcher を緩め、テスト用に severity = any として確認 |
| 「No data」になるが実際はデータあり | クエリの時間範囲 $__interval が過小で欠測が発生 |
時間ウィンドウを広げるか、fill(null) を除去 |
実務で使えるサンプルダッシュボードと簡易データセット
以下は MetricFire が公開している Python スクリプトを元に、ローカルの Prometheus に疑似 CPU 使用率メトリクスを流し込む手順です。実際にデータが入ることで、前述のアラート設定が正しく機能するか即座に確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# requirements.txt requests==2.31.0 prometheus-client==0.16.0 # generate_cpu_metric.py import random, time from prometheus_client import Gauge, start_http_server cpu_gauge = Gauge('cpu_usage_percent', 'CPU usage in percent') start_http_server(8000) while True: cpu_gauge.set(random.uniform(20, 95)) # 20%〜95% の疑似データ time.sleep(30) |
- 上記スクリプトを実行し、
http://localhost:8000/metricsが公開されることを確認 - Prometheus の
scrape_configsに以下を追加
|
1 2 3 4 |
- job_name: 'local_cpu' static_configs: - targets: ['host.docker.internal:8000'] |
- Grafana で Prometheus データソースを作成し、クエリ
cpu_usage_percentを使ったパネル（Time series または Gauge）を配置 - 前述の「CPU 使用率 > 80 %」アラートルールを同じデータソースに対して適用し、Test rule で即時評価
このサンプルダッシュボードは、実運用前の PoC（概念実証） に最適です。疑似データの変動幅や評価間隔を調整すれば、様々なシナリオを手軽に再現できます。
まとめ
- 統合アラート は Grafana 9/10 の核となる機能で、旧バージョンと比べて UI・権限管理が一元化され、運用負荷が大幅に低減します。
- アラートルールは「クエリ → 条件 → duration」の３ステップで構築し、
durationの設定ミスが誤検知の最大要因になるため慎重に調整してください。 - No data アラートを有効化すればデータ欠損時にも即座に通知でき、システム全体の可観測性が向上します。
- Notification Policies と mute timing を組み合わせることで、受信者・条件・時間帯ごとに柔軟な通知制御が可能です（Slack、メール、Webhook の実装例を掲載）。
- Amazon Managed Grafana では IAM ロールでデータソース権限を付与し、Unified Alerting を有効化すればマネージド環境でも同様の設定が利用できます。最小権限ポリシーは環境に応じて 追加権限 が必要になる点に留意してください。
- テストは UI の Test rule から即時評価し、一般的なトラブル（常にアラート、通知未達、No data 誤判定）は
duration・Matcher・クエリ時間範囲の見直しで解決できます。 - 最後に、MetricFire のサンプルスクリプトと Prometheus ダッシュボードを活用すれば、本番導入前に安全かつ手軽に動作検証が可能です。
参考リンク
[^1]: kuttsun, 「Grafana 9 における統合アラートの全容」(2023年), https://example.com/kuttsun-grafana-unified-alert
[^2]: kefi, 「Slack Webhook を Grafana 側で直接設定する方法」(2024年), https://example.com/kefi-slack-webhook-grafana