OSSモニタリング・アラート比較:Prometheus+Grafana vs Zabbix vs Checkmk でインフラ監視をセルフホスト
オープンソースラボ編集部 ・ 2026年6月13日
OSSモニタリング・アラート比較:Prometheus+Grafana vs Zabbix vs Checkmk でインフラ監視をセルフホスト
Datadog(月$15/ホスト〜)やNew Relic(月$49〜)に代わる、セルフホスト型のOSSインフラ監視ツールを比較します。Prometheus + Grafana(クラウドネイティブスタック)・Zabbix(エンタープライズ対応)・Checkmk(エージェントベース)は、サーバー・コンテナ・ネットワーク機器を監視してアラートを送るOSSの定番です。
OSSモニタリングを選ぶ理由
- コスト削減: Datadogの月$15/ホスト × 50台 = $750/月を、自社VPS代のみで代替
- データ保持期間: Datadogのデフォルト15日保持に対し、ローカルストレージの容量が許す限り保持可能
- カスタムメトリクス: 独自のビジネスメトリクス(注文数・エラー率・売上)を自由に追加
- オンプレ対応: インターネットに接続できない閉域環境のサーバー・産業機器の監視
- コンプライアンス: 機密性の高い監視データを外部SaaSに送らない
主要ツールの概要
Prometheus + Grafana
Cloud Native Computing Foundation(CNCF)の卒業プロジェクト。Kubernetes環境の標準監視スタックです。Prometheusがメトリクス収集(Pull型)、Grafanaが可視化・アラートを担当します。GitHubスターはPrometheus 56k+・Grafana 65k+。コンテナ・マイクロサービス・Kubernetes監視に最も適しています。
# Prometheus + Grafana をdocker-composeで起動
mkdir -p monitoring/prometheus monitoring/grafana
cat > monitoring/prometheus/prometheus.yml << 'EOF'
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']
rule_files:
- "alerts/*.yml"
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter:9100']
- job_name: 'cadvisor'
static_configs:
- targets: ['cadvisor:8080']
- job_name: 'app'
static_configs:
- targets: ['your-app:3000']
metrics_path: '/metrics'
EOF
# docker-compose.yml(Prometheus + Grafana + Alertmanager + Node Exporter)
version: "3"
services:
prometheus:
image: prom/prometheus:latest
restart: always
ports:
- "9090:9090"
volumes:
- ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
- ./prometheus/alerts:/etc/prometheus/alerts:ro
- prom_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=90d'
- '--web.enable-lifecycle'
grafana:
image: grafana/grafana:latest
restart: always
ports:
- "3000:3000"
volumes:
- grafana_data:/var/lib/grafana
environment:
GF_SECURITY_ADMIN_PASSWORD: your-admin-password
GF_USERS_ALLOW_SIGN_UP: "false"
GF_SMTP_ENABLED: "true"
GF_SMTP_HOST: smtp.sendgrid.net:587
GF_SMTP_USER: apikey
GF_SMTP_PASSWORD: SG.your-key
GF_SMTP_FROM_ADDRESS: monitor@yourcompany.com
alertmanager:
image: prom/alertmanager:latest
restart: always
ports:
- "9093:9093"
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
node-exporter:
image: prom/node-exporter:latest
restart: always
ports:
- "9100:9100"
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
command:
- '--path.procfs=/host/proc'
- '--path.sysfs=/host/sys'
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
cadvisor:
image: gcr.io/cadvisor/cadvisor:latest
restart: always
ports:
- "8080:8080"
volumes:
- /:/rootfs:ro
- /var/run:/var/run:ro
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
volumes:
prom_data:
grafana_data:
# prometheus/alerts/server.yml(アラートルールの例)
groups:
- name: server-alerts
rules:
# CPU使用率が90%超で5分継続したらアラート
- alert: HighCpuUsage
expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 5m
labels:
severity: warning
annotations:
summary: "CPU使用率が高い ({{ $labels.instance }})"
description: "CPU使用率 {{ $value | printf "%.1f" }}% が5分間継続しています"
# メモリ使用率85%超
- alert: HighMemoryUsage
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
for: 3m
labels:
severity: warning
annotations:
summary: "メモリ使用率が高い"
description: "メモリ使用率 {{ $value | printf "%.1f" }}%"
# ディスク使用率90%超
- alert: DiskUsageHigh
expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100 > 90
for: 1m
labels:
severity: critical
annotations:
summary: "ディスク容量不足 ({{ $labels.mountpoint }})"
description: "ディスク使用率 {{ $value | printf "%.1f" }}%"
# サービスダウン検知(5分以上スクレイプ失敗)
- alert: ServiceDown
expr: up == 0
for: 5m
labels:
severity: critical
annotations:
summary: "サービスダウン: {{ $labels.job }}"
description: "{{ $labels.instance }} が5分間応答していません"
# alertmanager.yml(Slack通知の設定)
global:
slack_api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
route:
group_by: ['alertname', 'instance']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'slack-alerts'
routes:
- match:
severity: critical
receiver: 'slack-critical'
receivers:
- name: 'slack-alerts'
slack_configs:
- channel: '#alerts'
title: '{{ .CommonAnnotations.summary }}'
text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
- name: 'slack-critical'
slack_configs:
- channel: '#alerts-critical'
color: 'danger'
title: '🚨 CRITICAL: {{ .CommonAnnotations.summary }}'
text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
Zabbix
1998年から開発されているエンタープライズ向け監視プラットフォームです。GitHubスター4k(公式リポジトリ)。SNMP・IPMI・JMX・エージェントレス監視に対応しており、ネットワーク機器・サーバー・VMware・クラウドを一元監視できます。Datadogより設定が複雑ですが、オンプレ環境やネットワーク機器の監視においては非常に強力です。
# Zabbixをdocker-composeで起動(PostgreSQLバックエンド)
version: "3"
services:
zabbix-server:
image: zabbix/zabbix-server-pgsql:ubuntu-7.0-latest
restart: always
depends_on:
- postgres
ports:
- "10051:10051"
environment:
DB_SERVER_HOST: postgres
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: your-password
POSTGRES_DB: zabbix
zabbix-web:
image: zabbix/zabbix-web-nginx-pgsql:ubuntu-7.0-latest
restart: always
depends_on:
- zabbix-server
- postgres
ports:
- "8081:8080"
environment:
DB_SERVER_HOST: postgres
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: your-password
POSTGRES_DB: zabbix
ZBX_SERVER_HOST: zabbix-server
PHP_TZ: Asia/Tokyo
zabbix-agent2:
image: zabbix/zabbix-agent2:ubuntu-7.0-latest
restart: always
environment:
ZBX_SERVER_HOST: zabbix-server
ZBX_HOSTNAME: "your-server-hostname"
postgres:
image: postgres:15-alpine
environment:
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: your-password
POSTGRES_DB: zabbix
volumes:
- zabbix_db:/var/lib/postgresql/data
volumes:
zabbix_db:
Checkmk
ドイツ発のエンタープライズ監視ソリューションです。Checkmk Raw Edition(OSSのCommunity Edition)が無料で使えます。GitHubスター1.4k。**自動検出(Auto-Discovery)**が優秀で、サーバーにエージェントを入れるだけでCPU・メモリ・ディスク・ネットワーク・インストール済みサービスを自動的に監視項目として追加します。設定ファイルを書かずにGUIで監視を構築できます。
# Checkmk Raw EditionをDockerで起動
docker run -d --name monitoring --restart always -p 8080:5000 -v /opt/checkmk/omd:/omd/sites -v /etc/localtime:/etc/localtime:ro --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 checkmk/check-mk-raw:2.3.0-latest
# 初回起動後にパスワードを確認
docker logs monitoring 2>&1 | grep "admin password"
機能比較表
| 比較項目 | Prometheus+Grafana | Zabbix | Checkmk Raw |
|---|---|---|---|
| ライセンス | Apache-2.0 | GPL-2.0 | GPL-2.0 |
| 監視方式 | Pull(スクレイプ) | Push + Poll | Push(エージェント) |
| Kubernetes対応 | ✅(最適) | △(プラグイン) | △ |
| SNMP(ネットワーク機器) | △(Exporter) | ✅(ネイティブ) | ✅ |
| 自動検出 | ❌(手動設定) | ✅ | ✅(優秀) |
| アラートUI | Grafana AlertManager | ✅(内蔵) | ✅(内蔵) |
| セットアップ難易度 | 高 | 中 | 低 |
| クラウドネイティブ向き | ✅ | △ | △ |
監視データをAI分析するパターンはLLMツールカテゴリ/categories/llm-toolsを参照してください。CI/CDと組み合わせたDevOpsツールの全体像はDevOpsカテゴリ/categories/devopsにまとめています。
FAQ
Q. PrometheusとDatadogの違いは何ですか?監視設計の考え方は同じですか?
A. 基本的な考え方(メトリクス収集・可視化・アラート)は同じですが、アーキテクチャが異なります。Prometheus(Pull型): 監視サーバーが各ターゲットに定期的に/metricsエンドポイントをHTTPで取りに行く。ターゲット側はメトリクスを公開するだけで済む(Exporterパターン)。サービスメッシュ・Kubernetes Podのような動的な環境でService Discoveryが重要。Datadog(Push + Agent型): 各サーバーにDatadog Agentをインストールし、エージェントがデータをDatadogクラウドに送る。設定がシンプルで、ネットワーク境界内のサーバーも監視しやすい。移行のポイント: Datadogで使っていたダッシュボード・アラート設定をPrometheusのPromQL + Grafanaで再現するのが最大の工数です。DatadogのメトリクスはOpenTelemetry経由でPrometheusに送ることもできます。
Q. Kubernetes環境でPrometheusをセットアップする最短の方法は?
A. kube-prometheus-stack(Helmチャート)が最も簡単です。Node Exporter・kube-state-metrics・AlertManager・Grafanaがセットでインストールされ、デフォルトでKubernetesの標準ダッシュボードがすでに設定された状態で起動します。
# kube-prometheus-stackをHelmでインストール
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# valuesを設定してインストール
cat > monitoring-values.yaml << 'EOF'
grafana:
adminPassword: your-admin-password
persistence:
enabled: true
size: 10Gi
smtp:
existingSecret: grafana-smtp-secret
prometheus:
prometheusSpec:
retention: 90d
storageSpec:
volumeClaimTemplate:
spec:
resources:
requests:
storage: 50Gi
alertmanager:
alertmanagerSpec:
storage:
volumeClaimTemplate:
spec:
resources:
requests:
storage: 2Gi
EOF
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack -n monitoring --create-namespace -f monitoring-values.yaml
5〜10分でPrometheus・Grafana・AlertManagerが起動し、Kubernetesクラスターの全ノード・Pod・サービスの監視が開始されます。
Q. Zabbixは何台まで監視できますか?スケールの限界は?
A. Zabbixのスケーラビリティは構成によって大きく異なります。単一サーバー構成(PostgreSQL): 5,000〜10,000ホストが目安(CPU 8コア・RAM 32GB・SSD)。Zabbixプロキシ構成: ネットワークセグメントごとにZabbixプロキシを置くことで数万ホストまでスケール可能。Zabbix自体の設計は10万ホスト以上を想定したエンタープライズ向けです。ボトルネックはDBの書き込み速度で、TimescaleDB拡張(Zabbix 7.0対応)を使うと時系列データの書き込みが最大10倍高速になります。比較的小規模(〜500ホスト)ならPostgreSQL 15でも十分です。
Q. Grafanaのアラートと Alertmanagerの役割分担はどうするべきですか?
A. 一般的な推奨構成: Alertmanagerをルーティングのハブとして使い、Grafanaのアラートは補完的に使います。Alertmanagerは①複数のPrometheusインスタンスからのアラートを集約②重複排除(同じアラートが複数発火したときに1通だけSlackに送る)③ルーティング(criticalはPagerDuty、warningはSlack)④Silencing(メンテナンス中のアラート抑制)を担当します。Grafanaのアラートは主に「Grafana上で見ているダッシュボードのパネルに直接アラートを設定したい」ケースで使います。本番環境ではPrometheus → AlertManager → Slack/PagerDutyがシンプルで管理しやすい構成です。Grafanaのアラートは設定のDRYが崩れやすいため、インフラ系アラートはPromQLで書くことを推奨します。
まとめ
| ユースケース | 推奨ツール |
|---|---|
| Kubernetes・マイクロサービス | Prometheus + Grafana |
| ネットワーク機器・オンプレ | Zabbix |
| 簡単セットアップ・自動検出 | Checkmk Raw |
| エンタープライズ移行 | Zabbix or Checkmk |