スシロー

Posted on Jun 16

【2026】Datadog 代替の低価格監視SaaS：料金・移行コストで選ぶ

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

乗り換え先は Grafana Cloud を推奨する。

理由は3点。第一に、Prometheus・OpenTelemetry との互換性が高く、既存のインスツルメンテーションをほぼそのまま流用できる。第二に、実用的な無料枠が設けられており、小〜中規模チームであれば初期コストを抑えながら本番監視を立ち上げられる。第三に、メトリクス・ログ・トレースの三本柱を一画面で扱えるため、Datadog からの機能的な代替として違和感が少ない。

比較表（料金/無料枠/移行コスト/対応言語）

ツール	料金モデル	無料枠	移行コスト	主な対応言語
Grafana Cloud	従量制 + 無料枠	あり（公式の料金ページで要確認）	低〜中（OTel Collector 置換のみ）	Go / Python / Node.js / Java / .NET 他
New Relic	データ量課金	あり（公式の料金ページで要確認）	中（エージェント差替、APMコード変更あり）	Go / Python / Node.js / Java / Ruby / PHP 他
SigNoz	OSS自己ホスト or クラウド	OSS版は無料（インフラ費は別途）	低（OTel準拠、コード変更最小）	OTel対応言語全般
Elastic APM	Elastic Cloud or 自己ホスト	OSS版は無料（Elasticスタック込み）	中〜高（Elasticスタック全体の習熟が前提）	Go / Python / Node.js / Java / Ruby / .NET 他

料金は頻繁に改定されるため、各社の公式料金ページを移行判断前に必ず確認すること。

移行手順

Datadog Agent から Grafana Cloud（OpenTelemetry Collector 経由）への移行を例に示す。

1. Grafana Cloud アカウント作成・接続情報の取得

Grafana Cloud のダッシュボードにログインし、Prometheus RemoteWrite エンドポイント URL と API キーを取得する。Loki（ログ）・Tempo（トレース）も同様に接続情報を控える。

2. OpenTelemetry Collector のインストール

# Linux (systemd) の例
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/latest/download/otelcol-contrib_linux_amd64.tar.gz
tar -xzf otelcol-contrib_linux_amd64.tar.gz
sudo mv otelcol-contrib /usr/local/bin/otelcol
sudo useradd --system otelcol

3. Collector 設定ファイルの作成

# /etc/otelcol/config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"
      http:
        endpoint: "0.0.0.0:4318"

exporters:
  prometheusremotewrite:
    endpoint: "https://<your-grafana-prom-endpoint>/api/prom/push"
    headers:
      Authorization: "Basic <base64(instanceId:api_key)>"
  loki:
    endpoint: "https://<your-loki-endpoint>/loki/api/v1/push"
    headers:
      Authorization: "Basic <base64(instanceId:api_key)>"

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      exporters: [loki]

# systemd サービスとして起動
sudo tee /etc/systemd/system/otelcol.service > /dev/null <<EOF
[Unit]
Description=OpenTelemetry Collector

[Service]
ExecStart=/usr/local/bin/otelcol --config /etc/otelcol/config.yaml
User=otelcol
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now otelcol

4. アプリケーション側の OTel SDK 追加（Node.js の例）

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

// tracing.js — エントリポイントより前に require する
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const sdk = new NodeSDK({
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

# 起動コマンドに --require を追加
node --require ./tracing.js app.js

5. Datadog Agent の停止と疎通確認

# Datadog Agent を無効化
sudo systemctl stop datadog-agent
sudo systemctl disable datadog-agent

# Grafana Cloud の Explore でメトリクス疎通を確認
# ブラウザ: Grafana > Explore > Prometheus データソースを選択
# クエリ例: rate(http_server_duration_milliseconds_count[5m])

既存の Datadog ダッシュボードは JSON のまま Grafana へ移植できない。PromQL ベースで手動再構築する必要があり、この工程が移行工数の大半を占める点に注意する。

向き不向き

向いているチーム・ケース

スタートアップや小規模チームで Datadog の月次コストが事業予算に対して重荷になっている
Prometheus をすでに運用しており、クラウドへのオフロードだけを求めている
OpenTelemetry に統一してベンダーロックインを段階的に減らしたい方針がある
インフラエンジニアが常駐しており、SigNoz などのセルフホスト OSS の運用も検討できる

避けるべきケース

Datadog の Watchdog（自動異常検知）や APM の相関分析 UI に強く依存しており、代替ツールの習熟コストを吸収できる体制がない
PCI DSS・SOC 2 などコンプライアンス要件が厳しく、新ベンダーの監査対応に時間をかけられない
オンコール体制が整っておらず、自己ホスト OSS の深夜障害に対応できるエンジニアがいない
契約上エンタープライズ SLA が必須で、中小 SaaS では要件を満たせないリスクがある

DEV Community