AI

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+GrafanaZabbixCheckmk Raw
ライセンスApache-2.0GPL-2.0GPL-2.0
監視方式Pull(スクレイプ)Push + PollPush(エージェント)
Kubernetes対応✅(最適)△(プラグイン)
SNMP(ネットワーク機器)△(Exporter)✅(ネイティブ)
自動検出❌(手動設定)✅(優秀)
アラートUIGrafana 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

関連外部リソース

他の記事も読む

Let's Build Together

OSS導入、自社だけで悩まない。

ツール選定から構築・運用・AI活用まで、オープンソースラボ運営元のClasslessが伴走します。初回のご相談は無料です。