Prometheus は、公式のバイナリを専用ユーザーと systemd で常駐させ、prometheus.yml に「どこから・どの間隔で取得するか」を書けば動き始めます。この記事では、Linux サーバーへのインストール手順に加えて、設定ファイルの各セクションの意味、データの保存期間とディスク容量の見積もり、アラートルールの置き方、そして 9090 番ポートを外部にさらさないための設定までを説明します。
Prometheus の動き方を押さえる
Prometheus は、監視対象が公開している /metrics に一定間隔で HTTP アクセスし、取得した値を自分のディスク（TSDB と呼ばれる時系列データベース）に保存します。監視対象から送ってもらうのではなく、Prometheus が取りに行く「プル型」です。
そのため、設定の中心は「取得先の一覧（ターゲット）」になります。Linux の CPU やメモリを取るなら各サーバーに node_exporter を、外部から Web サイトの応答を確かめるなら blackbox_exporter を置き、それらを Prometheus のターゲットに登録します。グラフ表示は Grafana、通知は Alertmanager という別のソフトウェアが担当します。
インストールする
Debian/Ubuntu には prometheus パッケージもありますが、公式の最新版より古いことが多く、Prometheus 3 系で変わった点が反映されていない場合があります。ここでは公式のバイナリを使います。
VERSION="3.5.0" # 例。GitHub の prometheus/prometheus のリリースページで確認した版に置き換える
ARCH="linux-amd64"
cd /tmp
curl -LO "https://github.com/prometheus/prometheus/releases/download/v${VERSION}/prometheus-${VERSION}.${ARCH}.tar.gz"
curl -LO "https://github.com/prometheus/prometheus/releases/download/v${VERSION}/sha256sums.txt"
grep "prometheus-${VERSION}.${ARCH}.tar.gz" sha256sums.txt | sha256sum -c -
tar xzf "prometheus-${VERSION}.${ARCH}.tar.gz"
sudo install -m 0755 "prometheus-${VERSION}.${ARCH}/prometheus" /usr/local/bin/
sudo install -m 0755 "prometheus-${VERSION}.${ARCH}/promtool" /usr/local/bin/
prometheus --versionチェックサムの確認で OK と表示されることを確かめてから先に進みます。Prometheus はおおむね6週間ごとに新しい版が出ており、長期サポート（LTS）として指定される版もあります（2026年10月現在）。頻繁な更新を避けたい場合は LTS 版を選ぶとよいでしょう。
続いて、ログインできない専用ユーザーと、設定・データ用のディレクトリを作ります。
sudo useradd --system --no-create-home --shell /usr/sbin/nologin prometheus
sudo mkdir -p /etc/prometheus/rules /etc/prometheus/targets /var/lib/prometheus
sudo cp "prometheus-${VERSION}.${ARCH}/prometheus.yml" /etc/prometheus/
sudo chown -R prometheus:prometheus /var/lib/prometheus設定ファイルは root が所有し、Prometheus は読むだけ、データディレクトリは Prometheus が書き込める、という分け方にしておくと、万一プロセスが乗っ取られても設定を書き換えられにくくなります。
systemd で常駐させる
# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/var/lib/prometheus \
--storage.tsdb.retention.time=30d \
--web.listen-address=127.0.0.1:9090
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable --now prometheus
systemctl status prometheus
curl -s http://127.0.0.1:9090/-/ready--web.listen-address=127.0.0.1:9090 にしているのは、Prometheus の画面と API をサーバーの外から直接見られないようにするためです。理由は後の「9090番ポートを保護する」で説明します。起動しない場合は journalctl -u prometheus -n 50 でエラーを確認します。多いのは、設定ファイルの YAML のインデント誤り、データディレクトリの所有者が prometheus になっていない、ポートの重複、の3つです。
ExecReload を書いておくと、設定変更後に systemctl reload prometheus で再起動せずに反映できます。Prometheus は SIGHUP を受け取ると設定を読み直します。
prometheus.yml の基本構成
設定ファイルは大きく4つのセクションに分かれます。
# /etc/prometheus/prometheus.yml
global:
scrape_interval: 30s # 取得の間隔（既定は1分）
evaluation_interval: 30s # ルールを評価する間隔
external_labels:
env: production
rule_files:
- /etc/prometheus/rules/*.yml
alerting:
alertmanagers:
- static_configs:
- targets: ["127.0.0.1:9093"]
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ["127.0.0.1:9090"]
- job_name: "node"
file_sd_configs:
- files:
- /etc/prometheus/targets/node_*.ymlglobal は全体の既定値です。scrape_interval を短くすると細かい変化を捉えられますが、保存するデータ量もそのぶん増えます。中小規模のサイトなら 15〜60 秒の範囲が扱いやすいでしょう。external_labels は、複数の Prometheus を使い分けるときや、Alertmanager の通知で「どの環境の警告か」を区別するのに使います。
rule_files は、アラートルールや集計ルールを書いたファイルの場所です。ワイルドカードが使えるので、ルールを用途ごとのファイルに分けておけます。
alerting は、警告を送る Alertmanager の場所です。Alertmanager をまだ入れていなければ、このセクションは省略してかまいません。
scrape_configs が取得先の一覧です。job_name ごとに取得先をまとめます。最初の prometheus ジョブは Prometheus 自身のメトリクスで、Prometheus が正常に動いているかの確認に使えます。
ターゲットは別ファイルに分けると管理しやすい
static_configs にサーバーを直接並べると、追加のたびに設定ファイル全体を触ることになります。file_sd_configs を使うと、ターゲットの一覧を別ファイルに切り出せます。このファイルは変更が検知されて自動で読み直されるため、Prometheus の再読み込みも要りません。
# /etc/prometheus/targets/node_web.yml
- targets:
- "192.0.2.10:9100"
- "192.0.2.11:9100"
labels:
role: "web"アラートルールを置く
監視の最初の一歩として、「取得できなくなったターゲットがある」ことを検知するルールを置いておくと役立ちます。
# /etc/prometheus/rules/basic.yml
groups:
- name: basic
rules:
- alert: TargetDown
expr: up == 0
for: 5m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }}（{{ $labels.job }}）から5分以上取得できていません"up は、Prometheus が取得に成功したターゲットは 1、失敗したターゲットは 0 になる組み込みのメトリクスです。for: 5m を付けると、一時的な通信の揺れでは発火せず、5分続いたときだけ警告になります。
設定やルールを変更したら、反映する前に文法を確認します。誤った設定で再読み込みすると、Prometheus は新しい設定を受け付けず古い設定のまま動き続けるため、変更が効いていないことに気づきにくくなります。
promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/rules/basic.yml
sudo systemctl reload prometheus保存期間とディスク容量の見積もり
保存期間は --storage.tsdb.retention.time で指定し、指定しなければ15日です。容量で上限を決めたい場合は --storage.tsdb.retention.size=20GB のように指定でき、両方を指定すると先に達した方で古いデータが削除されます。
必要なディスク容量は、おおよそ「1秒あたりに取り込むサンプル数 × 保存秒数 × 1サンプルあたりのバイト数」で見積もれます。公式ドキュメントでは1サンプルあたり1〜2バイト程度が目安とされています。取り込み量は、Prometheus 自身のメトリクスで確認できます。
rate(prometheus_tsdb_head_samples_appended_total[5m])ディスクが一杯になると取得が止まるため、データディレクトリはシステム領域と分けたディスクに置くか、retention.size で上限を決めておくと安心です。
9090番ポートを保護する
Prometheus の画面と API には、既定では認証がありません。外部から見られると、監視対象のホスト名や IP、構成の情報がそのまま読み取れてしまいます。
- 同じサーバーから使うなら 先の例のように
127.0.0.1で待ち受け、Grafana も同じサーバーに置きます。 - 手元の PC から画面を見るなら SSH のポートフォワーディング（
ssh -L 9090:127.0.0.1:9090 user@server）を使うと、ポートを開けずに済みます。 - ネットワーク越しに公開するなら ファイアウォールで接続元を限定したうえで、
--web.config.fileで TLS と Basic 認証を設定するか、認証付きのリバースプロキシを前段に置きます。Basic 認証のパスワードは bcrypt のハッシュで書きます。
あわせて、HTTP 経由で設定の再読み込みや終了ができる --web.enable-lifecycle、データを削除できる --web.enable-admin-api は、必要がなければ有効にしないでおきます。
動作を確認する
ブラウザ（またはポートフォワーディング先）で Prometheus の画面を開き、ターゲットの一覧を表示する画面で各ターゲットが UP になっているかを確認します。Prometheus 3 系で画面が刷新されたため、メニューの表記や場所は版によって異なります。クエリ欄に up と入力して、ターゲットごとに 1 が返れば取得は成功しています。
まとめ
- Prometheus は公式バイナリを専用ユーザーと systemd で常駐させ、チェックサムを確認してから導入します。
prometheus.ymlは global・rule_files・alerting・scrape_configs の4つで構成し、ターゲットはfile_sd_configsで別ファイルにすると管理が楽になります。- 変更は
promtool checkで確認してからsystemctl reloadで反映します。 - 保存期間は既定で15日です。
retention.timeとretention.sizeで期間と容量を決めます。 - 9090番は既定で認証がないため、ローカルで待ち受けるか、接続元の制限と認証をかけます。