クラウド監視ツール比較（Datadog・New Relic・CloudWatch）
選定の前提を3つ決める（監視対象・SLA・運用体制）
ツール比較の前に、何を守るのかを具体化します。対象は「どのサービス・環境・経路か（例：本番EKSのCheckout API、RDS、外形監視対象URL）」、SLAは「どの指標をどの水準で守るか（例：P95レイテンシ300ms、エラーレート1%以下）」、体制は「誰がいつ何で対応するか（オンコール、一次切り分け、エスカレーション先）」です。ここが曖昧なまま導入すると、ダッシュボードは綺麗でも意思決定に使えません。
- 監視対象の棚卸し：メトリクス/ログ/トレース/外形の4層で、必須と任意を分ける
- SLO/アラート基準：業務影響の観点で「SLO違反に直結するアラート」だけを先に整備
- 運用プロセス：一次対応Runbook、当番表、遅延の定義、ポストモーテムの型
この三点が固まると、各ツールの「どの機能を使う/使わない」「料金がどこで膨らみうる」が見えてきます。なお、最近はChatGPTやCopilot、Geminiを使ってLog InsightsやNRQLのクエリ雛形、Runbookの初稿を素早く用意するチームも増え、立ち上げ速度が上がっています。
Datadog・New Relic・CloudWatchの違いを一気に把握
Datadogの特徴
統合度が高く、インフラ監視/APM/ログ/RUM/合成/Kubernetes可視化までワンストップで進めやすいです。オートディスカバリとダッシュボードの初期体験が優秀で、EKSやLambdaも短時間で見える化できます。Watchdogの異常検知や、タグを軸に横断分析しやすいのも強み。一方で、モジュール単位の課金と高カーディナリティなタグでコストが跳ねやすく、ログやトレースの取り込み設計（サンプリング、マスク、保持期間）が雑だと月次請求が不安定になりがちです。
New Relicの特徴
データ取り込み量とユーザー数をベースにしたプライシングで、可観測性を「データプラットフォーム」として使い倒す設計に向きます。NRQLとNerdGraphでのクエリ駆動が強力で、開発者が自走しやすい反面、クエリ設計の素地がないと価値が出にくい側面も。OpenTelemetryとの相性が良く、マルチクラウドでデータを一元化したい時に選ばれやすいです。ダッシュボードの柔軟性は高いですが、初期セットアップはDatadogほどの「置けば出る」感はありません。
CloudWatchの特徴
AWSネイティブで、メトリクス/ログ/アラーム/ダッシュボード/合成（Synthetics）まで一通り揃います。IAM・CloudTrail・CloudFormationとの親和性が高く、AWS専業なら導入/運用の摩擦が最小です。X-Rayと組み合わせた分散トレースも可能。ただしマルチクラウドの横断可視化には向かず、EKSの詳細な可視化やSLO管理は追加設計が必要。料金はメトリクス数・アラーム数・ログ取り込み/保存量で増加するため、高頻度カスタムメトリクスや高カーディナリティのログはコスト要注意です。
コストと運用の落とし穴を回避する設計ポイント
- タグ/属性設計を先に決める：service、env、version、tenantの4本柱。自由記述は避ける
- ログは3段階で管理：収集（何を拾う）→保管（保持日数/圧縮）→検索（インデックス化の範囲）。デバッグログはサンプリング
- トレースは目標SLO逆算でサンプリング率を決める：Checkoutや認証などビジネスクリティカル経路を優先
- アラートは「静的×少数＋動的×限定」で始める：SLO違反、リソース枯渇、デプロイ後の急変だけ
- コストのガードレール：週次で取り込み量/カーディナリティのレポートを自動配信、閾値超過でアラート
- ダッシュボードは役割別：経営（SLO/売上影響）、SRE（エラー/レイテンシ/キャパ）、開発（リリース影響）を分離
実務では、クエリやRunbookの下書きをCopilotやChatGPTに生成させ、Peopleレビューで確度を上げるとスピードと品質が両立します。Datadogならログパイプラインでマスク/削減、New Relicなら取り込みルールとNRDB保持、CloudWatchならログフィルタと保持日数を組み合わせ、月次の「データ増加イベント（大量デプロイ、テナント増）」に備えるのが安全です。
失敗から学ぶ身近な活用例（小売ECスタートアップ）
AWS（ECS/Fargate、RDS、Lambda、CloudFront）で、当初はCloudWatchだけで監視していました。セール時のレイテンシ悪化やカゴ落ちが増えても、原因特定に時間がかかり機会損失が発生。改善のためDatadogを導入しましたが、APM/ログ/RUMをフル有効化し、デバッグログを全量送信。タグも自由記述で氾濫し、請求が予想外に膨らみ、かつアラートは過検知でオンコール疲れに陥りました。
見直しでは、SLOを「Checkout APIのP95=300ms、エラー<1%」に定義。CloudWatchは基礎監視（ALB 5xx、RDS CPU、Lambdaエラー、ビリングアラート）に絞って継続し、DatadogはAPMと合成監視に限定。APMはCheckout経路と在庫APIだけにトレースを導入し、サンプリング25%、個人情報はマスク。ログはアプリ側でINFO以上、エラーのみインデックス化。Kubernetesのオートディスカバリはenv・service・versionの3タグに固定。アラートはSLO違反・デプロイ直後のエラースパイク・RDS接続数の3本から開始。RunbookはGeminiで初稿を作り、実対応の知見を追記して1週間で整備しました。
結果として、セール中の障害でもボトルネックのSQLが即座に可視化され、MTTRは半減。取り込み量と保持期間の見直しで監視コストも約4割削減。意思決定材料が「なんとなくの負荷感」から「SLOとトレースの事実」に変わり、開発とSREの会話が噛み合うようになりました。
まとめると、AWS専業・費用最小重視ならCloudWatch、マルチクラウドやKubernetes横断の可視化とスピード重視ならDatadog、データ駆動で横断分析をやり切るならNew Relicが起点になりやすいです。ただし鍵はツールそのものより「SLO起点の設計」と「取り込み/保持/タグの運用」。サーバ監視運用事業としては、まさにこの設計と改善サイクルを現場と一緒に回し、障害を短く・予算は細く・学びは太くするところに価値が出ると考えています。
