Kubernetes に Prometheus と Alertmanager を導入し Slack 通知を設定する完全ガイド

全体像と前提条件

本セクションでは、今回構築するシステムの概要と、作業を始める前に準備しておくべき項目を紹介します。
- 対象環境：Kubernetes 1.30 以降（マネージドでもオンプレでも可）
- 必須ツール：helm, kubectl, promtool, yamllint, kubeval（CI に組み込む想定）
- 前提知識：基本的な Kubernetes の操作、Helm Chart の概念、PromQL の基礎

この記事は実践ガイドですので、手順をそのままコピーしても動作しますが、必ず自組織のネットワーク構成やセキュリティポリシーに合わせてパラメータを書き換えてください。

Helm Chart を使ったインストール手順

目的とメリット

Helm は Kubernetes 用のパッケージマネージャです。公式の kube-prometheus-stack Chart を利用すれば、Prometheus 本体・Alertmanager・Grafana まで一括でデプロイできます。
- 迅速な導入：数分で全コンポーネントが起動
- 柔軟なカスタマイズ：values.yaml に記述した設定だけでリソースを上書き可能

手順

1. リポジトリ追加と更新
   bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

2. values.yaml の作成（重要ポイントはコメントで説明）

yaml
# values.yaml
serviceAccount:
create: true # ServiceAccount を自動生成
name: prometheus-sa

alertmanager:
enabled: true
config:
global:
resolve_timeout: 5m
route:
receiver: slack-notify
group_by: ['alertname', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
routes:
- match:
severity: critical
receiver: slack-critical
receivers:
- name: slack-notify
slack_configs:
# Secret に保存したファイルを直接参照（api_url_file）
- api_url_file: /etc/alertmanager/webhook/slack_url
channel: '#monitoring-general'
title: "{{ .CommonAnnotations.summary }}"
text: "{{ .CommonAnnotations.description }}"
- name: slack-critical
slack_configs:
- api_url_file: /etc/alertmanager/webhook/slack_critical_url
channel: '#alerts-crit'


ポイント
- api_url_file を使うことで、Secret に保存したプレーンテキストの URL を直接ロードできます。Base64 エンコードされた文字列をテンプレート変数で展開する必要はありません。
- Secret のマウント先は /etc/alertmanager/webhook と統一し、Chart 側の extraSecretMounts で指定します。

1. Secret の作成（Webhook URL を平文で保存）

bash
kubectl create secret generic alertmanager-webhooks \
--from-literal=slack_url='https://hooks.slack.com/services/AAA/BBB/CCC' \
--from-literal=slack_critical_url='https://hooks.slack.com/services/DDD/EEE/FFF' \
-n monitoring

1. Helm デプロイ

bash
helm install prom-stack prometheus-community/kube-prometheus-stack \
-f values.yaml \
--namespace monitoring --create-namespace \
--set alertmanager.extraSecretMounts[0].name=alertmanager-webhooks \
--set alertmanager.extraSecretMounts[0].mountPath=/etc/alertmanager/webhook \
--set alertmanager.extraSecretMounts[0].secretName=alertmanager-webhooks \
--set alertmanager.extraSecretMounts[0].readOnly=true

1. 動作確認

bash
# Pod が正常に起動しているか確認
kubectl get pods -n monitoring

# Grafana にポートフォワードし、UI でデータソースが自動登録されていることを確認
kubectl port-forward svc/prom-stack-grafana 3000:80 -n monitoring


注意：extraSecretMounts の設定は Chart バージョンによって名前が変わる場合があります。2026 年版のリリースノートを必ず確認してください。

Operator と CRD によるインストール手順

目的とメリット

Operator はカスタムリソース（CR）とコントローラで構成され、宣言的にクラスター全体の状態管理ができます。GitOps と組み合わせると、Prometheus, Alertmanager, PrometheusRule のバージョン管理がコードレビューと同等の安全性で行えます。

手順

1. 最新 CRD バンドルを取得

固定バージョン (v0.78.2) を使用すると、将来的に互換性問題が生じる恐れがあります。以下のコマンドは GitHub API から最新版タグを自動取得し、適用します（CI パイプラインで利用可能）。

bash
LATEST=$(curl -s https://api.github.com/repos/prometheus-operator/prometheus-operator/releases/latest | jq -r .tag_name)
kubectl apply -f "https://github.com/prometheus-operator/prometheus-operator/releases/download/${LATEST}/bundle.yaml"

1. Prometheus カスタムリソース

yaml
# prometheus.yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: main
namespace: monitoring
spec:
serviceAccountName: prometheus-sa
resources:
limits:
cpu: 600m
memory: 600Mi
requests:
cpu: 250m
memory: 300Mi
enableAdminAPI: true

1. Alertmanager カスタムリソース（Secret マウントとファイル参照を含む）

yaml
# alertmanager.yaml
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
name: main
namespace: monitoring
spec:
replicas: 2
resources:
limits:
cpu: 200m
memory: 256Mi
secretMounts:
- name: alertmanager-webhooks
mountPath: /etc/alertmanager/webhook
secretName: alertmanager-webhooks
readOnly: true

1. 適用と確認

bash
kubectl apply -f prometheus.yaml
kubectl apply -f alertmanager.yaml
kubectl get prometheus,alertmanager -n monitoring

ポイント：spec.secretMounts は Operator が提供する機能で、Pod の volumeMounts と同等です。マウントしたファイルは Alertmanager 設定内で api_url_file に指定できます。

アラートルールの定義・検証 (promtool)

目的と重要性

アラートルールは PrometheusRule カスタムリソースとして管理されますが、書式ミスや PromQL の文法エラーはデプロイ時に即座に検出できません。promtool をローカルで実行し、CI に組み込むことで品質を担保します。

ルールファイル例

ローカル検証コマンド

CI パイプライン例（GitHub Actions）

Alertmanager の通知設定 – Secret と ConfigMap のベストプラクティス

目的と課題点の整理

• 課題 1：alertmanager.yaml が {{ .Values.slack.webhookUrl }}（Base64 エンコード済み）を直接参照しているため、Alertmanager が期待する URL 形式にならない。
• 課題 2：Secret を /etc/alertmanager/webhook にマウントしても設定ファイル側でそのパスを利用していない。

改善策

1. Webhook URL は Secret のファイルとして保存し、Alertmanager 設定では api_url_file を使用

2. これにより Helm テンプレート内で Base64 デコード処理を書かずに済みます。

3. values.yaml にテンプレート変数は不要（Secret が直接参照されるため）

Secret 作成例（再掲）

Alertmanager 設定（alertmanager.yaml）

Deployment へのマウント設定（Helm values の例）

ポイント：api_url_file は Alertmanager が提供する「ファイルから URL を読む」機能です。Secret のマウント先と完全に一致させるだけで、Base64 デコードやテンプレート文字列の加工は不要になります。

テスト用 curl コマンド（GET 版）

Alertmanager の API は GET メソッドでクエリパラメータ query を受け取ります。POST ではなく以下のように実行してください。

このコマンドで返ってくる JSON に status: "success" が含まれ、設定が正しく反映されていることを確認できます。

CI パイプラインへの自動検証組み込み例

目的

• YAML の構文とインデント：yamllint
• Kubernetes スキーマ妥当性：kubeval（または kubectl apply --dry-run=client）
• Prometheus ルールの正当性：promtool

正しい yamllint オプション例

以前は "{indent: 2}" と書かれていましたが、実際のオプション形式は上記のように JSON ライクな文字列で指定します。

GitHub Actions ワークフロー全体例

トラブルシューティングと運用ヒント

よくあるエラーと対処法

運用上のベストプラクティス

1. Secret のローテーション

2. 30 日ごとに Webhook URL を再生成し、kubectl apply -f secret.yaml 後に rollout restart。CI に自動化すると楽です。

3. Alertmanager のバージョン固定は避ける

4. helm upgrade --install 時に --version フラグを省略し、Chart リポジトリの最新安定版を取得する方が長期的に安全です。

5. Grafana ダッシュボードと Alertmanager のリンク
   json
{
"targets": [
{
"expr": "ALERTS{severity=\"critical\"}",
"legendFormat": "{{alertname}} ({{service}})",
"refId": "A"
}
],
"annotations": {
"__dashboardUid__": "prom-alerts",
"url": "http://<alertmanager>:9093/#/alerts?receiver=slack-critical"
}
}

6. これにより、Grafana のパネルから直接 Alertmanager の対象アラート一覧へ遷移できます。

7. ログとメトリクスのモニタリング

8. alertmanager コンテナの /var/log/alertmanager.log を Loki に流し、rate(alertmanager_notifications_failed_total[5m]) で失敗率を監視するアラートも追加すると安心です。

まとめ

• Helm と Operator のどちらでも数分で本番レベルの Prometheus + Alertmanager が構築可能です。
• Secret 管理は api_url_file を利用し、Base64 エンコード文字列をテンプレートに埋め込む手間を排除しました。
• CRD の取得は GitHub API で最新版タグを自動取得し、将来のバージョン差分リスクを低減します。
• CI パイプラインへ yamllint, kubeval, promtool を組み込むことでインデントミスやルール文法エラーを PR 時点で検出できます。
• トラブルシューティングフローと運用ベストプラクティス（Secret ローテーション、Grafana 連携、失敗率モニタリング）を実装すれば、障害発生時の復旧時間が大幅に短縮されます。

この手順に沿って構築・検証すれば、Slack／Discord への即時通知と可視化ダッシュボードが整った、信頼性の高い監視基盤を手に入れることができます。ぜひ自組織の CI/CD フローへ取り込み、継続的な品質保証を実現してください。