サーバーやアプリケーションを運用していると、「今、システムは正常に動いているのか？」「リソースは足りているのか？」といった疑問が常につきまといます。特に、マイクロサービスやコンテナ環境では、監視すべき対象が爆発的に増えるため、従来の監視ツールでは対応が困難になってきました。
そこで登場したのがPrometheus（プロメテウス）です。PrometheusはSoundCloudで開発され、現在はCloud Native Computing Foundation（CNCF）のプロジェクトとして、Kubernetesに次いで2番目に卒業（Graduated）した成熟したオープンソース監視ツールなんです。
Prometheusの最大の特徴は、時系列データベースを内蔵し、メトリクス（測定値）を効率的に収集・保存・クエリできること。そして、Pull型のアーキテクチャにより、動的に変化するクラウドネイティブ環境でも柔軟に対応できます。CPU使用率、メモリ使用量、HTTPリクエスト数、レスポンス時間など、あらゆるメトリクスを収集して可視化・アラート通知が可能です。
この記事では、Prometheusの基本から、実際の導入方法、Grafanaとの連携、アラート設定まで、初心者の方にも分かりやすく解説していきます！
Prometheusとは？基本概念を理解する
まず、Prometheusが何なのか、基本から押さえましょう。
Prometheusの定義
Prometheus（プロメテウス）は、オープンソースのシステム監視およびアラートツールキットです。
主な特徴：
- 開発元： SoundCloud（2012年）→ CNCF
- ライセンス： Apache License 2.0
- 言語： Go言語
- 公式サイト： https://prometheus.io/
- 現在のステータス： CNCF Graduated Project（卒業プロジェクト）
- 主な用途： サーバー監視、コンテナ監視、アプリケーション監視
時系列データベース（TSDB）
Prometheusの心臓部：
Prometheusは時系列データベース（Time Series Database）を内蔵しています。
時系列データとは：
時刻と値のペアのデータ
例：
2025-10-26 10:00:00 → CPU使用率 45%
2025-10-26 10:00:15 → CPU使用率 48%
2025-10-26 10:00:30 → CPU使用率 52%
2025-10-26 10:00:45 → CPU使用率 47%
...特徴：
- 時刻をキーとしたデータ
- 大量のメトリクスを効率的に保存
- 高速なクエリ処理
- 自動的に古いデータを削減（デフォルト15日保存）
メトリクス（Metrics）
監視対象の測定値：
インフラメトリクス：
- CPU使用率
- メモリ使用量
- ディスクI/O
- ネットワークトラフィック
- ディスク容量
アプリケーションメトリクス：
- HTTPリクエスト数
- レスポンス時間
- エラー率
- データベースクエリ時間
- ビジネスメトリクス（売上、ユーザー登録数など）
例：
http_requests_total{method="GET", status="200"} 12543
http_requests_total{method="POST", status="200"} 3421
http_requests_total{method="GET", status="404"} 89
node_cpu_seconds_total{cpu="0", mode="idle"} 124536.78Prometheusの主な特徴とメリット
なぜPrometheusが選ばれるのか、その理由を見ていきましょう。
1. Pull型アーキテクチャ
従来のPush型との違い：
Push型（従来型、例：Graphite、InfluxDB）：
監視対象サーバー → データを送信 → 監視サーバー
(Push)
メリット:
- シンプル
- ファイアウォール越しに送信可能
デメリット:
- 監視サーバーがダウンすると気づかない
- 監視対象が増えると負荷が集中Pull型（Prometheus）：
Prometheusサーバー → データを取得 → 監視対象
(Pull)
メリット:
- 監視対象が応答しなければすぐ検知
- Prometheus側で収集を制御
- サービスディスカバリで動的に追加・削除
デメリット:
- ネットワーク接続が必要
- ファイアウォールの設定が必要2. サービスディスカバリ
動的な環境に対応：
従来型の問題：
静的な設定ファイル:
- server1.example.com
- server2.example.com
- server3.example.com
→ サーバーが増減するたびに手動更新
→ コンテナ環境では管理不可能Prometheusのサービスディスカバリ：
対応プラットフォーム:
- Kubernetes（最も一般的）
- AWS EC2/ECS/EKS
- Google Cloud
- Azure
- Consul
- Docker
- その他多数
→ 自動的に監視対象を発見
→ 設定不要でスケール例：Kubernetes環境
# Kubernetes上のすべてのPodを自動検出
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true3. 強力なクエリ言語（PromQL）
PromQL（Prometheus Query Language）：
基本的なクエリ：
# CPU使用率
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# HTTPリクエスト数（過去5分間の1秒あたりの平均）
rate(http_requests_total[5m])
# エラー率
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100
# メモリ使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100高度な集計：
# インスタンスごとのCPU使用率の合計
sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
# 上位5つの最も遅いエンドポイント
topk(5, http_request_duration_seconds{quantile="0.99"})
# 前週との比較
http_requests_total - http_requests_total offset 1w4. マルチディメンショナルデータモデル
ラベル（Labels）による柔軟な分類：
データの構造：
メトリクス名{ラベル1="値1", ラベル2="値2", ...} 数値
例：
http_requests_total{
method="GET",
path="/api/users",
status="200",
instance="web-server-1:8080"
} 12543利点：
同じメトリクスを様々な切り口で分析:
- メソッド別（GET, POST, PUT, DELETE）
- ステータスコード別（200, 404, 500）
- インスタンス別（server-1, server-2, server-3）
- パス別（/api/users, /api/products）
→ 柔軟なクエリが可能
→ ダッシュボードで自由に可視化5. アラート機能
AlertManagerとの統合：
アラートルールの定義：
groups:
- name: example
rules:
# CPU使用率が80%を超えたらアラート
- alert: HighCPUUsage
expr: node_cpu_usage > 80
for: 5m # 5分間継続したら
labels:
severity: warning
annotations:
summary: "High CPU usage on {{ $labels.instance }}"
description: "CPU usage is {{ $value }}%"
# メモリ使用率が90%を超えたらアラート
- alert: HighMemoryUsage
expr: node_memory_usage > 90
for: 5m
labels:
severity: critical
annotations:
summary: "High memory usage on {{ $labels.instance }}"通知先：
- Slack
- PagerDuty
- Webhook（カスタム通知）
- その他多数
6. エコシステムが充実
豊富なExporter：
Exporterは、既存のシステムからPrometheus形式でメトリクスを公開するツールです。
公式・準公式Exporter：
- Node Exporter：Linux/Unixサーバーのメトリクス
- Blackbox Exporter：HTTPエンドポイントの監視
- MySQL Exporter：MySQLのメトリクス
- PostgreSQL Exporter：PostgreSQLのメトリクス
- Redis Exporter：Redisのメトリクス
- Nginx Exporter：Nginxのメトリクス
- その他数百種類
Prometheusのアーキテクチャ
Prometheusの内部構造を理解しましょう。
全体構成図
┌─────────────────────────────────────────────────────┐
│ │
│ 監視対象（Targets） │
│ ├─ Webサーバー（Node Exporter） │
│ ├─ アプリケーション（/metrics エンドポイント） │
│ ├─ データベース（MySQL Exporter） │
│ └─ その他のサービス │
│ ↑ ↑ ↑ │
│ │ │ │ Pull（メトリクス収集） │
└───────────┼─┼─┼─────────────────────────────────────┘
│ │ │
┌──────┴─┴─┴──────────┐
│ │
│ Prometheus Server │
│ ├─ Retrieval │ ← メトリクス収集
│ ├─ TSDB │ ← データ保存
│ ├─ HTTP Server │ ← API/UI提供
│ └─ Rule Engine │ ← アラート評価
│ │
└────────┬─────────┬───┘
│ │
│ └─────────→ [AlertManager] → 通知
│ (Email, Slack等)
│
└─────────→ [Grafana] → ダッシュボード
可視化主要コンポーネント
1. Prometheus Server
役割：
- メトリクスの収集（Scraping）
- データの保存（TSDB）
- クエリ処理（PromQL）
- アラートルールの評価
主要な機能：
Retrieval（収集）:
- 設定されたターゲットからメトリクスを定期的に取得
- デフォルト: 15秒ごと
Storage（保存）:
- 時系列データベースに保存
- デフォルト保存期間: 15日
- データ圧縮により効率的に保存
PromQL Engine:
- クエリを実行
- データの集計・計算
Rule Engine:
- アラートルールを評価
- 条件に合致したらAlertManagerに送信2. Exporters
役割：
既存のシステムをPrometheus対応にする
Node Exporterの例：
# Node Exporterを起動
./node_exporter
# http://localhost:9100/metrics にアクセスすると
# テキスト形式でメトリクスが表示される
# 出力例:
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 124536.78
node_cpu_seconds_total{cpu="0",mode="system"} 5234.12
node_cpu_seconds_total{cpu="0",mode="user"} 8765.43
# HELP node_memory_MemTotal_bytes Memory information field MemTotal_bytes.
# TYPE node_memory_MemTotal_bytes gauge
node_memory_MemTotal_bytes 8.589934592e+093. Pushgateway
役割：
短時間実行されるジョブ（バッチ処理など）のメトリクスを受け取る
使用例：
# バッチジョブからメトリクスをPush
echo "batch_job_duration_seconds 45.2" | curl --data-binary @- \
http://pushgateway:9091/metrics/job/backup_job注意：
- 通常のサービスにはPull型を推奨
- バッチジョブやCronジョブなど、短命なプロセス専用
4. AlertManager
役割：
アラートの管理と通知
機能：
- グルーピング：類似アラートをまとめる
- 抑制（Inhibition）：上位のアラートが発生したら下位を抑制
- 沈黙（Silencing）：一時的にアラートを無効化
- 通知ルーティング：条件に応じて通知先を変更
5. Grafana
役割：
可視化とダッシュボード作成
PrometheusとGrafanaの関係：
Prometheus: データ収集・保存・クエリ
Grafana: データを美しく可視化
→ 最強の組み合わせ！メトリクスの4つの型
Prometheusは4種類のメトリクスタイプをサポートしています。
1. Counter（カウンター）
単調増加する値：
特徴：
- 増加のみ（減少しない）
- リセット時は0に戻る
- 累積値
用途：
- HTTPリクエスト数
- エラー発生回数
- 処理済みジョブ数
- 送信バイト数
例：
http_requests_total 12543
http_requests_total 12544 # 1増加
http_requests_total 12545 # さらに1増加
http_requests_total 0 # サーバー再起動でリセット
http_requests_total 1 # また増加開始PromQLでの使い方：
# 1秒あたりのリクエスト数（rate関数）
rate(http_requests_total[5m])
# 5分間の増加量
increase(http_requests_total[5m])2. Gauge（ゲージ）
増減する値：
特徴：
- 上下に変動
- 現在の状態を表す
- スナップショット
用途：
- CPU使用率
- メモリ使用量
- 現在の接続数
- 温度
- キューの長さ
例：
node_memory_MemAvailable_bytes 4294967296 # 4GB
node_memory_MemAvailable_bytes 3221225472 # 3GB（減少）
node_memory_MemAvailable_bytes 5368709120 # 5GB（増加）PromQLでの使い方：
# そのまま使用
node_memory_MemAvailable_bytes
# 割合を計算
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 1003. Histogram（ヒストグラム）
値の分布を記録：
特徴：
- 複数のバケット（区間）に分類
- 累積カウンター
- 合計値とカウント数も記録
用途：
- レスポンス時間の分布
- リクエストサイズの分布
例：
# レスポンス時間のヒストグラム
http_request_duration_seconds_bucket{le="0.1"} 9500 # 0.1秒以下: 9500件
http_request_duration_seconds_bucket{le="0.5"} 9950 # 0.5秒以下: 9950件
http_request_duration_seconds_bucket{le="1.0"} 9990 # 1.0秒以下: 9990件
http_request_duration_seconds_bucket{le="+Inf"} 10000 # すべて: 10000件
http_request_duration_seconds_sum 1234.5 # 合計時間
http_request_duration_seconds_count 10000 # リクエスト数PromQLでの使い方：
# 平均レスポンス時間
rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])
# 95パーセンタイル（推定）
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))4. Summary（サマリー）
クライアント側で計算された統計：
特徴：
- クライアント側でパーセンタイル計算
- 合計値とカウント数も記録
- Histogramより計算コストが高い
用途：
- レスポンス時間の統計
- リクエストサイズの統計
例：
http_request_duration_seconds{quantile="0.5"} 0.123 # 50パーセンタイル（中央値）
http_request_duration_seconds{quantile="0.9"} 0.234 # 90パーセンタイル
http_request_duration_seconds{quantile="0.99"} 0.456 # 99パーセンタイル
http_request_duration_seconds_sum 1234.5
http_request_duration_seconds_count 10000HistogramとSummaryの違い：
| 項目 | Histogram | Summary |
|---|---|---|
| 計算場所 | サーバー側（Prometheus） | クライアント側 |
| パーセンタイル精度 | 推定値 | 正確な値 |
| 集計可能性 | 複数インスタンスで集計可能 | 集計不可 |
| パフォーマンス | 低負荷 | 高負荷 |
| 推奨 | ✅ 一般的にはこちら | 特殊な用途のみ |
Prometheusの導入方法
実際にPrometheusをインストールして使ってみましょう。
方法1：バイナリで直接実行
Linux/macOSの場合：
# Prometheusをダウンロード
wget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz
# 解凍
tar xvfz prometheus-2.48.0.linux-amd64.tar.gz
cd prometheus-2.48.0.linux-amd64
# 設定ファイルを確認
cat prometheus.yml
# Prometheusを起動
./prometheus --config.file=prometheus.yml
# ブラウザで http://localhost:9090 にアクセス基本的な設定ファイル（prometheus.yml）：
global:
scrape_interval: 15s # メトリクス収集間隔
evaluation_interval: 15s # ルール評価間隔
# AlertManagerの設定（オプション）
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093
# アラートルールファイルの指定
rule_files:
# - "alerts.yml"
# メトリクス収集対象の設定
scrape_configs:
# Prometheus自身を監視
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# Node Exporterを監視
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']方法2：Dockerで実行
Docker Composeを使用：
# docker-compose.yml
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
ports:
- "9090:9090"
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus-data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
restart: unless-stopped
node-exporter:
image: prom/node-exporter:latest
container_name: node-exporter
ports:
- "9100:9100"
restart: unless-stopped
grafana:
image: grafana/grafana:latest
container_name: grafana
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
volumes:
- grafana-data:/var/lib/grafana
restart: unless-stopped
volumes:
prometheus-data:
grafana-data:起動：
docker-compose up -dアクセス：
- Prometheus UI: http://localhost:9090
- Node Exporter: http://localhost:9100/metrics
- Grafana: http://localhost:3000 （admin/admin）
方法3：Kubernetesにデプロイ
Helm Chartを使用（最も簡単）：
# Helmリポジトリを追加
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# Prometheusをインストール
helm install prometheus prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace
# Pod確認
kubectl get pods -n monitoring
# Grafanaにアクセス（ポートフォワード）
kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80
# ブラウザで http://localhost:3000 にアクセス
# 初期パスワード: admin / prom-operator含まれるコンポーネント：
- Prometheus Operator
- Prometheus Server
- AlertManager
- Grafana
- Node Exporter
- kube-state-metrics
- 多数の事前設定されたダッシュボード
Node Exporterでサーバー監視
実際にLinuxサーバーを監視してみましょう。
Node Exporterのインストール
# ダウンロード
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
# 解凍
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
cd node_exporter-1.7.0.linux-amd64
# 起動
./node_exporter
# メトリクスを確認
curl http://localhost:9100/metricssystemdサービスとして登録
# ユーザー作成
sudo useradd --no-create-home --shell /bin/false node_exporter
# バイナリを配置
sudo cp node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter
# systemdサービスファイル作成
sudo nano /etc/systemd/system/node_exporter.serviceサービスファイルの内容：
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.targetサービス起動：
sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter
sudo systemctl status node_exporterPrometheusに設定を追加
# prometheus.yml に追加
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
labels:
instance: 'my-server'Prometheusを再起動：
sudo systemctl restart prometheus収集されるメトリクス
主要なメトリクス：
CPU：
# CPU使用率（idle以外）
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# CPUコア別の使用率
rate(node_cpu_seconds_total{mode!="idle"}[5m])メモリ：
# メモリ使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100
# スワップ使用量
node_memory_SwapTotal_bytes - node_memory_SwapFree_bytesディスク：
# ディスク使用率
(node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100
# ディスクI/O
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])ネットワーク：
# ネットワーク受信バイト数
rate(node_network_receive_bytes_total[5m])
# ネットワーク送信バイト数
rate(node_network_transmit_bytes_total[5m])アプリケーションの監視
実際のアプリケーションにメトリクスを組み込んでみましょう。
Python（Flask）の例
必要なライブラリ：
pip install prometheus-client flaskアプリケーションコード：
from flask import Flask
from prometheus_client import Counter, Histogram, Gauge, generate_latest, REGISTRY
import time
import random
app = Flask(__name__)
# メトリクスの定義
REQUEST_COUNT = Counter(
'http_requests_total',
'Total HTTP requests',
['method', 'endpoint', 'status']
)
REQUEST_DURATION = Histogram(
'http_request_duration_seconds',
'HTTP request duration',
['method', 'endpoint']
)
ACTIVE_REQUESTS = Gauge(
'http_requests_in_progress',
'Number of requests in progress'
)
# ミドルウェアでメトリクスを記録
@app.before_request
def before_request():
ACTIVE_REQUESTS.inc()
request._prometheus_start_time = time.time()
@app.after_request
def after_request(response):
request_duration = time.time() - request._prometheus_start_time
REQUEST_COUNT.labels(
method=request.method,
endpoint=request.endpoint or 'unknown',
status=response.status_code
).inc()
REQUEST_DURATION.labels(
method=request.method,
endpoint=request.endpoint or 'unknown'
).observe(request_duration)
ACTIVE_REQUESTS.dec()
return response
# エンドポイント
@app.route('/')
def index():
time.sleep(random.uniform(0.01, 0.1)) # ランダムな遅延
return "Hello, World!"
@app.route('/api/users')
def users():
time.sleep(random.uniform(0.05, 0.2))
return {"users": ["Alice", "Bob", "Charlie"]}
# Prometheusメトリクスエンドポイント
@app.route('/metrics')
def metrics():
return generate_latest(REGISTRY)
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8000)Prometheusに設定追加：
scrape_configs:
- job_name: 'flask-app'
static_configs:
- targets: ['localhost:8000']Node.js（Express）の例
必要なパッケージ：
npm install express prom-clientアプリケーションコード：
const express = require('express');
const client = require('prom-client');
const app = express();
const register = new client.Registry();
// デフォルトメトリクスを収集（CPU、メモリなど）
client.collectDefaultMetrics({ register });
// カスタムメトリクス
const httpRequestCounter = new client.Counter({
name: 'http_requests_total',
help: 'Total HTTP requests',
labelNames: ['method', 'route', 'status'],
registers: [register]
});
const httpRequestDuration = new client.Histogram({
name: 'http_request_duration_seconds',
help: 'HTTP request duration',
labelNames: ['method', 'route'],
registers: [register]
});
// ミドルウェア
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
const duration = (Date.now() - start) / 1000;
httpRequestCounter.inc({
method: req.method,
route: req.route?.path || 'unknown',
status: res.statusCode
});
httpRequestDuration.observe({
method: req.method,
route: req.route?.path || 'unknown'
}, duration);
});
next();
});
// エンドポイント
app.get('/', (req, res) => {
res.send('Hello, World!');
});
app.get('/api/users', (req, res) => {
res.json({ users: ['Alice', 'Bob', 'Charlie'] });
});
// メトリクスエンドポイント
app.get('/metrics', async (req, res) => {
res.set('Content-Type', register.contentType);
res.end(await register.metrics());
});
app.listen(8000, () => {
console.log('Server running on port 8000');
});Grafanaとの連携
Prometheusのデータを美しく可視化しましょう。
Grafanaのセットアップ
1. データソースの追加：
Grafanaにログイン
→ Configuration（設定）
→ Data Sources
→ Add data source
→ Prometheus を選択
→ URL: http://localhost:9090
→ Save & Test2. ダッシュボードの作成
新規ダッシュボード：
+ アイコン
→ Dashboard
→ Add new panelパネル設定例（CPU使用率）：
Query:
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Panel title: CPU Usage
Unit: percent (0-100)
Legend: {{instance}}3. 既存のダッシュボードをインポート
人気のダッシュボード：
Node Exporter Full：
Dashboard ID: 1860
https://grafana.com/grafana/dashboards/1860インポート手順：
+ アイコン
→ Import
→ Dashboard ID に 1860 を入力
→ Load
→ Prometheus data source を選択
→ Importその他の推奨ダッシュボード：
- Kubernetes Cluster Monitoring（ID: 7249）
- Docker Container & Host Metrics（ID: 179）
- MySQL Overview（ID: 7362）
- Nginx Overview（ID: 12708）
4. 便利なパネル例
HTTPリクエスト数：
sum(rate(http_requests_total[5m])) by (status)レスポンス時間の95パーセンタイル：
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))エラー率：
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100メモリ使用率（複数サーバー）：
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100AlertManagerでアラート設定
問題が発生したら即座に通知を受け取りましょう。
AlertManagerのインストール
# ダウンロード
wget https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz
# 解凍
tar xvfz alertmanager-0.26.0.linux-amd64.tar.gz
cd alertmanager-0.26.0.linux-amd64
# 設定ファイル作成
nano alertmanager.ymlAlertManagerの設定
# alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: ['alertname', 'instance']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'email-notifications'
# 重要度別のルーティング
routes:
- match:
severity: critical
receiver: 'pagerduty-critical'
- match:
severity: warning
receiver: 'slack-warnings'
receivers:
# Email通知
- name: 'email-notifications'
email_configs:
- to: 'admin@example.com'
from: 'prometheus@example.com'
smarthost: 'smtp.gmail.com:587'
auth_username: 'your-email@gmail.com'
auth_password: 'your-app-password'
# Slack通知
- name: 'slack-warnings'
slack_configs:
- api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
channel: '#alerts'
title: 'Prometheus Alert'
text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}'
# PagerDuty通知
- name: 'pagerduty-critical'
pagerduty_configs:
- service_key: 'YOUR_PAGERDUTY_KEY'
inhibit_rules:
# ノードダウン時は他のアラートを抑制
- source_match:
severity: 'critical'
alertname: 'NodeDown'
target_match:
instance: '.*'
equal: ['instance']AlertManagerを起動：
./alertmanager --config.file=alertmanager.ymlアラートルールの定義
# alerts.yml
groups:
- name: node_alerts
interval: 30s
rules:
# CPU使用率アラート
- alert: HighCPUUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage on {{ $labels.instance }}"
description: "CPU usage is {{ $value | humanize }}%"
# メモリ使用率アラート
- alert: HighMemoryUsage
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
for: 5m
labels:
severity: critical
annotations:
summary: "High memory usage on {{ $labels.instance }}"
description: "Memory usage is {{ $value | humanize }}%"
# ディスク容量アラート
- alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 10
for: 5m
labels:
severity: warning
annotations:
summary: "Low disk space on {{ $labels.instance }}"
description: "Only {{ $value | humanize }}% remaining on {{ $labels.mountpoint }}"
# サービスダウンアラート
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Service {{ $labels.job }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."
# HTTPエラー率アラート
- alert: HighErrorRate
expr: (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))) * 100 > 5
for: 5m
labels:
severity: critical
annotations:
summary: "High HTTP error rate"
description: "Error rate is {{ $value | humanize }}%"Prometheusの設定に追加：
# prometheus.yml
rule_files:
- "alerts.yml"
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093他の監視ツールとの比較
Prometheusと他のツールの違いを見てみましょう。
比較表
| 項目 | Prometheus | Grafana | Zabbix | Nagios | Datadog |
|---|---|---|---|---|---|
| タイプ | メトリクス収集・保存 | 可視化 | 統合監視 | 統合監視 | SaaS監視 |
| アーキテクチャ | Pull型 | N/A | Push/Pull | Push | Push |
| 時系列DB | 内蔵 | なし | あり | なし | あり |
| クラウドネイティブ | ✅ 最適 | ✅ | ❌ | ❌ | ✅ |
| 学習曲線 | 中 | 易 | 難 | 難 | 易 |
| 料金 | 無料 | 無料 | 無料 | 無料 | 有料 |
| Kubernetes対応 | ✅ 最高 | ✅ | ⚠️ | ⚠️ | ✅ |
それぞれの特徴
Prometheus：
- ✅ クラウドネイティブに最適
- ✅ Pull型で動的環境に強い
- ✅ PromQLが強力
- ❌ 長期保存には別途ストレージが必要
- ❌ 可視化は別途Grafanaが必要
Zabbix：
- ✅ オンプレミスに強い
- ✅ 統合監視（ログ、メトリクス、トレース）
- ✅ エージェントレス監視も可能
- ❌ 設定が複雑
- ❌ クラウドネイティブには不向き
Nagios：
- ✅ 歴史が長く実績豊富
- ✅ プラグインが豊富
- ❌ 古い設計
- ❌ 時系列データの扱いが弱い
- ❌ UIが古い
Datadog：
- ✅ すぐ使える（SaaS）
- ✅ 統合監視（APM、ログ、インフラ）
- ✅ 美しいUI
- ❌ 高額（サーバー数で課金）
- ❌ ベンダーロックイン
よくある質問（FAQ）
Q1. PrometheusとGrafanaはどちらが必要ですか？
回答：
両方使うのが一般的です。
役割分担：
- Prometheus：データ収集・保存・クエリ
- Grafana：可視化・ダッシュボード
Prometheus単体でも：
- 簡易的なWebUIあり
- クエリは実行可能
- ただし可視化は弱い
推奨：
Prometheus + Grafana の組み合わせが最強です。
Q2. Prometheusのデータ保存期間は？
回答：
デフォルトは15日間です。
変更方法：
./prometheus --storage.tsdb.retention.time=30d # 30日間
./prometheus --storage.tsdb.retention.size=50GB # 50GBまで長期保存には：
- Thanos：Prometheusの長期保存拡張
- Cortex：マルチテナント対応
- VictoriaMetrics：高性能な代替TSDB
- InfluxDB：別の時系列DB
Q3. Prometheusは何台まで監視できますか？
回答：
数千〜数万のターゲットを1台で監視可能です。
スケーラビリティ：
- 単一インスタンス：数千ターゲット
- Federation（連邦）：複数Prometheusを階層化
- Thanos/Cortex：水平スケーリング
例：
[Central Prometheus]
↑ ↑ ↑
┌───────┴────┼────┴───────┐
│ │ │
[Prometheus 1] [Prometheus 2] [Prometheus 3]
(Region A) (Region B) (Region C)
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
サーバー群 サーバー群 サーバー群Q4. PrometheusはログやTraceも扱えますか？
回答：
いいえ、Prometheusはメトリクス専門です。
オブザーバビリティの3本柱：
1. Metrics（メトリクス） → Prometheus
2. Logs（ログ） → Loki, Elasticsearch
3. Traces（トレース） → Jaeger, Zipkin統合ソリューション：
- Grafana Loki：Prometheusライクなログ収集
- Grafana Tempo：分散トレーシング
- Grafanaで統合可視化
Q5. Prometheusは無料ですか？
回答：
はい、完全に無料でオープンソースです。
ライセンス：
- Apache License 2.0
- 商用利用も可能
- 改変・再配布も自由
費用が発生する可能性：
- インフラコスト（サーバー、ストレージ）
- 運用コスト（人件費）
- マネージドサービス利用時（AWS、GCP等）
Q6. Windows Serverも監視できますか？
回答：
はい、Windows Exporterを使います。
インストール：
# ダウンロード
# https://github.com/prometheus-community/windows_exporter
# インストーラーを実行
# サービスとして自動起動
# メトリクス確認
http://localhost:9182/metrics収集されるメトリクス：
- CPU使用率
- メモリ使用量
- ディスク使用量
- ネットワーク
- Windowsサービスの状態
- IIS（オプション）
Q7. クラウドのマネージドサービスはありますか？
回答：
はい、主要クラウドプロバイダーが提供しています。
AWS：
- Amazon Managed Service for Prometheus（AMP）
- フルマネージド
- 自動スケーリング
Google Cloud：
- Google Cloud Managed Service for Prometheus
- GKE統合
Azure：
- Azure Monitor managed service for Prometheus
- AKS統合
メリット：
- 運用不要
- 自動スケール
- 高可用性
デメリット：
- 費用がかかる
- ベンダーロックイン
まとめ：Prometheusは現代の監視の標準
Prometheusは、クラウドネイティブ時代に最適化された強力な監視ツールです。
この記事のポイント：
- PrometheusはCNCFのGraduated Project
- 時系列データベースを内蔵
- Pull型アーキテクチャで動的環境に最適
- PromQLで強力なクエリが可能
- サービスディスカバリで自動検出
- マルチディメンショナルなデータモデル
- 豊富なExporterで様々なシステムを監視
- Grafanaとの組み合わせが最強
- AlertManagerでアラート通知
- Kubernetesとの親和性が高い
- 完全に無料でオープンソース
Prometheusは、特にKubernetesやマイクロサービス環境での監視において、事実上の業界標準となっています。
従来の監視ツールと異なり、動的に変化するコンテナ環境でも柔軟に対応でき、強力なクエリ言語（PromQL）により、複雑な分析も可能です。
Grafanaとの組み合わせにより、美しいダッシュボードで視覚的にシステムの状態を把握でき、AlertManagerにより迅速な問題対応が可能になります。
クラウドネイティブなシステムを運用するなら、Prometheusは必ず習得すべきツールです。ぜひこの機会に導入して、システムの可観測性（Observability）を向上させましょう！
コメント