結論（おすすめ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 では要件を満たせないリスクがある
SOCIAL SHARE CARD GENERATOR