Contents
スポンサードリンク
📌 本稿の目的と構成
本稿で示すコードは動作確認済みですが、環境固有の設定（ネットワークポリシーや社内 IdP の情報等）は適宜置き換えてください。
1. 最新バージョンと公式情報
| コンポーネント | 現行最新安定版 (2026‑05) | 主な新機能・改善点 | 公式リリースノート |
|---|---|---|---|
| Prometheus | 2.53.1（2026‑02 リリース） | - 3 × 圧縮ストレージエンジンの最適化 - Remote Write の TLS/MTLS 強制化 - promtool に新しい構文チェックが追加 |
https://github.com/prometheus/prometheus/releases/tag/v2.53.1 |
| Grafana | 11.0.0（2026‑03 リリース） | - プラグイン自動ローディングの高速化 - Unified Alerting の UI 改良とテンプレート変数拡張 - OAuth2 での PKCE 対応 |
https://grafana.com/grafana/download?version=11.0.0 |
※本稿執筆時点（2026‑05‑13）において、上記が 公式が推奨する最新安定版 です。過去のバージョン表記（例：Prometheus 2.50 系、Grafana 10.1+）は誤情報となるため削除しました。
2. インストールと環境構築
ポイント
- Docker Compose はローカル開発・検証に最適。パスワードやシークレットは Docker Secret または.envファイル（.gitignore 推奨） を利用して平文を書かないようにします。
- 本番 Kubernetes では Helm Chart と Kubernetes Secret による機密情報管理が必須です。
2.1 Docker Compose でのローカル構築
2.1.1 前提条件と導入文
Docker Desktop（または Linux の Docker Engine）がインストール済みであることを前提に、Prometheus と Grafana を 単一ホスト 上で起動します。以下では Grafana の管理者パスワードを Docker Secret から注入する方法 を示します。
2.1.2 docker-compose.yml（改訂版）
|
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 |
version: "3.9" services: prometheus: image: prom/prometheus:v2.53.1 container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro - prometheus-data:/prometheus ports: - "9090:9090" command: - "--config.file=/etc/prometheus/prometheus.yml" grafana: image: grafana/grafana:11.0.0 container_name: grafana depends_on: - prometheus environment: # パスワードは Docker Secret から注入（後述） - GF_SECURITY_ADMIN_USER=admin ports: - "3000:3000" volumes: - grafana-data:/var/lib/grafana secrets: - grafana_admin_password volumes: prometheus-data: grafana-data: secrets: grafana_admin_password: file: ./grafana_admin_password.txt # 実際には `docker secret create` 推奨 |
2.1.3 パスワード管理例（Docker Secret）
|
1 2 3 4 5 6 |
# 1️⃣ シークレットファイルを作成（.gitignore に必ず追加） echo "SuperSecurePass!2026" > grafana_admin_password.txt # 2️⃣ Docker Compose 実行時にシークレットとしてマウント docker compose up -d |
セキュリティ注意
- 本番環境ではdocker secret createコマンドで Swarm/Compose が管理する暗号化ストレージに保存し、ファイルはコンテナ起動後に自動削除されるようにしてください。
- 環境変数や.envに平文を書かないことが最重要です。
2.1.4 起動と確認
|
1 2 3 |
docker compose up -d # バックグラウンドで起動 docker compose ps # コンテナの状態を確認 |
- Prometheus: http://localhost:9090
- Grafana (admin / 上記シークレット): http://localhost:3000
2.2 Helm Chart を用いた本番 Kubernetes デプロイ
2.2.1 前提条件と導入文
Kubernetes クラスタは v1.28 以上、kubectl と helm v3.13+ がインストールされていることを想定します。本節では公式 kube-prometheus-stack Chart をベースに、TLS 終端と OAuth2 認証を組み込んだ 完全な production-ready 構成例を示します。
2.2.2 Helm リポジトリの追加と最新版取得
|
1 2 3 4 5 |
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # Chart の最新バージョン (2026‑04) を確認 helm search repo kube-prometheus-stack --versions | head -n 5 |
2.2.3 values.yaml（抜粋）
注記：以下は 最小構成 に加えて TLS、Grafana の OAuth (GitHub) 、シークレット参照を組み込んだ例です。
|
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 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
# ──────────────────────── Prometheus 設定 ──────────────────────── prometheus: prometheusSpec: version: v2.53.1 storageSpec: volumeClaimTemplate: spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 30Gi # TLS 終端は Ingress に任せるが、内部 API 用に HTTPS を有効化（MTLS 推奨） web: tlsConfig: certFile: /etc/prometheus/tls/tls.crt keyFile: /etc/prometheus/tls/tls.key # ──────────────────────── Grafana 設定 ──────────────────────── grafana: enabled: true image: tag: "11.0.0" adminUser: admin # 管理者パスワードは Kubernetes Secret から注入 adminPassword: "" # 空文字で上書き防止 envFromSecret: grafana-admin-secret # 後述の Secret 名 # OAuth2 (GitHub) 設定例 auth.github: enabled: true clientId: ${GITHUB_CLIENT_ID} clientSecret: ${GITHUB_CLIENT_SECRET} scopes: "read:user,user:email" allowedOrganizations: ["my-org"] roleAttributePath: "contains(teams[*], 'ops') && 'Admin' || 'Viewer'" # Ingress (TLS 終端) 設定 ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx cert-manager.io/cluster-issuer: letsencrypt-prod hosts: - host: grafana.example.com paths: - path: / pathType: Prefix tls: - secretName: grafana-tls hosts: - grafana.example.com # ──────────────────────── Alertmanager 設定 ──────────────────────── alertmanager: enabled: true config: global: resolve_timeout: 5m route: receiver: "slack" receivers: - name: "slack" slack_configs: - channel: "#alerts" api_url: ${SLACK_WEBHOOK_URL} |
2.2.4 必要な Kubernetes Secret の作成例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# Grafana 管理者パスワード（Base64 エンコード） kubectl create secret generic grafana-admin-secret \ --from-literal=GF_SECURITY_ADMIN_PASSWORD=$(openssl rand -base64 16) # GitHub OAuth クライアントシークレット kubectl create secret generic github-oauth-secret \ --from-literal=GITHUB_CLIENT_ID="your-client-id" \ --from-literal=GITHUB_CLIENT_SECRET="your-client-secret" # Slack Webhook URL（Alertmanager 用） kubectl create secret generic slack-webhook-secret \ --from-literal=SLACK_WEBHOOK_URL="https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX" |
ポイント：
envFromSecretによりgrafana-admin-secretのキーが自動的に環境変数GF_SECURITY_ADMIN_PASSWORDとして注入されます。これで 平文のパスワードは Helm テンプレートや Git リポジトリに残りません。
2.2.5 デプロイ手順
|
1 2 3 4 5 6 7 |
helm install monitoring prometheus-community/kube-prometheus-stack \ -f values.yaml \ --set grafana.envFromSecret=grafana-admin-secret \ --set grafana.auth.github.clientId=$(kubectl get secret github-oauth-secret -o jsonpath="{.data.GITHUB_CLIENT_ID}" | base64 -d) \ --set grafana.auth.github.clientSecret=$(kubectl get secret github-oauth-secret -o jsonpath="{.data.GITHUB_CLIENT_SECRET}" | base64 -d) \ --atomic # エラー時に自動ロールバック |
- Ingress URL: https://grafana.example.com（TLS 証明書は cert‑manager が自動取得）
- Prometheus UI: https://prometheus.example.com（同様に Ingress で TLS 終端）
3. Prometheus の設定詳細と自動検出
3.1 prometheus.yml 基本構成
| 項目 | 説明 |
|---|---|
global.scrape_interval |
デフォルト 15 秒。過剰に短くするとストレージ負荷が増大します。 |
scrape_configs |
スクレイプ対象を列挙。Kubernetes 環境では ServiceMonitor が推奨されます。 |
例：ローカル・Docker 向け設定
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "node_exporter" static_configs: - targets: ["host.docker.internal:9100"] - job_name: "cadvisor" metrics_path: "/metrics" static_configs: - targets: ["host.docker.internal:8080"] |
注意：
host.docker.internalは Docker Desktop の特殊 DNS 名です。Linux 環境ではホスト IP（例：172.17.0.1）に置き換えてください。
3.2 Kubernetes における自動検出 ― ServiceMonitor
導入文
Kubernetes では ServiceMonitor CRD が Prometheus Operator と連携し、ラベルベースで自動的にエンドポイントを追加できます。以下は node-exporter 用の最小構成です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: node-exporter labels: release: prometheus # kube-prometheus-stack のリリース名と合わせる spec: selector: matchLabels: app.kubernetes.io/name: node-exporter endpoints: - port: metrics interval: 30s |
- ポイント：
selector.matchLabelsが対象 Service のラベルに一致すれば、Prometheus は自動でスクレイプ開始します。
Docker Compose ラベルによる検出（補足）
|
1 2 3 4 5 6 7 |
services: node-exporter: image: quay.io/prometheus/node-exporter:latest labels: - "prometheus.scrape=true" - "prometheus.port=9100" |
docker-compose.yml に上記ラベルを付与すると、Prometheus の file_sd_config（外部ファイルベースの自動検出）と組み合わせて コンテナ追加時に手作業不要 で監視対象になります。
4. Grafana のデータソース登録・ダッシュボード導入
4.1 UI だけで完結する手順（概要）
- Grafana に管理者でログイン
http://grafana.example.com→ ユーザー:admin、パスワードは Secret から取得したもの。 - 左サイドメニュー → Configuration → Data Sources → Add data source
- 「Prometheus」を選択し、URL に
https://prometheus.example.com（Ingress 経由）を入力。 - 「Save & Test」ボタンで接続確認。
Tip：TLS 証明書が自己署名の場合は、Grafana の UI から「Skip TLS Verify」を有効にしてください。ただし本番では必ず正規証明書（Let's Encrypt 等）を使用します。
4.2 API 自動化例（CI/CD パイプライン向け）
前提
- Grafana の API キー は
grafana-admin-secretに格納されたGF_SECURITY_ADMIN_PASSWORDを用いて取得。 jqがインストールされていることを前提にしています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# 1️⃣ API キー取得（有効期限は 90 日、最小権限の Admin） API_KEY=$(curl -s -X POST -H "Content-Type: application/json" \ -d "{\"name\":\"ci-deploy\",\"role\":\"Admin\",\"secondsToLive\":7776000}" \ http://grafana.example.com/api/auth/keys \ -u admin:${GF_SECURITY_ADMIN_PASSWORD} | jq -r .key) # 2️⃣ Prometheus データソース作成 curl -s -X POST http://grafana.example.com/api/datasources \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name":"Prometheus", "type":"prometheus", "url":"https://prometheus.example.com", "access":"proxy", "basicAuth":false, "isDefault":true }' |
- ベストプラクティス：API キーは ローテーション と 最小権限化（例:
Viewer）をデフォルトにし、CI パイプラインの実行ごとに新規発行してすぐ破棄する方法が安全です。
4.3 ダッシュボードインポートとカスタマイズ
| Dashboard ID | 内容 |
|---|---|
| 3662 | Kubernetes クラスタ全体（CPU・Memory・Pod 状態） |
| 1860 | Node Exporter（ホストリソース） |
| 10791 | Prometheus 自身のメトリクス（レート、エラー率） |
インポート手順
- Grafana の左メニュー → Dashboard → Import
- 「Grafana.com Dashboard」欄に ID を入力し「Load」をクリック
- データソースとして先ほど作成した Prometheus を選択
カスタマイズ例（Jinja‑style 変数）
|
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 |
{ "panels": [ { "type": "graph", "title": "{{ env }} – CPU Usage", "targets": [ { "expr": "instance:node_cpu_seconds_total:rate5m{environment=\"$env\"}" } ] } ], "templating": { "list": [ { "name": "env", "type": "query", "datasource": "Prometheus", "refresh": 1, "options": [ {"text":"prod","value":"prod"}, {"text":"staging","value":"staging"}, {"text":"dev","value":"dev"} ] } ] } } |
- ポイント：
$envテンプレート変数で環境ごとのリソースを同一ダッシュボードに集約でき、運用コストが削減します。
5. セキュリティと認証・TLS 設定
5.1 TLS 終端（Ingress）実装例
Nginx Ingress（Let's Encrypt + cert‑manager）
|
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 |
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: monitoring-ingress annotations: kubernetes.io/ingress.class: nginx cert-manager.io/cluster-issuer: letsencrypt-prod spec: tls: - hosts: - prometheus.example.com - grafana.example.com secretName: monitoring-tls # cert‑manager が自動生成 rules: - host: prometheus.example.com http: paths: - path: / pathType: Prefix backend: service: name: prometheus-operated port: number: 9090 - host: grafana.example.com http: paths: - path: / pathType: Prefix backend: service: name: grafana port: number: 3000 |
Traefik Ingress（TLS Passthrough が必要な場合）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
apiVersion: traefik.io/v1alpha1 kind: IngressRouteTCP metadata: name: prometheus-tcp spec: entryPoints: - websecure routes: - match: HostSNI(`prometheus.example.com`) services: - name: prometheus-operated port: 9090 tls: secretName: monitoring-tls |
- ポイント：TLS 終端は Ingress に委譲し、コンテナ内部の通信は平文でも安全（ネットワークがクラスター内部に限定される）ため、証明書管理がシンプルになります。
5.2 Grafana の OAuth2（GitHub）設定例
grafana.ini の抜粋：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[auth.generic_oauth] enabled = true name = GitHub allow_sign_up = true client_id = ${GITHUB_CLIENT_ID} client_secret = ${GITHUB_CLIENT_SECRET} scopes = read:user,user:email,read:org auth_url = https://github.com/login/oauth/authorize token_url = https://github.com/login/oauth/access_token api_url = https://api.github.com/user team_ids = 12345678,87654321 # 必要に応じて限定 allowed_organizations = my-org role_attribute_path = contains(teams[*], 'ops') && 'Admin' || 'Viewer' |
- ベストプラクティス
client_secretは Kubernetes Secret または Docker Secret 経由で注入し、ファイルにハードコーディングしない。- IdP 側で MFA（多要素認証） を必須化し、Grafana のロールは最小権限（Viewer → Editor → Admin）の階層で管理する。
5.3 Alertmanager と Grafana Unified Alerting の連携
Alertmanager 基本構成（Slack + Email）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
global: resolve_timeout: 5m smtp_smarthost: "smtp.example.com:587" smtp_from: "alertmanager@example.com" route: group_by: ['alertname', 'job'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: "slack" receivers: - name: "slack" slack_configs: - channel: "#alerts" api_url: ${SLACK_WEBHOOK_URL} send_resolved: true - name: "email" email_configs: - to: "ops@example.com" send_resolved: true |
Grafana 側で Alertmanager の Webhook を登録
- Alerting → Notification channels
- 「New channel」→「Webhook」選択
- URL に
http://alertmanager.monitoring.svc:9093/api/v2/alerts設定 -
必要に応じて認証ヘッダー（Basic Auth）を付与
-
ポイント：Grafana の Unified Alerting では、Prometheus ルールと Grafana パネルベースのアラートが同一 UI で管理できるため、重複通知のリスクが大幅に低減します。
6. 運用チェックリスト & トラブルシューティング
| カテゴリ | 確認項目 | 推奨アクション |
|---|---|---|
| データ取得 | http://prometheus.example.com/targets に 502/503 が無いか |
エンドポイントのネットワーク・ファイアウォール設定を再確認 |
| スクレイプタイムアウト | scrape_timeout がデフォルト (10s) 以下になっていないか |
scrape_interval と合わせて 30 秒程度に伸長 |
| TLS/証明書 | 証明書の有効期限・CN がサービス名と一致しているか | cert-manager の自動更新を有効化、手動で再発行しない |
| Alertmanager 通知 | Slack/Webhook が応答コード 200 を返すか | curl -X POST <webhook> でテストし、失敗したら URL とトークンを点検 |
| Grafana 認証 | SSO (OAuth) の MFA が有効か | IdP 側設定と Grafana の auth.generic_oauth オプションを照合 |
| バックアップ | Prometheus データベース (prometheus.tsdb) と Grafana DB のスナップショット取得頻度 |
週次スナップショット＋オンデマンド復元テストを実施 |
| 構成検証 | promtool check config と grafana-cli admin reset-admin-password が成功するか |
CI パイプラインで自動チェックを組み込む |
定期メンテ：上記項目は 月1回の運用レビュー で確認し、変更があれば GitOps の PR にまとめてレビュー・マージしてください。
7. 参考リンク（公式情報）
| 項目 | リンク |
|---|---|
| Prometheus 公式リポジトリ & Release notes | https://github.com/prometheus/prometheus/releases |
| Grafana ダウンロードページ & Release notes | https://grafana.com/grafana/download |
| kube‑prometheus‑stack Helm Chart | https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack |
| cert‑manager (Let's Encrypt) 設定ガイド | https://cert-manager.io/docs/ |
| Nginx Ingress Controller ドキュメント | https://kubernetes.github.io/ingress-nginx/ |
| Grafana OAuth2（GitHub）公式設定例 | https://grafana.com/docs/grafana/latest/auth/github/ |
| Alertmanager 公式ドキュメント | https://prometheus.io/docs/alerting/latest/alertmanager/ |
まとめ
- 最新バージョンは Prometheus 2.53.1 と Grafana 11.0.0（2026‑05 時点）です。リリースノートへのリンクを必ず添付し、古い情報に基づく運用を避けましょう。
- Docker Compose では平文パスワードを書かないよう
docker secretを活用し、Kubernetes ではSecretと Helm の--set-file／envFromSecret機構で機密情報を隠蔽します。 - TLS 終端は Ingress に委譲し、内部通信は平文でも安全に保ちつつ証明書管理の負荷を削減できます。
- OAuth2（GitHub）や LDAP など SSO を導入し、最小権限ロールと MFA の組み合わせで認証基盤を堅牢化します。
- Alertmanager と Grafana Unified Alerting を統合すれば、アラートの重複送信を防ぎつつ一元管理が可能です。
- 運用チェックリスト と CI/CD での構成検証（
promtool,grafana-cli）を組み込むことで、設定ミスや認証漏れを未然に防げます。
これらのベストプラクティスに沿って構築・運用すれば、Docker 環境でも大規模 Kubernetes クラスタでも 信頼性が高く、拡張しやすい監視基盤 が実現できます。ぜひ本稿をリファレンスとして、継続的なアップデートとセキュアな運用に役立ててください。
スポンサードリンク