オープンソース監視・アラートツール比較：Prometheus vs Zabbix vs VictoriaMetrics でインフラ監視をセルフホストする

DatadogやNew Relicのような高価な監視SaaSに依存せず、インフラ・アプリケーション監視をオープンソースでセルフホストしましょう。Prometheus・Zabbix・VictoriaMetricsはメトリクス収集・アラート・ダッシュボードを自社サーバーで構築できます。

インフラ監視ツールが必要な場面

• コスト削減: Datadogは$15/ホスト/月〜、100ホストで年間180万円
• データ主権: インフラのメトリクス・ログを外部SaaSに送りたくない
• カスタムメトリクス: ビジネス固有のKPIを監視する
• 長期保存: コスト上の理由からメトリクスを1年以上保存したい
• オンプレ/エアギャップ: クラウドに繋がらない環境でのサーバー監視

主要ツールの概要

Prometheus

クラウドネイティブ時代のデファクトスタンダードの監視システムです。スクレイプ型（監視対象がエンドポイントを公開し、Prometheusが定期取得）で動作し、PromQL（Prometheus Query Language）でメトリクスを集計・分析します。Grafanaと組み合わせてダッシュボードを作成するのが標準的な構成です。

# Prometheus + Grafanaをdocker-composeで起動
version: "3"
services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.retention.time=30d"
      - "--web.enable-lifecycle"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
      GF_DASHBOARDS_DEFAULT_HOME_DASHBOARD_PATH: /etc/grafana/dashboards/overview.json
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/dashboards:/etc/grafana/dashboards

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"

volumes:
  prometheus_data:
  grafana_data:

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alert_rules.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  # Prometheus自身を監視
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  # サーバー（node_exporter）を監視
  - job_name: "node"
    static_configs:
      - targets:
          - "192.168.1.10:9100"  # web-server-1
          - "192.168.1.11:9100"  # web-server-2
          - "192.168.1.12:9100"  # db-server-1
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

  # KubernetesのPodを自動ディスカバリー
  - job_name: "kubernetes-pods"
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: "true"

# alert_rules.yml
groups:
  - name: node_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 | humanize }}% です"

      # ディスク残量が10%未満でアラート
      - alert: LowDiskSpace
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "ディスク残量が少ない: {{ $labels.instance }}"
          description: "{{ $labels.mountpoint }} の残量が {{ $value | humanize }}% です"

# prometheus_client ライブラリでカスタムメトリクスを公開
from prometheus_client import Counter, Gauge, Histogram, start_http_server
import time

# カウンター（増加のみ）
http_requests_total = Counter(
    "http_requests_total",
    "HTTPリクエスト総数",
    ["method", "endpoint", "status_code"],
)

# ゲージ（任意の値）
active_users = Gauge("active_users_total", "現在のアクティブユーザー数")

# ヒストグラム（レイテンシ分布）
request_duration = Histogram(
    "http_request_duration_seconds",
    "HTTPリクエストのレイテンシ",
    ["endpoint"],
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0],
)

# FastAPIのミドルウェアとして使用
from fastapi import FastAPI, Request
import time

app = FastAPI()

@app.middleware("http")
async def prometheus_middleware(request: Request, call_next):
    start_time = time.time()
    response = await call_next(request)
    duration = time.time() - start_time

    http_requests_total.labels(
        method=request.method,
        endpoint=request.url.path,
        status_code=response.status_code,
    ).inc()

    request_duration.labels(endpoint=request.url.path).observe(duration)
    return response

# /metricsエンドポイントをPrometheusスクレイプ用に公開
start_http_server(8000)  # http://localhost:8000/metrics

VictoriaMetrics

Prometheusの互換APIを持ちながら、より高いパフォーマンス・低メモリ・大幅な圧縮率を実現したタイムシリーズデータベースです。単一バイナリで動作し、PrometheusのPromQLに加えてMetricsQL（拡張クエリ言語）もサポートします。

# VictoriaMetricsをDockerで起動（シングルノード）
docker run -d   -p 8428:8428   -v victoriametrics_data:/storage   victoriametrics/victoria-metrics:latest   --storageDataPath=/storage   --retentionPeriod=12  # 12ヶ月保存

# PrometheusのリモートライトをVictoriaMetricsに向ける
# prometheus.yml に追加:
# remote_write:
#   - url: http://victoriametrics:8428/api/v1/write

# クラスター版（大規模向け）
# vminsert / vmstorage / vmselect の3コンポーネント構成

Zabbix

エージェントベースの従来型監視ツールです。SNMP・IPMI・JMXにも対応しており、ネットワーク機器・物理サーバー・データベースを幅広くカバーします。エンタープライズの既存インフラ監視に適しています。

# Zabbixをdocker-composeで起動
version: "3"
services:
  zabbix-server:
    image: zabbix/zabbix-server-pgsql:latest
    ports:
      - "10051:10051"
    environment:
      DB_SERVER_HOST: postgres
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pass
      POSTGRES_DB: zabbix
    depends_on:
      - postgres

  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:latest
    ports:
      - "8080:8080"
    environment:
      DB_SERVER_HOST: postgres
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pass
      POSTGRES_DB: zabbix
      ZBX_SERVER_HOST: zabbix-server
      PHP_TZ: Asia/Tokyo
    depends_on:
      - zabbix-server

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pass
      POSTGRES_DB: zabbix

機能比較表

比較項目	Prometheus + Grafana	VictoriaMetrics	Zabbix
メトリクス収集方式	プル（スクレイプ）	プル/プッシュ	プッシュ（エージェント）
保存効率	★★★☆☆	★★★★★	★★★☆☆
クエリ言語	PromQL	MetricsQL（PromQL互換）	Zabbix式
Grafana統合	✅ ネイティブ	✅ ネイティブ	✅
Kubernetes対応	★★★★★	★★★★☆	★★★☆☆
SNMP/ネットワーク機器	❌（別途Exporter）	❌	✅ ネイティブ
アラート	✅ Alertmanager	✅ vmalert	✅ 内蔵
長期保存（1年〜）	❌（外部Thanosが必要）	✅	✅
スケールアウト	✅（Thanos/Cortex）	✅（Cluster）	✅
UIダッシュボード	Grafana必須	Grafana/VMUI	✅ 内蔵
設定の容易さ	★★★☆☆	★★★★☆	★★☆☆☆
ライセンス	Apache 2.0	Apache 2.0	GPL 2.0
GitHub Stars	55k+	12k+	4k+

監視・可観測性ツールはDevOpsカテゴリ（/categories/devops）で一覧でき、ログ管理・トレーシングツールはセキュリティカテゴリ（/categories/security）でも探せます。

FAQ

Q. DatadogからPrometheusへの移行はどうやりますか？

A. 移行の基本的な流れ: 1) Prometheusをサイドバイサイドで起動してメトリクスを収集開始、2) Grafanaでダッシュボードを再現（Datadogのダッシュボード設定をPromQLに書き直す）、3) Alertmanagerでアラートを再設定（Datadogのアラートルールをalert_rules.ymlに移植）、4) 一定期間並行運用して異常がないことを確認、5) Datadogのエージェントを停止。移行で最も時間がかかるのはPromQLへの書き直しです。Datadog独自のメトリクス（datadog.*）はPrometheusに移行できないため、対応するNode Exporter等のメトリクスに置き換えます。

Q. PrometheusとVictoriaMetricsを同時に使う意味はありますか？

A. あります。一般的なパターン: Prometheusを短期メトリクス収集・ルール評価・Alertmanager連携に使い、VictoriaMetricsをPrometheusのリモートライト先として長期保存に使います。メリット: Prometheusのシンプルな設定を維持しながら、VictoriaMetricsの高圧縮・長期保存を活用できる。大規模環境ではThanosの代わりにVictoriaMetricsをリモートストレージとして使うと、運用がシンプルになります。

Q. Prometheusで1年以上メトリクスを保存するには？

A. PrometheusはデフォルトでTSDB（Time Series Database）に15日分のメトリクスを保存します。1年以上の長期保存には3つの選択肢があります: 1) --storage.tsdb.retention.time=365dで直接延長（ストレージ容量に注意）、2) ThanosまたはCortexを使ってS3/GCSにリモートストレージ、3) VictoriaMetricsをリモートライト先として使う（最もシンプル）。1年分のメトリクス容量の目安: 100台のサーバーで各100メトリクス取得なら約50〜100GB（VictoriaMetricsなら10〜20GB）。

Q. Zabbixのエージェントレス監視はどんな場合に使いますか？

A. エージェントがインストールできないデバイスの監視に有効です。SNMP（スイッチ・ルーター・プリンター・UPS）・ICMP（pingによる死活監視）・SSH（コマンド実行結果を監視）・HTTP（APIエンドポイントのステータス確認）・JMX（JavaアプリケーションのJMXメトリクス）・IPMI（物理サーバーのハードウェアセンサー）。既存のネットワーク機器・物理インフラが多い企業では、Zabbixのエージェントレス監視が非常に有用です。PrometheusはSNMPをSNMP Exporterで対応できますが、Zabbixの方が設定が容易です。

まとめ

ユースケース	推奨ツール
Kubernetes・クラウドネイティブ	Prometheus + Grafana
長期保存・大規模・高効率	VictoriaMetrics
ネットワーク機器・物理インフラ	Zabbix
Datadog代替	Prometheus + VictoriaMetrics

関連外部リソース

• Prometheus GitHubリポジトリ↗
• VictoriaMetrics GitHubリポジトリ↗
• Zabbix GitHubリポジトリ↗
• Prometheus公式ドキュメント↗