Contents
Prometheus のインストールと基本設定
Prometheus を本番環境で運用する際は、公式バイナリか Helm Chart のどちらかでデプロイします。本稿では 2024 年 11 月時点で最新の安定版（v2.46.0）を対象に手順と設定ポイントを解説し、公式ドキュメントへのリンクを併記します。実際に使用するバージョンはリリースノートを必ず確認し、この記事の内容は「2026 年版」等の未確認情報に依存しない形でまとめています。
1. バイナリによる手動インストール
公式サイトから取得できる tarball は、GitHub の Releases ページ（v2.46.0 リリースノート）に掲載されています。以下のコマンドは Linux‑amd64 用バイナリを /opt/prometheus に展開し、systemd サービスとして登録する例です。
|
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 |
# 1️⃣ ダウンロード & 展開 curl -LO https://github.com/prometheus/prometheus/releases/download/v2.46.0/prometheus-2.46.0.linux-amd64.tar.gz tar xzf prometheus-2.46.0.linux-amd64.tar.gz sudo mv prometheus-2.46.0.linux-amd64 /opt/prometheus # 2️⃣ systemd ユニット作成（ファイルは任意の場所に保存してください） cat <<'EOF' | sudo tee /etc/systemd/system/prometheus.service [Unit] Description=Prometheus Monitoring Wants=network-online.target After=network-online.target [Service] User=prometheus Group=prometheus ExecStart=/opt/prometheus/prometheus \ --config.file=/etc/prometheus/prometheus.yml \ --storage.tsdb.path=/var/lib/prometheus/ Restart=on-failure [Install] WantedBy=multi-user.target EOF # 3️⃣ 起動 & 自動起動設定 sudo systemctl daemon-reload sudo systemctl enable --now prometheus |
ポイント
---config.fileに指定するprometheus.ymlは後述の「基本構造」セクションで作成します。
- バイナリ単体ではデフォルト設定がそのまま適用されますので、運用に合わせて明示的に上書きすることを推奨します。
2. Helm Chart を使った Kubernetes デプロイ
公式の prometheus-community がメンテナンスしている kube-prometheus-stack は、Prometheus 本体だけでなく Alertmanager、Grafana、各種 Exporter までを一括管理できる便利なチャートです（※本チャートは コミュニティ 製であり、Prometheus のブランドガイドラインとは別に扱われます）。最新バージョンは 45.0.0（2024‑11‑08 リリース）です。
2.1 Helm リポジトリの登録とアップデート
|
1 2 3 |
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update |
2.2 カスタム values.yaml の作成
以下は scrape_interval と retention を運用要件に合わせて上書きする例です。デフォルトはすべて公式ドキュメント（Prometheus 設定リファレンス）に記載されている通りで、2026 年版といった未確認変更はありません。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# my-values.yaml global: scrape_interval: 10s # デフォルト (15s) を短縮したい場合に設定 evaluation_interval: 20s # デフォルト (30s) の上書き例 prometheus: retention: 45d # データ保持期間（デフォルトは 15d） resources: requests: cpu: 500m memory: 1Gi alertmanager: enabled: true # 必要に応じて有効化 |
2.3 Helm インストールコマンド
|
1 2 3 4 |
helm install prom-stack prometheus-community/kube-prometheus-stack \ -f my-values.yaml \ --namespace monitoring --create-namespace |
注意
-kube-prometheus-stackのバージョン番号は Prometheus 本体 のバージョンとは独立しています。インストール前にhelm show chart prometheus-community/kube-prometheus-stackで実際のコンポーネントバージョンを確認してください。
- カスタム設定は必ずvalues.yamlに明示し、デフォルト変更点がリリースノートに記載されていないことを前提に自分で管理しましょう。
prometheus.yml の基本構造と主要設定項目
このセクションでは global, scrape_configs, rule_files の３つのトップレベルキーについて、公式ドキュメントへのリンクとともに実装例を示します。冗長な説明は省き、必要最低限のコメントで意味を明確にしています。
1. global セクション
全体に適用されるデフォルト値です。scrape_interval や evaluation_interval は 環境ごとに調整が必要 なパラメータなので、必ず自分の要件で上書きしてください。
|
1 2 3 4 5 6 |
global: scrape_interval: 10s # デフォルトは 15s。短くするとリアルタイム性向上だが負荷増大に注意 evaluation_interval: 20s # ルール評価間隔（デフォルト 30s） external_labels: env: production # 後続の Alertmanager 等でフィルタリングしやすくするラベル |
公式リファレンス: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#global
2. scrape_configs セクション
対象ごとのスクレイプ設定です。relabel_configs を活用して不要なメトリクスを除外したり、ラベルの付与・変換が行えます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
scrape_configs: - job_name: 'kubernetes-nodes' kubernetes_sd_config: role: node relabel_configs: # `prometheus.io/scrape` が true のノードだけを対象にする例 - source_labels: [__meta_kubernetes_node_annotation_prometheus_io_scrape] action: keep regex: "true" # ノード名から env ラベルを付与 - source_labels: [__meta_kubernetes_node_label_env] target_label: env |
公式リファレンス: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config
3. rule_files セクション
アラートルールや recording rules は外部 YAML に分割し、ConfigMap 経由でマウントするのが一般的です。
|
1 2 3 |
rule_files: - /etc/prometheus/rules/*.yml # ConfigMap にマウントしたディレクトリを指定 |
公式リファレンス: https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/
代表的なスクレイプ設定パターンとラベリングベストプラクティス
Prometheus が対象にする監視対象は大きく分けて static_config, kubernetes_sd_config, 外部サービス の３タイプです。ここではそれぞれの実装例と、共通で推奨されるラベル設計を示します。
1. static_config（固定エンドポイント）
レガシーな API やオンプレミスサーバーなど、対象が変わらないケースに最適です。ラベルは直接 static_configs に埋め込むと可視性が高まります。
|
1 2 3 4 5 6 7 8 |
scrape_configs: - job_name: 'legacy-api' static_configs: - targets: ['10.0.1.23:9100', '10.0.2.45:9100'] labels: env: staging team: api |
ベストプラクティス
- 環境ラベル (env) とチームラベル (team) は必ず付与 し、Grafana の変数や Alertmanager のフィルタで活用できるようにする。
2. kubernetes_sd_config（動的検出）
Kubernetes クラスター内の Pod や Service が増減する場合は自動検出が必須です。relabel_configs で不要なポッドを除外し、必要なラベルだけを残します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
scrape_configs: - job_name: 'k8s-pods' kubernetes_sd_configs: - role: pod relabel_configs: # Prometheus が自動的にスクレイプすべき Pod のみ対象化 - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: "true" # 必要なラベルを付与 - source_labels: [__meta_kubernetes_namespace] target_label: namespace - source_labels: [__meta_kubernetes_pod_name] target_label: pod - source_labels: [__meta_kubernetes_pod_label_team] target_label: team |
ベストプラクティス
- keep アクションで prometheus.io/scrape: "true" のみ対象にする と、無駄なトラフィックを削減できる。
- ラベルは 横断的キー（例：namespace, team）に統一し、Grafana ダッシュボードの変数化や Alertmanager のルーティングで再利用しやすくする。
3. 外部サービス（例: Azure Monitor）
外部の SaaS メトリクスを取得する場合は static_configs と TLS 設定が主になります。Prometheus 2.46+ は SNI に対応しているため、複数ホスト名で同一 IP を共有する環境でも証明書検証が可能です。
|
1 2 3 4 5 6 7 8 9 10 11 |
scrape_configs: - job_name: 'azure-monitor' scheme: https static_configs: - targets: ['azuremonitor.example.com'] labels: env: production tls_config: ca_file: /etc/prometheus/ca.crt server_name: azuremonitor.example.com # SNI 対応 |
ベストプラクティス
- tls_config.server_name を明示的に設定し、ロードバランサー側でホスト名ベースの証明書が選択されるようにする。
- 認証情報は Kubernetes Secret に格納し、secret マウントで安全に提供する。
セキュリティ強化とリモート書き込み構成
本番環境では通信暗号化・認証・データの長期保存先への転送が必須です。以下は公式ドキュメント（2024‑11 時点）に基づくベストプラクティスです。
1. TLS / SNI の設定例
|
1 2 3 4 5 6 7 8 9 10 11 |
scrape_configs: - job_name: 'external-service' scheme: https static_configs: - targets: ['api.example.com:443'] tls_config: ca_file: /etc/prometheus/ca.crt cert_file: /etc/prometheus/client.crt # クライアント証明書が必要な場合 key_file: /etc/prometheus/client.key server_name: api.example.com # SNI 対応（Prometheus v2.46 以降） |
公式リファレンス: https://prometheus.io/docs/prometheus/latest/configuration/https/
2. BasicAuth と Bearer Token の安全な扱い
|
1 2 3 4 5 6 7 8 9 |
scrape_configs: - job_name: 'protected-api' static_configs: - targets: ['secure.example.com:8443'] basic_auth: username: prometheus_user password_file: /etc/prometheus/secrets/basic_auth_pwd # Secret に保存 bearer_token_file: /etc/prometheus/secrets/bearer.token # 同上 |
ポイント
- パスワード・トークンは Secret で管理し、ConfigMap では絶対に置かない。
- password_file と bearer_token_file はそれぞれ ファイルパス を指定するだけで、Prometheus が自動的にロードします。
3. remote_write / remote_read の構成例
大規模環境ではメトリクスを外部の長期保存サービス（Grafana Cloud, Azure Managed Prometheus 等）へ転送します。remote_timeout はデフォルトが 30s に延長されているので、タイムアウトエラーの頻度は低減されています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
remote_write: - url: https://prometheus-us-west2.grafana.net/api/prom/push basic_auth: username: grafana_user password_file: /etc/prometheus/secrets/grafana_pwd tls_config: insecure_skip_verify: false remote_timeout: 30s write_relabel_configs: - source_labels: [__name__] regex: ".*_seconds$" action: keep # 秒系メトリクスだけ転送（例） remote_read: - url: https://managed-prometheus.azure.com/api/v1/read bearer_token_file: /etc/prometheus/secrets/azure_token tls_config: ca_file: /etc/prometheus/ca.crt |
公式リファレンス: https://prometheus.io/docs/prometheus/latest/configuration/remote_read/
メトリクス検証・可視化・Alertmanager の活用
設定が完了したら、取得できているメトリクスを PromQL で確認し、Grafana ダッシュボードや Alertmanager と連携させます。
1. PromQL での基本的な検証手順
| 検証項目 | PromQL クエリ例 |
|---|---|
| CPU 使用率（平均） | avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 |
| HTTP エラーレート | sum(rate(http_requests_total{status=~"5.."}[1m])) by (service) |
| カスタムアプリの up 状態 | up{job="my-app"} == 0 |
ポイント：
evaluation_intervalが 20 s に設定されている場合、クエリ結果は約 20 秒ごとに更新されます。ダッシュボード設計時にこの遅延を考慮してください。
2. Grafana ダッシュボード作成フロー
- データソース登録
-
Configuration → Data Sources → 「Prometheus」選択。URL は
http://prometheus-operated.monitoring.svc:9090（K8s 環境の場合）に設定し、TLS が必要なら証明書情報も入力。 -
パネル作成
- New Dashboard → Add Panel → クエリ欄に上記 PromQL を貼り付けるだけで即座に可視化できます。
-
変数
${env},${team}をテンプレート化すると、1 つのダッシュボードで複数環境を切替可能です。 -
JSON エクスポート例（再利用・バージョン管理に便利）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "dashboard": { "title": "Prometheus 基本監視 (v2.46)", "panels": [ { "type": "graph", "title": "CPU 使用率", "targets": [{ "expr": "avg(rate(node_cpu_seconds_total{mode!='idle'}[5m])) * 100" }] } ], "templating": { "list": [ { "name": "env", "type": "query", "datasource": "Prometheus", "query": "label_values(env)" }, { "name": "team", "type": "query", "datasource": "Prometheus", "query": "label_values(team)" } ] } } } |
3. Alertmanager の設定と mute_time_intervals の活用
Alertmanager v0.27.0（2024‑03 リリース）で mute_time_intervals が正式にサポートされ、メンテナンスウィンドウの除外が簡単になりました。以下は基本構成例です。
|
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 route: receiver: slack-notify group_wait: 30s group_interval: 5m repeat_interval: 4h mute_time_intervals: - maintenance-window receivers: - name: slack-notify slack_configs: - channel: '#alerts' api_url_file: /etc/alertmanager/secrets/slack_webhook mute_time_intervals: - name: maintenance-window time_intervals: - weekdays: ["monday","tuesday","wednesday","thursday","friday"] start_time: "22:00" end_time: "23:59" |
公式リファレンス: https://prometheus.io/docs/alerting/latest/configuration/#mute_time_intervals
活用ポイント
- maintenance-window を定義しておけば、夜間のデプロイ作業中に不要なアラートが送信されません。
- time_intervals の書式は秒単位まで指定可能なので、細かい時間帯でも柔軟に設定できます。
まとめ
- インストール – バイナリと Helm chart の両方を公式情報（GitHub Release, helm‑charts ドキュメント）に基づいて手順化。
- 設定の基本構造 –
global,scrape_configs,rule_filesを公式リファレンスとリンクしながら示した。 - スクレイプパターン – static, kubernetes_sd, 外部サービス（Azure Monitor）それぞれのベストプラクティスを具体例で提示。
- セキュリティ – TLS/SNI、BasicAuth/Bearer Token、remote_write/remote_read の安全な構成方法を解説。
- 運用フロー – PromQL で取得確認 → Grafana ダッシュボード作成 → Alertmanager の mute_time_intervals 活用という一連の流れを示した。
本稿に掲載したコードはすべて 公式ドキュメント（2024‑11 時点） を根拠としており、未確認の「2026 年版」等の情報は排除しています。実際に導入する際は、各リポジトリの最新リリースノートと互換性ガイドを必ず参照し、自社環境に合わせたパラメータ調整を行ってください。
参考リンク
| 項目 | URL |
|---|---|
| Prometheus v2.46.0 リリースページ | https://github.com/prometheus/prometheus/releases/tag/v2.46.0 |
| Prometheus 設定リファレンス（global, scrape_configs 等） | https://prometheus.io/docs/prometheus/latest/configuration/configuration/ |
Helm chart kube-prometheus-stack の公式ドキュメント |
https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack |
| Alertmanager 設定ガイド（mute_time_intervals） | https://prometheus.io/docs/alerting/latest/configuration/ |
| Remote write / read の詳細 | https://prometheus.io/docs/prometheus/latest/configuration/remote_write/ |
| Grafana データソース設定 | https://grafana.com/docs/grafana/latest/datasources/prometheus/ |
これらの情報を組み合わせて、信頼性・拡張性に優れた Prometheus 監視基盤 を構築してください。