Prometheus × OPA：無法地帯の監視基盤を「ポリシー駆動」で守り抜く技術
こんにちは。システムの安定稼働を支えるオブザーバビリティの世界へようこそ。
組織が成長し、チームが増えると必ず直面する「負の遺産」があります。それは、「誰が書いたか分からない、ラベルの揺れまくったPrometheus設定ファイル」です。
`env=prod` なのか `environment=production` なのか。`service_name` は必須なのか。これらがバラバラのまま運用されると、いざ障害が起きたとき、ダッシュボードは壊れ、アラートは鳴り響くのに原因特定ができない……そんな絶望的な状況に陥ります。
今日は、Open Policy Agent (OPA) を使い、Prometheusの設定ファイルを「デプロイ前にCIで自動検出し、違反を弾く」という、現場で最も頼りになる守護神の作り方を伝授します。
—
1. なぜ「設定ファイルのガバナンス」が必要なのか？
Prometheusの `alerting_rules.yml` や `prometheus.yml` は、単なるテキストファイルではありません。これらは「システムの死活を握るコード」です。
- ラベルの統一: `instance` や `job` 以外のカスタムラベルの命名規則が崩壊すると、Grafanaでのクエリ（PromQL）が地獄化します。
- アラートのノイズ対策: 深刻度の低いアラートが放置されると、エンジニアは警告に対して鈍感になります。
- 権限と設定のガードレール: 誰でも自由に高頻度なスクレイピング設定を追加できてしまうと、Prometheusサーバーのメモリがパンクします。
これらを「人間のレビュー」に頼るのはやめましょう。「コードとして記述し、自動でテストする」。これがオブザーバビリティのプロの姿勢です。
—
2. OPA（Rego）でルールを書く：Hello World
まずは、OPAの言語である Rego で「特定のラベルが必須であること」を強制するルールを書いてみましょう。
インストール
macOSなら一行です。
brew install opa
ポリシーファイル (`rules.rego`)
以下は、「すべてのアラートに `severity` ラベルを強制する」というルールです。
package prometheus.alerts
ルール違反があればリストに追加する
violation[msg] {
alert := input.groups[_].rules[_]
# severityラベルがないものを探す
not alert.labels.severity
msg := sprintf(“Alert ‘%s’ には必須ラベル ‘severity’ が設定されていません”, [alert.alert])
}
—
3. 実践：Prometheus設定の自動検知
次に、検査対象となる `alerts.yml` を用意します。
検証対象 (`alerts.yml`)
groups:
- name: example
rules:
- alert: HighMemoryUsage
expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1 # severityラベルが欠けている（これが違反） labels: team: sre
実行してテストする
以下のコマンドで、設定ファイルがポリシーに準拠しているか確認します。
opa eval –data rules.rego –input alerts.yml “data.prometheus.alerts.violation”
実行結果：
{
“result”: [
{
“expressions”: [
{
“value”: [“Alert ‘HighMemoryUsage’ には必須ラベル ‘severity’ が設定されていません”],
“text”: “data.prometheus.alerts.violation”,
“location”: { “row”: 1, “col”: 1 }
}
]
}
]
}
ビンゴです。これで「ルール違反」を機械的に見つけることができました。
—
4. CI/CDパイプラインへの組み込み
ここからが本番です。GitHub Actionsにこのチェックを組み込み、「ポリシー違反があればPRをマージさせない」という強力なゲートを作ります。
`.github/workflows/policy-check.yml` の例です。
name: Prometheus Policy Check
on: [push, pull_request]
jobs:
opa-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install OPA
run: |
curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64
chmod +x opa
sudo mv opa /usr/local/bin/
- name: Run OPA Check
run: |
# 違反があれば終了コード1を返し、CIを失敗させる
opa eval –fail-defined –data rules.rego –input alerts.yml “data.prometheus.alerts.violation”
—
最後に：この仕組みがもたらす未来
この仕組みを導入すると、何が起きるか。
1. レビューの質が変わる: 「ラベルの名前が…」という細かい指摘を人間がする必要がなくなります。レビュアーは、ロジックの本質（アラート条件の妥当性など）に集中できます。
2. オンボーディングの加速: 新規メンバーは、何をすべきか迷う必要がありません。CIが「こう書け」と優しく教えてくれます。
3. 運用負荷の激減: データの正規化が担保されることで、Grafanaのクエリが爆速で書けるようになります。
オブザーバビリティの真髄は、「監視すること」そのものではなく、「監視される側をいかに健全に保ち続けるか」という仕組み化にあります。
ぜひ今日から、あなたのチームにこの「コードによるガバナンス」を導入してみてください。きっと、毎日の運用が劇的に、そして驚くほど楽になりますよ。
何か詰まったら、いつでも聞いてください。設計の細部まで一緒に詰めていきましょう。