Contents
スポンサードリンク
全体構成のイメージ
|
1 2 3 4 5 6 7 8 9 |
graph LR subgraph Cluster[Kubernetes クラスタ] Prom[Prometheus] -->|scrape| KS[kube-state-metrics] Prom -->|scrape| NE[node-exporter] Prom -->|alert to| AM[Alertmanager] AM -->|notify| Slack[(Slack Webhook)] AM -->|mail| Gmail[(Gmail SMTP)] end |
- Prometheus が
kube-state-metrics・node-exporterから指標を取得し、定義したルールに基づいて Alertmanager にアラートを送信。 - Alertmanager は Slack と Gmail（App Password）へ通知する構成です。
- 本ガイドでは Helm と Operator (kube‑prometheus‑stack) の2パターンを示し、どちらでも同一の
AlertRuleと通知設定が利用できることを目指します。
Prometheus & Alertmanager のデプロイ方法比較
1. Helm Chart を使ったシンプルインストール
| 項目 | 内容 |
|---|---|
| チャート | prometheus-community/kube-prometheus-stack |
| 主な利点 | 1 回のコマンドで Prometheus・Alertmanager・Grafana·Exporter が一括デプロイ。 カスタム値は values.yaml に記載するだけで柔軟に調整可能。 |
| 想定ユースケース | PoC、テスト環境、短期間の導入が必要な場合 |
手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
# 1. Helm リポジトリ登録 & 更新 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 2. カスタム values.yaml（例）※必ずシークレットは別途作成してください cat > prom-values.yaml <<'EOF' alertmanager: enabled: true config: global: resolve_timeout: 5m route: group_by: ['alertname'] receiver: slack-notify routes: - match: severity: critical receiver: mail-critical receivers: - name: slack-notify slack_configs: - api_url: ${SLACK_WEBHOOK_URL} channel: '#alerts' send_resolved: true - name: mail-critical email_configs: - to: 'oncall-team@example.com' from: '${ALERTMAIL_FROM}' smarthost: 'smtp.gmail.com:587' auth_username: '${ALERTMAIL_USER}' auth_password_file: /etc/alertmanager/secrets/smtp-password require_tls: true prometheus: enabled: true serviceAccount: create: true EOF |
|
1 2 3 4 |
# 3. デプロイ（monitoring 名前空間を自動作成） helm install prometheus-stack prometheus-community/kube-prometheus-stack \ -f prom-values.yaml --namespace monitoring --create-namespace |
ポイント
api_url・auth_password_fileの値は環境変数または Kubernetes Secret に置き換えてください（後述のシークレット管理参照）。
2. Operator (kube‑prometheus‑stack) を用いた宣言的デプロイ
| 項目 | 内容 |
|---|---|
| 利点 | CRD (Prometheus, Alertmanager, ServiceMonitor 等) により設定が GitOps と相性抜群。スケールやアップグレードは CR の変更だけで完了。 |
| 想定ユースケース | 本番環境、長期運用、複数クラスター間で統一された管理をしたい場合 |
手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
# 1. Operator と CRD をインストール kubectl apply -f https://github.com/prometheus-operator/prometheus-operator/raw/main/bundle.yaml # 2. Prometheus カスタムリソース (prometheus.yaml) cat > prometheus.yaml <<'EOF' apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: my-prometheus namespace: monitoring spec: serviceAccountName: prometheus-k8s replicas: 2 # HA構成例 resources: requests: memory: 500Mi alerting: alertmanagers: - namespace: monitoring name: my-alertmanager port: web EOF # 3. Alertmanager カスタムリソース (alertmanager.yaml) cat > alertmanager.yaml <<'EOF' apiVersion: monitoring.coreos.com/v1 kind: Alertmanager metadata: name: my-alertmanager namespace: monitoring spec: replicas: 2 configSecret: alertmanager-config # 後述の Secret を参照 EOF # 4. 適用 kubectl apply -f prometheus.yaml -f alertmanager.yaml |
ポイント
configSecretに格納した Alertmanager の設定は、次章で作成する Kubernetes Secret (alertmanager-config) と同一です。
必要エクスポーター
kube‑state‑metrics
|
1 2 3 |
helm install kube-state-metrics prometheus-community/kube-state-metrics \ --namespace monitoring --create-namespace |
Operator を利用している場合は自動で次の ServiceMonitor が生成されます。手動で作成したいときは以下を参考にしてください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: kube-state-metrics namespace: monitoring spec: selector: matchLabels: app.kubernetes.io/name: kube-state-metrics endpoints: - port: http-metrics interval: 30s |
node‑exporter
|
1 2 3 |
helm install node-exporter prometheus-community/prometheus-node-exporter \ --namespace monitoring |
同様に ServiceMonitor が自動生成されます。
実務で使えるアラートルール例
以下は GitOps 用に ConfigMap に格納し、Prometheus の rule_files: から参照させる形を想定しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-alert-rules namespace: monitoring data: alert_rules.yml: | groups: - name: node.rules rules: - alert: HighCpuUsage expr: avg_over_time(node_cpu_seconds_total{mode="idle"}[5m]) < 20 for: 5m labels: severity: warning annotations: summary: "CPU 使用率が高い ({{ $labels.instance }})" description: "過去5分間で CPU のアイドル時間が20%未満です。" - alert: PodRestartsHigh expr: increase(kube_pod_container_status_restarts_total[10m]) > 3 for: 10m labels: severity: critical annotations: summary: "Pod が頻繁に再起動しています" description: "{{ $labels.namespace }}/{{ $labels.pod }} の再起動回数が 10 分で {{ $value }} 回です。" - alert: MemoryUsageHigh expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.85 for: 5m labels: severity: warning annotations: summary: "Memory 使用率が高い" description: "{{ $labels.instance }} のメモリ使用率が 85% を超えています。" - alert: DeploymentReplicasUnavailable expr: kube_deployment_status_replicas_available < kube_deployment_spec_replicas for: 2m labels: severity: critical annotations: summary: "Deployment のレプリカが不足" description: "{{ $labels.namespace }}/{{ $labels.deployment }} が期待レプリカ数 {{ $value }} 未満です。" |
適用例（Helm ディレクトリ構成）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# ConfigMap を作成 kubectl apply -f prometheus-alert-rules.yaml # Prometheus の設定に追加（values.yaml で指定） alertmanager: # 省略... prometheus: alertingRules: - name: custom-rules groups: - file: /etc/prometheus/rules/alert_rules.yml # ConfigMap がマウントされるパス |
通知先設定
1. Slack Webhook
Slack の Incoming Webhooks を利用します。Webhook URL は機密情報なので、以下のように Secret に格納し、Alertmanager 設定ではファイル参照にします。
|
1 2 3 4 5 6 7 8 9 10 |
# secret-slack.yaml apiVersion: v1 kind: Secret metadata: name: alertmanager-slack-webhook namespace: monitoring type: Opaque stringData: webhook_url: https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ # ← 実際の URL に置き換える |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# alertmanager-config.yaml（Secret のデータとして保存） apiVersion: v1 kind: Secret metadata: name: alertmanager-config namespace: monitoring type: Opaque stringData: alertmanager.yml: | global: resolve_timeout: 5m route: receiver: slack-notify group_wait: 30s group_interval: 5m repeat_interval: 12h receivers: - name: slack-notify slack_configs: - api_url_file: /etc/alertmanager/secrets/slack-webhook/webhook_url # ファイル参照 channel: '#alerts' send_resolved: true |
ポイント
api_url_fileは Alertmanager が 0.22 以降でサポートする「ファイルから読み込む」方式です。これにより Secret のマウントだけで済み、設定ファイル自体に URL がハードコーディングされません。
2. Gmail（App Password）によるメール通知
2022 年以降、Google は「安全性の低いアプリ」の認証を廃止しました。そのため SMTP 認証には App Password（2段階認証が有効な Google アカウントで作成）か、OAuth2 の代替手段を利用する必要があります。
手順
- Google アカウントで 2FA を有効化
- App Password を生成（例:
alertmanager-smtp） - 以下の Secret に保存
|
1 2 3 4 5 6 7 8 9 10 11 |
# secret-gmail.yaml apiVersion: v1 kind: Secret metadata: name: alertmanager-gmail-cred namespace: monitoring type: Opaque stringData: smtp_user: yourgmailaccount@gmail.com # 送信元アカウント smtp_password: xxxxxxxxxxxxxxxx # 生成した App Password |
- Alertmanager 設定にファイル参照で組み込む
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# alertmanager-config.yaml（続き） receivers: - name: mail-critical email_configs: - to: 'oncall-team@example.com' from: '${ALERTMAIL_FROM}' smarthost: 'smtp.gmail.com:587' auth_username_file: /etc/alertmanager/secrets/gmail/smtp_user auth_password_file: /etc/alertmanager/secrets/gmail/smtp_password require_tls: true send_resolved: true |
代替策
社内のメールサーバや SendGrid、Mailgun など外部 SMTP プロバイダーを使用する場合は同様に Secret に認証情報を格納し、smarthostを変更してください。
シークレット管理のベストプラクティス
1. Kubernetes Secret の基本作成フロー
|
1 2 3 4 5 6 7 |
# 例: Slack Webhook と Gmail 認証情報をまとめて作成 kubectl create secret generic alertmanager-secrets \ --namespace monitoring \ --from-literal=slack_webhook_url='https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ' \ --from-literal=gmail_user='yourgmailaccount@gmail.com' \ --from-literal=gmail_app_password='xxxxxxxxxxxxxx' |
注意
-type: Opaqueがデフォルトです。
-kubectl get secret ... -o yamlで出力した場合は Base64 エンコードされますが、実際の内容は暗号化されていません。クラスター自体に Encryption at Rest（KMS 連携）を有効化してください。
2. 外部シークレットマネージャーとの統合例
以下は External Secrets Operator を利用し、AWS Secrets Manager に保存した認証情報を K8s Secret として自動同期する構成です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# external-secret.yaml apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: alertmanager-external-secret namespace: monitoring spec: secretStoreRef: name: aws-ssm-store # 事前に作成した SecretStore リソース kind: SecretStore target: name: alertmanager-config # 生成される Kubernetes Secret 名 creationPolicy: Owner data: - secretKey: slack_webhook_url remoteRef: key: prod/alertmanager/slack-webhook # AWS Secrets Manager のシークレット名 - secretKey: gmail_user remoteRef: key: prod/alertmanager/gmail-user - secretKey: gmail_app_password remoteRef: key: prod/alertmanager/gmail-app-pass |
利点
| 項目 | 内容 |
|---|---|
| ローテーション | 外部ストアでパスワードを更新すれば、K8s 側は自動的にリフレッシュ。 |
| 監査・アクセス制御 | IAM ポリシーや Cloud KMS による細粒度の権限管理が可能。 |
| 暗号化 | シークレットは保存時に AWS KMS で暗号化され、K8s 側では暗号化された状態で保持（Encryption at Rest が必須）。 |
参考：External Secrets Operator の公式ドキュメント https://external-secrets.io/
3. Secret をマウントする Pod 定義例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
apiVersion: apps/v1 kind: Deployment metadata: name: alertmanager namespace: monitoring spec: replicas: 2 selector: matchLabels: app: alertmanager template: metadata: labels: app: alertmanager spec: serviceAccountName: prometheus-k8s containers: - name: alertmanager image: quay.io/prometheus/alertmanager:v0.27.0 args: - '--config.file=/etc/alertmanager/config/alertmanager.yml' volumeMounts: - name: config mountPath: /etc/alertmanager/config - name: secrets mountPath: /etc/alertmanager/secrets volumes: - name: config secret: secretName: alertmanager-config - name: secrets secret: secretName: alertmanager-secrets # 先ほど作成した Secret |
Grafana での可視化と運用上のポイント
1. Grafana のインストール（Helm）
|
1 2 3 4 5 6 7 8 |
helm repo add grafana https://grafana.github.io/helm-charts helm repo update helm install grafana grafana/grafana \ --namespace monitoring \ --set adminPassword='StrongPass123!' \ --set service.type=LoadBalancer # 必要に応じて NodePort 等へ変更 |
2. データソースとダッシュボードの設定
| 手順 | 操作 |
|---|---|
| データソース追加 | Grafana UI → Configuration → Data Sources → Add data source → Prometheus。URL に http://prometheus-operated.monitoring.svc:9090 を指定。 |
| 公式ダッシュボードインポート | Create → Import → ID に 3662（Kubernetes cluster monitoring）を入力し、先ほど作成した Prometheus データソースを選択。 |
| Alert List パネル | ダッシュボードに「Alert List」パネルを追加し、alertmanager_url: http://alertmanager-main.monitoring.svc:9093 を設定すれば、現在のアラートが一覧表示されます。 |
ヒント：Grafana の Provisioning 機能で
values.yamlにダッシュボード JSON とデータソース定義を組み込めば、GitOps で完全自動化できます。
3. 運用ベストプラクティス
| 項目 | 推奨設定 |
|---|---|
| Silence（一時停止） | UI だけでなく /api/v2/silences を使った自動化（例: メンテナンスウィンドウのスクリプト）。 |
| HA構成 | replicas: 2 以上に設定し、StatefulSet + PVC による永続化。Alertmanager のフラグ --retention.time=120h で保存期間を制御。 |
| ルールのバージョン管理 | alert_rules.yml を Git リポジトリで管理し、Argo CD / Flux が ConfigMap に反映させる。PR ベースのレビューで変更ミスを防止。 |
| ロギング & メトリクス | Alertmanager の内部メトリクス (alertmanager_notifications_total など) を Prometheus で取得し、AlertmanagerDown アラートも設定すると監視が完結する。 |
付録 – 参考文献・リンク集
| 項目 | URL |
|---|---|
| Prometheus Community Helm Chart | https://github.com/prometheus-community/helm-charts |
| kube‑prometheus‑stack Operator（GitHub） | https://github.com/prometheus-operator/kube-prometheus |
| Sysdig 公式ガイド – Prometheus と Alertmanager のベストプラクティス | https://sysdig.com/blog/kubernetes-monitoring-with-prometheus/ |
| Nutanix Docs – Kubernetes 上のメール通知設定（Gmail に関する記載あり） | https://www.nutanix.com/docs/k8s/monitoring |
| Google Workspace – App Password の作成手順 | https://support.google.com/accounts/answer/185833?hl=ja |
| External Secrets Operator | https://external-secrets.io/ |
| Grafana Dashboard ID 3662 | https://grafana.com/grafana/dashboards/3662 |
上記リンクは執筆時点の最新情報です。利用前に公式サイトで内容が変更されていないか必ず確認してください。
まとめ
- Helm と Operator のどちらでも、同一のアラートルールと通知設定をコードとして管理できる。
- Slack・Gmail への通知は Secret に格納した機密情報をファイル参照させることで、設定ファイルに平文が残らない安全な構成になる。
- Gmail の SMTP 利用は App Password が必須であり、従来の「安全性の低いアプリ」方式は利用できないことを留意。
- シークレット管理は Kubernetes Secret に加え、外部シークレットマネージャー（AWS Secrets Manager など）と連携させることで ローテーション・監査 を自動化できる。
- Grafana と Alertmanager の UI を組み合わせれば、アラートの可視化・一時停止・履歴確認がシームレスに行える。
このガイドをベースに GitOps パイプライン（Argo CD / Flux）へ取り込み、コードレビューと自動デプロイで運用品質を高めてください。 🚀
スポンサードリンク