概要
Datadog とは、システムの監視・観測プラットフォームである。
アプリやインフラが「今どういう状態か」「どこで問題が起きているか」を一箇所で把握するための SaaS サービスで、メトリクス・ログ・APM・アラートを統合的に管理できる。
なぜ必要なのか
本番環境では様々な問題が起きる。
「APIのレスポンスが急に遅くなった」
「エラーが大量に出ている」
「サーバーのCPUが100%になった」
「あのバッチ、ちゃんと動いたっけ？」
これらを気づかないまま放置するとユーザーに迷惑がかかる。Datadog はこういった問題を早期に検知・調査するために使う。
主な機能
1. メトリクス監視（Metrics）
サーバーやアプリの数値データを時系列で記録・可視化する。
CPU使用率、メモリ使用量、リクエスト数、
レスポンスタイム、エラー率、DBのクエリ時間...
グラフでダッシュボードを作り、チーム全員がリアルタイムで確認できる。
2. ログ管理（Logs）
アプリが出力するログを収集・検索・分析できる。
# Railsのログも流し込める
Started GET "/api/properties" for 127.0.0.1
Processing by PropertiesController#index
SQL (2.3ms) SELECT * FROM properties...
Completed 200 OK in 45ms
大量のログの中から「エラーだけ抽出」「特定ユーザーのログだけ表示」といったことが簡単にできる。
3. APM（Application Performance Monitoring）
アプリの処理の流れを可視化する機能。
リクエスト受信
└── Controllerの処理（5ms）
└── DBクエリ（38ms） ← ここが遅い！
└── レスポンス返却
どの処理がボトルネックになっているかが一目でわかる。Rails との相性も良い。
4. アラート（Alerts）
異常を検知したら Slack・メール・PagerDuty などに通知を飛ばせる。
「エラー率が5%を超えたらSlackに通知」
「レスポンスタイムが2秒を超えたら即アラート」
「ディスク使用率が90%を超えたら警告」
全体像
[Railsアプリ] [ECSコンテナ ]
[MySQLなど ] │
▼
Datadogエージェント（収集担当）
│
▼
Datadogクラウド（分析・可視化）
┌──────┴──────┐
▼ ▼
ダッシュボード アラート通知
（監視画面） （Slackなど）
Datadogエージェントというプログラムをサーバーにインストールするだけで、自動的にメトリクスやログを収集してくれる。
Rails での導入
# Gemfile
gem 'ddtrace'
# config/initializers/datadog.rb
Datadog.configure do |c|
c.tracing.instrument :rails # Rails全体をトレース
c.tracing.instrument :mysql2 # DBクエリも計測
c.tracing.instrument :sidekiq # バックグラウンドジョブも
end
これだけで Rails のリクエスト・DB クエリ・Sidekiq ジョブなどが自動で計測される。
よく使う場面
| 場面 | Datadog でやること |
|---|---|
| 本番でエラー発生 | ログを検索してスタックトレース確認 |
| API が遅い | APM でどのクエリが遅いか特定 |
| デプロイ後の確認 | メトリクスでエラー率・レスポンスタイムの変化を確認 |
| 定期バッチの監視 | 正常終了したかログ・アラートで確認 |
| 障害対応 | 複数サービスのログを横断的に調査 |
Sentry との使い分け
Sentry はエラー検知・通知に特化しているが、Datadog はより広範囲の監視をカバーする。
| Datadog | Sentry | |
|---|---|---|
| 強み | インフラ監視・ログ管理・APM | エラー検知・通知 |
| 用途 | システム全体の可観測性 | アプリのエラー追跡 |
| 料金 | ホスト数・データ量課金 | イベント数課金 |
両方導入しているプロジェクトも多い。
まとめ
- 何者か？ → システム監視・観測プラットフォーム（SaaS）
- 何に使うか？ → メトリクス・ログ・APM・アラートの統合管理
- なぜ必要か？ → 本番の問題を早期に発見・調査するため
- Rails との関係 →
ddtracegem を入れるだけで自動計測できる - 最初の一歩 → ログを検索する・ダッシュボードを眺めるだけでも十分