Prometheus Alertmanagerを飼い慣らせ：Goで書く「究極のインシデント連携」アーキテクチャ
現場のテックリードとして、多くのチームを見てきたが、Prometheusの標準的な通知設定に満足しているエンジニアは、まだ「地獄の入り口」にいることに気づいていない。
Slackに流れてくる「`Firing`」という単なる文字列の羅列。それを人間が目で見て、チケットシステムに転記し、誰が対応するかをSlackで議論する。そんな不毛な時間は、今日で終わりだ。
今回は、AlertmanagerのWebhookをハックし、Go言語で「インシデントの文脈」を完全に自動制御するカスタムレシーバーの作り方を伝授する。
—
1. Alertmanagerペイロードの解剖：見えない「文脈」を捕まえろ
AlertmanagerのWebhookは、ただのJSONではない。ここには「どのサービスが、どれほど深刻に、どんなラベルを持って死んでいるか」のすべてが詰まっている。
特に注目すべきは `commonLabels` と `alerts` の構造だ。
- `commonLabels`: 複数のアラートがグルーピングされた際、共通する属性（例: `service`, `env`）を抽出できる。これを使わない手はない。
- `groupLabels`: どのアラートグループでまとめられたかの識別子。
- `alerts`: ここに個別の詳細が詰まっている。`annotations` には、Prometheusのルール定義で書いた `runbook_url` や `summary` を必ず含めるべきだ。
プロの教訓: ログやアラートに「Runbook（対応手順書）へのURL」を埋め込まない運用は、夜間呼び出しの際のエンジニアを殺す行為だ。必ずセットで設計せよ。
—
2. 実装：Goによる軽量カスタムレシーバー
フレームワークなど不要だ。`net/http` だけで十分。余計な依存関係は、将来の脆弱性管理コストになるだけだ。
package main
import (
“encoding/json”
“log”
“net/http”
)
// Alertmanagerの構造体に合わせる。現場では常に最新のスキーマを追うこと。
type Alert struct {
Labels map[string]string `json:”labels”`
Annotations map[string]string `json:”annotations”`
Status string `json:”status”`
}
type WebhookPayload struct {
Status string `json:”status”`
CommonLabels map[string]string `json:”commonLabels”`
Alerts []Alert `json:”alerts”`
}
func handler(w http.ResponseWriter, r http.Request) {
var payload WebhookPayload
if err := json.NewDecoder(r.Body).Decode(&payload); err != nil {
http.Error(w, “Bad Request”, http.StatusBadRequest)
return
}
// ここでルーティングロジックを回す
for _, alert := range payload.Alerts {
log.Printf(“[%s] Alert: %s – Summary: %s”, alert.Status, alert.Labels[“alertname”], alert.Annotations[“summary”])
// チケット発行、PagerDuty連携、インフラ自動回復処理をここに書く
}
w.WriteHeader(http.StatusOK)
}
func main() {
http.HandleFunc(“/webhook”, handler)
log.Fatal(http.ListenAndServe(“:8080”, nil))
}
—
3. 実務で差がつく「賢い」運用テクニック
チーム開発におけるYAML管理の絶対ルール
PrometheusのルールファイルやAlertmanagerの設定を「誰が書いたか分からない」状態にすると、必ず障害時のトリアージで詰む。
- `group_by` の戦略: `[‘alertname’, ‘cluster’, ‘service’]` でグルーピングせよ。サービスごとに通知チャネルを分けることで、ノイズが激減する。
- `inhibit_rules`: これが最も重要だ。「ネットワーク疎通断」が発生した時に、「APIエラー」や「DB接続エラー」が大量に発生するのを防ぐ。親アラートが発報している間、子アラートを黙らせる設定を必ず入れること。
開発スピードを上げる「神」ショートカット
- Prometheus Query Editor (VS Code): `Prometheus` 拡張機能を入れて、`.rules` ファイルのシンタックスチェックを保存時に自動実行せよ。
- `promtool` をCIに組み込む:
promtool check rules alert.rules
これをCIパイプラインの初期ステージに置く。デプロイ前にアラート設定ミスを検知できるだけで、年間数時間のロスが防げる。
—
最後に：なぜ「自作」なのか
市販のツールは便利だ。しかし、障害対応の「現場の文脈」は、どの会社も異なる。
「このサービスが落ちたら、まずはこのAPIを叩いてリフレッシュする」
「特定の環境では、このアラートは無視していい」
そうしたドメイン特有の知見をコードとしてレシーバーに埋め込むことこそが、オブザーバビリティの真髄だ。ツールに合わせるのではなく、ツールを自社の運用フローの「手足」にせよ。
次回の呼び出しが来たとき、Slackの通知ではなく、君が自作したチケット管理システムが「対応完了」のログを吐き出している未来を創ろう。それが、我々エンジニアの誇りだ。