監視の「死に体」を救う：Grafana OnCall で構築する、ノイズレスなインシデント管理の極意
多くのチームが「監視はしているが、アラートが多すぎて無視している」という致命的な状況に陥っている。PagerDutyは確かに強力だが、コストと設定の複雑さが開発の足枷になることも多い。
今、オブザーバビリティの最前線にいるエンジニアが選ぶべきは Grafana OnCall だ。これは単なる代替ツールではない。Grafanaのメトリクス・ログ基盤とシームレスに統合され、インシデントの「発生から解決」までを一つのコンテキストで完結させるための最強の武器だ。
本稿では、PagerDutyからの移行を含め、現場で本当に役立つ「運用を止めないための構築術」を伝授する。
—
1. なぜ Grafana OnCall なのか：コンテキストの断絶を断つ
監視の本質は、アラートを鳴らすことではなく、「誰が、いつ、何をすべきか」を迷わせないことにある。
- Grafanaとの統合: メトリクス（Prometheus/Mimir）やログ（Loki）から飛んできたアラートが、即座にOnCallのタイムラインに紐づく。
- コスト構造: ユーザー単位のライセンスに縛られず、Grafana Cloudの枠組みでスケールできる。
- 宣言的設定: インフラストラクチャ・アズ・コード（IaC）との親和性が極めて高い。
2. インシデント管理を「コード」で定義する（ベストプラクティス）
GUIで設定をポチポチするのは今日で終わりにしよう。Grafana OnCallの設定はTerraform（Grafana Provider）で管理し、環境差異を吸収するのがプロの作法だ。
エスカレーションポリシーの YAML 構成例
以下は、`SRE-Team` が 5分応答しなければマネージャーに通知が飛び、さらに5分経過で全体チャンネルにエスカレーションする設定の骨子だ。
Terraformによるエスカレーションポリシー定義の断片
resource “grafana_oncall_escalation_chain” “critical_chain” {
name = “Critical Service Alert Chain”
}
resource “grafana_oncall_escalation” “step_1” {
escalation_chain_id = grafana_oncall_escalation_chain.critical_chain.id
type = “notify_user_group”
duration_minutes = 5
# Slackと連携した即時通知
notify_user_group_id = grafana_oncall_user_group.sre_team.id
}
resource “grafana_oncall_escalation” “step_2” {
escalation_chain_id = grafana_oncall_escalation_chain.critical_chain.id
type = “notify_on_call_from_shift”
duration_minutes = 5
# ここでマネージャー層へエスカレーション
}
現場の知見: エスカレーションの `duration_minutes` は「5分」が黄金律だ。これより短いと過敏な反応（アラート疲れ）を招き、長いと初動の遅れに繋がる。
—
3. 生産性を劇的に高める「隠れたテクニック」
① Grafana OnCall の「神」ショートカット
ブラウザ操作に時間を費やすな。Grafanaを開いている状態で以下のキーを叩け。
- `g` + `o`: OnCall ダッシュボードへ即時ジャンプ。
- `Shift` + `?`: 全キーボードショートカットの表示（まずはこれを覚える）。
② Slack 連携の「ノイズ除去」戦略
Slackにアラートを流しすぎると、エンジニアは「アラート通知をミュート」するようになる。これを防ぐには 「インシデントグルーピング」 が必須だ。
- Labeling: `alertname` や `service_id` でグループ化し、1つのインシデントに対して1スレッドしか作らせない設定を徹底せよ。
③ 神プラグイン・拡張
- Grafana Annotation Integration: 解決したインシデントを自動的にGrafanaのグラフ上に「注釈（Annotation）」として書き込む。事後検証（Post-mortem）の際、グラフのスパイクとインシデントの相関を一目で確認できる。これができるだけで、障害対応時間は半分になる。
—
4. チーム開発で役立つ「運用の掟」
ツールを入れるだけでは現場は変わらない。以下のルールをチームに強制せよ。
1. 「アラートは常にアクション可能（Actionable）であること」:
- アクションを伴わないアラートは、即座に「警告（Warning）」に格下げせよ。Slackに流すな。
2. 「OnCall のローテーションは Git で管理せよ」:
- Grafana OnCall のスケジュール管理を Terraform に統合し、誰がオンコールかは `oncall.tf` を見れば全員が把握できる状態にする。
3. 「事後検証（Post-mortem）は Slack ログから自動生成せよ」:
- OnCall が解決した時点で、Slackスレッドの内容を自動的にバックアップするスクリプトを走らせる。
—
最後に：監視とは「対話」である
Grafana OnCall は、単なる通知ツールではない。システムが発する「悲鳴」を、エンジニアが「解決可能なタスク」へと変換するためのコンジット（導管）だ。
PagerDutyの運用コストに疲弊しているなら、今すぐ Grafana OnCall への移行を検討してほしい。Terraformでコード化し、Slackで完結させ、Annotationで歴史を刻む。このサイクルを回せば、あなたのチームの運用レベルは間違いなく一段上のステージに到達する。
「監視のノイズは、設計の甘さである」。
この言葉を胸に、今日も最高のダッシュボードを構築しよう。