監視の「無法地帯」をコードで制圧せよ：Prometheus × OPA によるポリシー駆動型ガバナンスの極意
チームがスケールし、マイクロサービスが乱立する現場で、皆さんはこんな「負の遺産」に頭を抱えていないだろうか。
- 「ラベルの不統一」：`env` なのか `environment` なのか、チームごとにバラバラで、ダッシュボードが壊滅する。
- 「野良アラート」：閾値が適当すぎて、SREのスマホが夜中に鳴り響く。
- 「カーディナリティの爆発」：誰かが `user_id` をラベルに突っ込んで、Prometheusが死にかける。
これらを「運用でカバー」するのは、もはやエンジニアの仕事ではない。監視設定も「コード」である以上、CIでバリデーションをかけるのは当然の責務だ。今回は、Prometheusの設定ファイルを OPA (Open Policy Agent) で静的解析し、デプロイ前に不適合を弾く「監視ガバナンスの自動化」について、現場で即戦力となる解法を伝授する。
—
1. なぜ「設定の静的解析」が必要なのか
監視設定（`prometheus.rules.yml` や `alerts.yaml`）は、一度デプロイされると修正コストが非常に高い。特にPrometheusは、一度時系列データが誤ったラベルで保存されると、バックフィルなしでは過去のデータと結合できない。
「壊れた設定を本番に入れない」。この鉄則を強制するのが、OPAによるポリシー駆動型監視だ。
推奨する構成案：GitOps ワークフロー
1. 開発者: `alerting_rules.yml` を編集しプルリクエスト。
2. CI (GitHub Actions):
- `promtool` で構文チェック。
- OPA (Rego) でラベル規約や命名規則をチェック。
3. マージ: 合格したものだけが Prometheus に反映される。
—
2. 実践：OPA で「不正な設定」を検知する
まずはRegoによるポリシー定義の核心部分を見せよう。例えば、「全てのアラート定義には `team` ラベルが必須」かつ「`severity` ラベルは `critical` か `warning` に限定する」というルールを作る。
`policy.rego` (監視ポリシーの定義)
package prometheus.rules
必須ラベルの存在チェック
default allow = false
違反が見つからない場合に許可する
allow {
count(violations) == 0
}
違反リストの生成
violations[msg] {
group := input.groups[_]
rule := group.rules[_]
# ‘alert’ フィールドを持つルールのみ対象
rule.alert
# チームラベルが設定されていない場合
not rule.labels.team
msg := sprintf(“Alert ‘%s’ はラベル ‘team’ が必須です”, [rule.alert])
}
許可された重要度レベル以外を禁止
violations[msg] {
group := input.groups[_]
rule := group.rules[_]
rule.alert
allowed_severities := {“critical”, “warning”}
not allowed_severities[rule.labels.severity]
msg := sprintf(“Alert ‘%s’ の severity ‘%s’ は不正です”, [rule.alert, rule.labels.severity])
}
—
3. GitHub Actions に組み込む「必勝」CI構成
このポリシーを CI/CD に組み込むには、`conftest` を使うのが最もエレガントだ。
`.github/workflows/lint-prometheus.yml`
jobs:
validate-alerts:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Conftest
uses: instrumenta/setup-conftest@v1
# 1. まずはPrometheus公式ツールで構文チェック
- name: Check Syntax with promtool
run: promtool check rules alerts/.yml
# 2. OPAポリシーで独自規約チェック
- name: Validate with OPA
run: conftest test alerts/.yml –policy policy/
—
4. プロの現場で差がつく「設定共有化」のベストプラクティス
設定ファイルが巨大化すると管理不能になる。現場では以下の構成を推奨する。
ディレクトリ構成案
monitoring/
├── alerts/
│ ├── k8s-nodes.rules.yml # インフラ系
│ └── business-logic.rules.yml # アプリケーション系
├── policy/
│ └── policy.rego # OPAポリシー
└── lib/
└── common-labels.libsonnet # Jsonnetで共通ラベルを管理
💡 テックリードの推奨テクニック
- Jsonnetの活用: Prometheus設定のYAMLは冗長になりがちだ。`Jsonnet` を使い、`team`, `environment`, `service` などの共通ラベルを関数として定義せよ。YAMLのコピペによるミスは、コードの重複から生まれる。
- VSCode プラグイン:
- Prometheus (by PromLabs): PromQLの補完が必須。
- OPA (by Styra): Regoのテスト実行とデバッグが劇的に楽になる。
—
5. 最後に：監視とは「合意」である
監視設定をCIでブロックするということは、単に「エラーを防ぐ」だけではない。それは、「チーム間で、何を監視すべきか、どの状態が異常か」という認識をコードとして合意する行為だ。
ポリシーをCIに組み込むと、最初は「厳しい」と反発があるかもしれない。だが、一度この「型」が出来上がれば、運用コストは激減し、エンジニアは「アラートの調整」という不毛な作業から解放され、本来の価値創造に集中できる。
さあ、あなたの Prometheus 設定を、ただの YAML から「ガバナンスされた最強の武器」へと進化させよう。現場で震えるような高質な監視体験は、この一歩から始まる。