Datadog vs Sentry：地獄のデバッグからエンジニアを解放する「真の選択」と最適解
「エラー検知はSentry、メトリクス監視はDatadog」……教科書通りの回答に満足しているようでは、サービスが急拡大した瞬間に運用地獄を見る。
私はこれまで数々の大規模分散システムを渡り歩いてきたが、言わせてもらおう。ツールを「どちらか一つ」に絞る必要はない。だが、それぞれの「魂」を理解せずに併用すれば、アラートの洪水に溺れて死ぬ。
今日は、現場で血を流しながら学んだ、DatadogとSentryの「実戦的」な使い分けと、生産性を極限まで高めるための設定術を叩き込む。
—
1. 魂の比較：なぜこれらは「別の生き物」なのか
Sentry：フロントエンド〜バックエンドの「文脈（Context）」の守護者
Sentryは「何が起きたか」の文脈を再現するスペシャリストだ。スタックトレース、ローカル変数の値、ブラウザのメモリ状態まで、エラー発生瞬間のスナップショットを完璧に切り取る。
- ターゲット: アプリケーションコードの品質に妥協したくない全エンジニア。
Datadog：インフラからビジネスまでを貫く「相関（Correlation）」の支配者
Datadogは「システム全体で何が起きているか」を俯瞰する帝王だ。ログ、メトリクス、APM、RUMを一つのUIで相関させる。
- ターゲット: サービス全体のSLI/SLOを定義し、MTTR（平均復旧時間）を極限まで短縮したいSRE・テックリード。
—
2. 3軸比較：実戦の現場で突きつけられる現実
| 軸 | Sentry | Datadog |
| :— | :— | :— |
| エラートラッキング | 圧倒的。エラーのグルーピングと再現性が異常に高い | ログベースの検知は可能だが、調査時の体験はSentryに劣る |
| パフォーマンス | APMはあるが、インフラ相関に弱い | 分散トレースの海を泳ぐなら最強。インフラ依存の遅延特定に無双 |
| 料金体系 | エラーイベント課金。爆発すると予算が溶ける | ホスト・コンテナ・データ量課金。複雑すぎて請求書を見るのが怖い |
—
3. 現場で「開発スピード」を劇的に変える設定術
ツールを導入するだけでは生産性は上がらない。以下の設定を今すぐ反映せよ。
Sentryの神設定：ノイズを殺し、本質を掘り起こす
Sentryのデフォルト設定は「ノイズ」の温床だ。`beforeSend`フックを使って、ゴミを排除せよ。
// sentry.config.js – ノイズを除去するフィルタリング設定
Sentry.init({
dsn: ‘…’,
beforeSend(event, hint) {
// ユーザーのキャンセルや、特定バージョンの既知のバグは無視する
const error = hint.originalException;
if (error && error.message && error.message.includes(‘ResizeObserver loop limit’)) {
return null; // このイベントを破棄
}
return event;
},
// 必要なコンテキストだけを絞り込む
sendDefaultPii: false,
});
【キーボードショートカット：Sentryを爆速で操作せよ】
- `Cmd + K` (Mac) / `Ctrl + K` (Win): コマンドパレットを起動せよ。 プロジェクト切り替えやイシュー検索はマウスを使わずこれで行う。これができないとSentry使いとは言えない。
Datadog：ダッシュボードは「動的」に構成する
静的なダッシュボードは飾りだ。Tagベースの可変ダッシュボードこそが正義。
datadog.yaml – 運用を最適化するエージェント設定の断片
logs_config:
container_collect_all: true
# プロダクションのログだけをフィルタしてSentryに飛ばすような連携も可能
apm_config:
enabled: true
# 重要なトランザクションのみサンプリングレートを上げる設定
extra_sample_rates:
“service:my-api,name:post_checkout”: 1.0
—
4. 併用アーキテクチャ：これが最強の布陣だ
私が推奨する黄金比はこれだ：
1. Sentry: アプリケーションの「例外エラー（Exception）」専用。Slack通知を飛ばし、即座にスタックトレースを確認する。
2. Datadog: サービスの「健全性（Health）」専用。CPU/メモリ、レイテンシ（P99）、エラー率の異常を監視し、SentryへのリンクをAPMに埋め込む。
【併用のベストプラクティス】
DatadogのAPMトレースIDをSentryに注入せよ。
これにより、Datadogでレイテンシ異常を見つけた際、そこに紐づくSentryのエラー詳細画面へ、ワンクリックで遷移できるようになる。この「文脈の橋渡し」こそが、MTTRを分単位で短縮する鍵だ。
—
最後に：ツールに振り回されるな
スタートアップなら、まずはSentry一択だ。コードのバグを潰すこと以上に重要なKPIはない。
ある程度トラフィックが伸び、マイクロサービス化が進んだらDatadogを足せ。
大切なのは、「どのツールを使うか」ではない。「異常が起きた瞬間に、脳内でどのグラフを思い浮かべ、どのログを叩くか」というオブザーバビリティの解像度だ。
君たちのチームの生産性は、その解像度で決まる。今すぐ設定ファイルを開き、不要な通知をオフにし、真に必要なシグナルだけを研ぎ澄ませ。それがプロの仕事だ。