※本記事にはプロモーションを含む場合があります。

  • Prometheusは時系列データベースを核とした監視ツールで、CPU使用率90%超などの条件で即座にアラートを飛ばせます
  • 導入にはPrometheus本体・Exporter・Alertmanagerの3コンポーネントが最低限必要で、構築時間の目安は初回で半日〜1日程度とされています
  • Node Exporterは9100番、Prometheus本体は9090番、Alertmanagerは9093番とポート番号を覚えておくと設定ミスを防げます
  • Zabbixなど従来型ツールと比べ、PromQLによる柔軟なクエリとKubernetes対応が最大の差別化ポイントです
  • 本番運用では30日〜90日程度のデータ保持期間設定とディスク容量の見積もりが運用トラブル回避の鍵になります

Prometheusとは？

Prometheusは2012年にSoundCloud社内で開発が始まったオープンソースの監視システムです。現在ではCNCF（Cloud Native Computing Foundation）が管理するプロジェクトとなっており、Kubernetesエコシステムにおけるデファクトスタンダードのメトリクスシステムとされています。従来型の監視ツールがリレーショナルデータベースにメトリクスを保存するのに対し、Prometheusは時系列データベース（TSDB）を採用している点が最大の違いです。

サーバーの死活監視という観点で見ると、Prometheusは単に「動いているか止まっているか」を判定するだけでなく、CPU使用率・メモリ消費量・ディスクI/O・ネットワークトラフィックといった数十種類のメトリクスを同時に収集し続けます。例えば5秒間隔でメトリクスを収集する設定にした場合、1台のサーバーから1日あたり約1万7000件のデータポイントが生成される計算になります。この蓄積されたデータをもとに、過去24時間・過去7日間・過去30日間といった単位でトレンド比較が可能です。

Prometheusが選ばれる3つの理由

1つ目は独自クエリ言語PromQLによる柔軟な分析力です。SQLのようなJOIN操作ではなく、ラベル（タグ）ベースでメトリクスを絞り込む設計になっており、「instance=\”web01\”」のような条件で瞬時にフィルタリングできます。2つ目はExporterという仕組みによる拡張性で、公式・非公式合わせて200種類以上のExporterが公開されているとされています。3つ目はPull型アーキテクチャで、Prometheus Server側が能動的にメトリクスを取得しにいくため、監視対象サーバー側の実装がシンプルに保てる点です。

比較項目PrometheusZabbix
データモデル時系列データベース（TSDB）リレーショナルデータベース
クエリ言語PromQLSQLベース
収集方式Pull型（自ら取得）Push/Pull両対応
初期構築の学習コストYAML設定＋PromQL習得で約3〜5日GUI操作中心で約1〜2日
Kubernetes親和性非常に高い（標準連携）プラグイン対応が中心
ライセンス費用無料（OSS）無料（OSS、商用サポートは別途）

Prometheusの5つの構成要素

アーキテクチャはPrometheus Server・Exporter・Alertmanager・Grafana・Pushgatewayの5要素で構成されています。Prometheus Serverがメトリクスの収集と保存、クエリ処理を担当し、Exporterが各サーバーの生データをPrometheusが読み取れる形式に変換します。Alertmanagerはアラートルールに合致した際の通知経路（Slack・メール・Webhookなど）を管理し、Grafanaはダッシュボード表示を担当します。Pushgatewayはバッチ処理のような短命なジョブのメトリクスを一時的に保持し、Prometheus Serverが後から取得できるようにする中継役です。この5つが連携することで、数台規模から数千台規模まで柔軟にスケールする監視基盤が構築できます。

導入前の準備

Prometheusを導入する前に、サーバーのスペックと監視対象の規模を確認しておく必要があります。小規模構成であれば1台のサーバーでPrometheus ServerとAlertmanagerを同居させても問題ないとされていますが、監視対象が50台を超えるあたりからリソース設計の見直しが推奨されます。

コンポーネントCPUメモリストレージ推奨OS
Prometheus Server2コア以上4GB以上SSD 10GB以上Ubuntu 20.04以上
Exporter1コア以上512MB以上SSD 1GB以上Linux/Windows
Alertmanager1コア以上1GB以上SSD 5GB以上Linux

ストレージ容量は保持期間によって大きく変動します。デフォルトの保持期間は15日ですが、監視対象100台・スクレイプ間隔15秒という条件では、1日あたり約150MB〜300MBのディスク消費が発生するといわれています。保持期間を90日に延長する場合は、事前に容量計算をしておくとディスク枯渇によるサービス停止を避けられます。

環境構築前のチェックリスト

  • □ サーバーのOSがLinux（Ubuntu 20.04以上推奨）であることを確認したか
  • □ 9090・9100・9093番ポートがファイアウォールで開放されているか
  • □ curl・wget・tarコマンドがインストール済みか
  • □ Prometheus専用の実行ユーザー（例：prometheus）を作成する方針が決まっているか
  • □ ディスクの空き容量が想定保持期間分（最低10GB以上）確保されているか

準備段階でこれらの項目をひとつずつ潰しておくことで、インストール作業中に発生しがちな権限エラーやポート競合を未然に防げます。特にファイアウォール設定の見落としは、Targetsページで「DOWN」表示が続く原因の第1位とされています。

基本設定と起動方法

Prometheus本体のインストールから起動までは、以下の手順で進めます。作業時間の目安は初回であれば30分〜1時間程度です。

  1. 公式GitHubリリースページから最新版のtar.gzファイルをダウンロードする（例：wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz）
  2. tar xvfz prometheus-2.47.0.linux-amd64.tar.gzでファイルを解凍し、専用ディレクトリへ移動する
  3. 設定ファイルprometheus.ymlを編集し、収集間隔と監視対象を定義する
  4. ./prometheus --config.file=prometheus.ymlを実行してサーバーを起動する
  5. ブラウザでhttp://サーバーIP:9090にアクセスし、Statusページが表示されることを確認する

設定ファイルはYAML形式で、globalセクション・scrape_configsセクション・alertingセクションの3つが基本構成です。globalセクションのscrape_intervalはメトリクス収集間隔を指定するもので、デフォルトは15秒です。監視対象が多い環境では30秒〜60秒に緩めることでサーバー負荷を抑えられるとされています。

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  rule_files:
    - 'alert.rules'
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'localhost:9093'

起動確認は3ステップで完結

正常起動時には「Start listening for connections address=:9090」というログが表示されます。このログが確認できたら、Web UI上のTargetsページで監視対象のステータスがUPになっているかをチェックし、続けてGraphページで簡単なPromQLクエリ（例：up）を実行してデータが返ってくるかを確認します。この3ステップで、収集・保存・クエリという一連の流れが機能しているかを短時間で検証できます。

Exporter導入方法

サーバー死活監視の実体を担うのがExporterです。Prometheus本体は自分自身のメトリクスしか持っていないため、各サーバーの状態を知るには対応するExporterを必ず導入する必要があります。代表的なExporterは以下の通りです。

Exporter名用途デフォルトポート
Node ExporterサーバーのCPU・メモリ・ディスク・ネットワーク9100
MySQL ExporterMySQLのクエリ数・接続数・レプリケーション状態9104
Redis ExporterRedisのメモリ使用量・接続数・コマンド実行数9121
Blackbox ExporterHTTP/HTTPS/TCP経由の外形死活監視9115

最も基本となるNode Exporterのインストール手順は次の通りです。

  1. 公式リリースから最新版をダウンロードする（例：wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz）
  2. 解凍後、/usr/local/bin/配下にバイナリを配置する
  3. 専用ユーザーnode_exporterをuseradd --no-create-home --shell /bin/false node_exporterで作成する
  4. systemdサービスファイル/etc/systemd/system/node_exporter.serviceを作成し、自動起動を有効化する
  5. sudo systemctl enable --now node_exporterでサービスを起動し、9100番ポートでLISTENしていることを確認する

サービス化しておくことで、サーバー再起動後も自動的にNode Exporterが立ち上がるため、再起動のたびに監視が途切れるという事故を防げます。Prometheus側の設定ファイルには以下のようにジョブを追加します。

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.100:9100']
    scrape_interval: 30s
    scrape_timeout: 10s

Kubernetes環境では動的検出も可能

コンテナ環境ではPodのIPアドレスが頻繁に変わるため、静的なtargets指定では運用が回りません。そこでkubernetes_sd_configsを使ったサービスディスカバリーを設定し、prometheus.io/scrape: "true"というアノテーションが付いたPodのみを自動的に監視対象へ組み込む方式が一般的とされています。この設定により、Pod数が数百台規模になっても手動でのターゲット追加作業が不要になります。

アラート設定を自動化

死活監視の本質は、異常を検知した瞬間に人へ通知が届くことです。Prometheusではrule_filesにアラートルールを定義し、Alertmanager経由で通知先へ送信する構成が基本です。以下はCPU使用率が90%を5分間超えた場合にアラートを発報する設定例です。

groups:
  - name: example
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"
          description: "CPU usage is {{ $value }}% for more than 5 minutes."

for: 5mの指定がポイントで、瞬間的なスパイクだけでアラートが乱発されるのを防ぐ役割を持っています。この猶予時間を設けないと、1日に数十回のアラートが飛んでしまい、担当者が本当に重大な障害を見落とす「アラート疲れ」に陥るリスクがあるとされています。

Alertmanagerで通知をグループ化する

複数のサーバーで同時に同じ障害が発生した場合、個別に通知が飛ぶと数十件のメッセージが一気に届いてしまいます。Alertmanagerのgroup_by設定を使えば、同一のアラート名でまとめて1通に集約できます。

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'webhook'
receivers:
  - name: 'webhook'
    webhook_configs:
      - url: 'http://alertmanager-webhook:5001/'

repeat_intervalを3時間に設定した場合、同一障害が解消されない限り3時間おきに再通知が届く仕組みになります。夜間対応の担当者を疲弊させないよう、深夜帯のみ通知先をSlackから電話連絡へ切り替えるルーティング設定を組み込む運用も一般的とされています。

Grafanaとの連携

Prometheus単体でもWeb UI上でグラフ表示は可能ですが、複数メトリクスをひとつのダッシュボードにまとめて可視化するにはGrafanaとの連携が実務上ほぼ必須とされています。Grafanaの導入自体は、公式リポジトリからパッケージをインストールし、データソース設定でPrometheusのURL（例：http://localhost:9090）を指定するだけで完了します。所要時間は10分〜15分程度です。

データソース登録後は、Node Exporter用の公開ダッシュボード（Grafana Labs公式のID番号を指定してインポート）を使うことで、CPU・メモリ・ディスク・ネットワークの主要メトリクスが即座にグラフ化されます。ゼロから作成するとダッシュボード1枚あたり数時間かかることもありますが、公開テンプレートを流用すれば5分程度で見栄えの良い監視画面が完成します。

ダッシュボード設計の3つのコツ

1つ目は「1画面に詰め込みすぎない」ことです。パネル数が20枚を超えると、障害発生時にどこを見ればよいか分からなくなるため、サーバー概要・ネットワーク・アプリケーション別に画面を分割するのが実務的とされています。2つ目は色分けのルール統一で、緑=正常、黄=警告閾値の80%到達、赤=クリティカルというように全パネルで色の意味を揃えると視認性が上がります。3つ目はアラートしきい値の線をグラフ上に表示しておくことで、数値だけでなく視覚的にも異常を判断しやすくなります。

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

Prometheusを本番環境で長期運用する際は、初期構築時とは異なる観点での設定調整が必要になります。まずデータ保持期間についてですが、デフォルトの15日では過去比較の分析には不十分なケースが多く、30日〜90日程度に延長する構成が一般的とされています。ただし保持期間を延ばすほどディスク消費量も比例して増えるため、月次でディスク使用率を確認する運用フローを組んでおくと安心です。

次にラベル設計です。Exporterから収集したメトリクスにはinstanceやjobといったラベルが自動付与されますが、これに加えてenvironment: productionやteam: infraのような独自ラベルをexternal_labelsで付与しておくと、後からの絞り込みクエリが格段に書きやすくなります。ラベルの種類を増やしすぎるとカーディナリティ（組み合わせ数）が爆発的に増加し、クエリのパフォーマンスが低下する原因になるため、1メトリクスあたりのラベル種類は10個程度までに抑えるのが目安とされています。

本番運用チェックリスト

  • □ データ保持期間とディスク容量のバランスを月1回確認しているか
  • □ Prometheus本体・Alertmanager・Exporterのバージョンアップ計画があるか
  • □ アラートルールを四半期ごとに見直し、しきい値の妥当性を再検証しているか
  • □ 設定ファイルをGitなどでバージョン管理しているか
  • □ Prometheus自体が停止した場合の二次監視（外形監視）を用意しているか

特に最後の項目は見落とされがちです。Prometheus自体がダウンしてしまうと監視システムそのものが機能停止するため、外部の死活監視サービスやBlackbox Exporterを別サーバーに配置し、Prometheus自身の生存確認を行う二重構成が推奨されています。

トラブルシューティング

実運用でよく遭遇するトラブルとその対処法を整理します。1つ目は「Targetsページでステータスが常にDOWN」というケースです。原因の多くはファイアウォールによるポートブロックか、Exporter側のプロセスが停止していることにあります。curl http://対象IP:9100/metricsを実行してレスポンスが返ってくるかを確認することで、ネットワーク経路の問題かExporter自体の問題かを切り分けられます。

2つ目は「アラートが発報されない」というトラブルです。これはPromQLの式自体は正しくても、rule_filesのパス指定が誤っている、あるいはAlertmanagerとの疎通ができていないケースが大半とされています。Prometheus Web UIの「Alerts」ページでルールが読み込まれているか、Statusの状態が「pending」のまま止まっていないかを確認すると原因が特定しやすくなります。

3つ目はディスク容量の逼迫によるPrometheus本体のクラッシュです。TSDBのデータブロックが肥大化すると、あるタイミングで書き込みエラーが発生し、サービスが停止することがあります。保持期間の見直しに加え、--storage.tsdb.retention.sizeオプションでディスク使用量に上限を設けておくことで、容量超過による突発停止を回避できるとされています。

よくあるエラーメッセージ一覧

エラー内容主な原因対処法
context deadline exceededscrape_timeoutの超過タイムアウト値を延長、またはExporter側の負荷軽減
connection refusedExporterプロセス未起動systemctl statusでプロセス確認・再起動
out of order sampleサーバー間の時刻ずれNTPでの時刻同期設定

よくある質問

Q1. Prometheusの導入は無料ですか？
A. Prometheus本体・Node Exporter・Grafanaはいずれもオープンソースで無料で利用できます。サーバー費用やクラウドの利用料金は別途発生します。

Q2. Prometheusだけで死活監視は完結しますか？
A. 実務ではPrometheus単体ではなく、Exporter・Alertmanager・Grafanaを組み合わせた構成が一般的とされています。通知やグラフ表示にはこれらの周辺ツールが必要です。

Q3. Zabbixから移行するメリットはありますか？
A. Kubernetes環境やマイクロサービス構成であればPromQLと動的サービスディスカバリーの恩恵が大きく、移行メリットがあるとされています。一方、GUI中心の運用に慣れているチームでは学習コストが発生する点に注意が必要です。

Q4. アラートが多すぎて対応しきれません。どうすればいいですか？
A. for句で猶予時間を設ける、Alertmanagerのgroup_byで通知を集約する、しきい値を段階的（warning/critical）に分けるといった調整が有効とされています。

Q5. Prometheusのデータ保持期間はどれくらいが適切ですか？
A. 一般的には30日〜90日程度が目安とされていますが、ディスク容量や分析要件によって調整が必要です。長期保存が必要な場合はThanosやCortexなどの長期ストレージ連携ツールを検討する運用もあります。

環境ごとに最適なしきい値やラベル設計は異なるため、まずは1台の検証サーバーでNode ExporterとPrometheusを試験導入し、実際のメトリクス値を確認しながら閾値を調整していく進め方が現場では取られています。

本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前にテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営