OSSモニタリング比較：Grafana+Prometheus vs Netdata vs Zabbix でサーバー監視を構築

Datadog（月$15〜/ホスト）・New Relic（月$49〜）に対して、Grafana + Prometheus（メトリクス可視化の業界標準スタック）・Netdata（リアルタイム・ゼロ設定の軽量モニタリング）・Zabbix（エンタープライズ向けインフラ監視）はOSSのモニタリングソリューションです。

インフラモニタリングの必要性

• SLO（Service Level Objective）管理: p99レイテンシ・エラーレート・可用性の継続監視
• 容量計画: CPU・メモリ・ディスク使用率の傾向から増強タイミングを予測
• 障害の早期検知: アラートで問題が大きくなる前に通知を受ける
• コスト最適化: リソース使用率の可視化でオーバープロビジョニングを削減

主要ツールの概要

Grafana + Prometheus

Prometheus（2012年にSoundCloudが開発、CNCF卒業プロジェクト）はPull型のメトリクス収集エンジンです（GitHubスター57k+）。各サービスは/metricsエンドポイントでPromQLメトリクスを公開し、PrometheusがN秒ごとに収集します。Grafana（GitHubスター64k+）はそのデータを美しいダッシュボードとして可視化します。Kubernetes・Docker・Linux・AWS/GCPのモニタリング事実上の標準スタックです。

# docker-compose.yml - Grafana + Prometheus + Alertmanager
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./alerts.yml:/etc/prometheus/alerts.yml
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.retention.time=30d"
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
      GF_USERS_ALLOW_SIGN_UP: "false"
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/dashboards:/etc/grafana/provisioning/dashboards
      - ./grafana/datasources:/etc/grafana/provisioning/datasources

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

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

volumes:
  prometheus_data:
  grafana_data:

# prometheus.yml - スクレイプ設定
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts.yml"

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

scrape_configs:
  # Node Exporter（OS メトリクス）
  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]
        labels:
          env: production

  # Dockerコンテナのメトリクス（cAdvisor）
  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"]

  # アプリのカスタムメトリクス（/metricsエンドポイント）
  - job_name: "api-service"
    static_configs:
      - targets: ["api-service:3000"]

# alerts.yml - アラートルール
groups:
  - name: infrastructure
    rules:
      # CPU使用率が5分間80%超
      - alert: HighCPUUsage
        expr: 100 - (avg by (instance) (irate(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 }}%"

      # メモリ残量が10%未満
      - alert: LowMemory
        expr: (node_memory_MemFree_bytes + node_memory_Cached_bytes) / node_memory_MemTotal_bytes * 100 < 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Low memory on {{ $labels.instance }}: {{ $value }}%"

      # ディスク使用率が90%超
      - alert: DiskAlmostFull
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Disk almost full on {{ $labels.instance }}: {{ $value }}%"

# Pythonアプリにカスタムメトリクスを追加（prometheus_client）
from prometheus_client import Counter, Histogram, Gauge, start_http_server
import time

# カスタムメトリクスを定義
REQUEST_COUNT = Counter("http_requests_total",
    "Total HTTP requests", ["method", "endpoint", "status_code"])
REQUEST_LATENCY = Histogram("http_request_duration_seconds",
    "HTTP request latency", ["endpoint"])
ACTIVE_CONNECTIONS = Gauge("active_connections",
    "Number of active WebSocket connections")

# FastAPIでのメトリクス記録
from fastapi import FastAPI, Request
import time

app = FastAPI()

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

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

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

# /metrics エンドポイントを公開
from prometheus_client import make_asgi_app
metrics_app = make_asgi_app()
app.mount("/metrics", metrics_app)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=3000)

Netdata

2014年から開発されているC言語製のリアルタイム監視エージェントです。GitHubスター73k+。ゼロ設定でインストール後即座に2,000以上のメトリクスを1秒単位で収集し、ブラウザで確認できます。Docker・Nginx・MySQL・Redis・PostgreSQLなど主要サービスを自動検出してメトリクスを収集します。軽量（RAM 25MB〜）で単一ホストのクイックモニタリングに最適です。

# Netdataのインストール（1コマンド）
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# WebUI: http://your-server:19999
# サービス自動検出: Nginx・MySQL・Docker等を検知して即座に監視開始

# Dockerで起動
docker run -d   --name netdata   -p 19999:19999   -v netdataconfig:/etc/netdata   -v netdatalib:/var/lib/netdata   -v netdatacache:/var/cache/netdata   -v /etc/passwd:/host/etc/passwd:ro   -v /etc/group:/host/etc/group:ro   -v /proc:/host/proc:ro   -v /sys:/host/sys:ro   -v /etc/os-release:/host/etc/os-release:ro   --restart unless-stopped   --cap-add SYS_PTRACE   --security-opt apparmor=unconfined   netdata/netdata:latest

機能比較表

比較項目	Grafana+Prometheus	Netdata	Zabbix
設定の複雑さ	高	低（ゼロ設定）	高
メトリクス粒度	15秒〜	1秒	60秒〜
必要RAM	2GB〜	25MB〜	512MB〜
Kubernetes対応	✅（標準）	✅	✅（Helm）
カスタムダッシュボード	✅（Grafana）	限定的	✅
エージェントレス監視	❌	❌	✅（SNMP）
GitHub Stars	64k+	73k+	5k+

モニタリングのアラートをSlack・PagerDutyに送信するにはDevOpsカテゴリ/categories/devopsのAlertmanagerを使います。ログとメトリクスを統合した可観測性プラットフォームを構築するにはKnowledgeカテゴリ/categories/knowledgeのGrafana Lokiとの組み合わせが一般的です。

FAQ

Q. Prometheusのメトリクス保持期間を延ばすにはどうすればいいですか？

A. Prometheusのデフォルト保持期間は15日（--storage.tsdb.retention.time=15d）です。長期保持には2つのアプローチがあります。①--storage.tsdb.retention.time=365dで増やす（ディスク増設が必要・推奨最大2年）。②Thanos（GitHubスター13k+）またはCortexをPrometheusのサイドカーとして動かしてS3等にデータをオフロードする（無制限保持・大規模環境向け）。コスト効率を重視するならThanosのS3 Compact機能でデータを圧縮してコールドストレージに移動するのが標準的なアーキテクチャです。

Q. Netdataだけで本番環境のモニタリングをカバーできますか？

A. 単一ホストやシンプルな環境ではNetdataだけで十分です。限界: ①複数ホストの横断ダッシュボードはNetdata Cloudを使わないと作れない（セルフホストだと各ホストに個別アクセス）②メトリクスの長期保持はデフォルト1時間（増やすとRAM増加）③カスタムダッシュボードの柔軟性がGrafanaより低い。本番の複数サービスを横断的に監視し、アラートをSlack/PagerDutyに送りたい場合はGrafana+Prometheusの方が圧倒的に柔軟です。

Q. GrafanaのダッシュボードをGit管理するには？

A. Grafanaの「Dashboards as Code」にはいくつかのアプローチがあります。①Dashboard JSON Export: GrafanaのUIからJSON形式でダッシュボードをエクスポートしてGitに保存。変更はJSON差分で管理。②Grafonnet（Jsonnet）: Jsonnetでダッシュボードをプログラマティックに生成し、CIでGrafanaにデプロイ。③Grafana Terraform Provider: InfrastructureとしてTerraformでGrafanaリソースを管理。一番シンプルな方法はdocker-compose.ymlでプロビジョニング用フォルダをマウントし、起動時にJSONを自動反映することです。

Q. Prometheusでマルチテナント（複数顧客のメトリクスを分離して管理）はできますか？

A. Prometheus標準にはマルチテナント機能がありません。対応方法: ①顧客ごとに別Prometheusインスタンスを立てる（シンプルだが管理が煩雑）②Grafanaの組織機能で顧客ごとにダッシュボードのアクセス権を分ける③Cortex（マルチテナント対応のPrometheusとして設計）を使う。SaaS企業で顧客ごとにメトリクスを分離したい場合はCortexまたはThanos+Grafanaテナント機能の組み合わせが推奨されます。

まとめ

ユースケース	推奨ツール
Kubernetes・本格的なダッシュボード	Grafana + Prometheus
単一ホスト・クイック設定	Netdata
エンタープライズ・SNMP・エージェントレス	Zabbix

関連外部リソース

• Grafana GitHubリポジトリ↗
• Prometheus GitHubリポジトリ↗
• Netdata GitHubリポジトリ↗
• Prometheus公式ドキュメント↗