【ITニュース解説】Datadog vs Dynatrace: Which is Better in 2025? [Hands-On Testing]

システムエンジニアを目指す皆さんにとって、システムがきちんと動いているかを確認し、何か問題が起きたときにその原因を素早く突き止めることは非常に重要な仕事である。この「監視」や「可観測性」と呼ばれる分野で、DatadogとDynatraceは特に人気の高いツールだ。今回は、PythonアプリケーションとMongoDBデータベースという組み合わせをAWSの仮想サーバー上で動かし、これらのツールがどのような違いを見せるのか、実際に試した結果を基に解説していく。

まず、DatadogとDynatraceの主な機能を比較すると、どちらもインフラの監視、アプリケーションの性能監視（APM）、ログの監視、実際のユーザー体験の監視（RUM）、そしてサービス品質保証（SLA）の監視に対応している。最近重要視されているOpenTelemetryというオープンな規格にも両方とも対応している。ただし、Datadogには無料プランがあるのに対し、Dynatraceにはない。また、Dynatraceは自社サーバーでの運用（オンプレミス）も可能だが、Datadogはクラウドのみである。AIを使った自動運用機能（AIOps）も両者ともに備えており、DatadogはWatchdog、DynatraceはDavis AIという名前で提供している。DynatraceはAIによる統合的な分析に強みがある一方、Datadogは独自の監視エージェントを優先しつつもOpenTelemetryのプロトコルもサポートしている。

今回の検証では、AWSの「t2.micro EC2インスタンス」という、CPUが1つでメモリが1GBの小さな仮想サーバーを2台用意した。それぞれのサーバーにMongoDBデータベースとPythonアプリケーションをインストールし、同じ条件でDatadogとDynatraceの監視能力を比較した。

最初に、両ツールのサインアッププロセスを見てみよう。Datadogのサインアップはメールアドレスなどを入力するだけで、クレジットカード情報も不要で非常にスムーズだった。自分の使っている技術スタックを選ぶ画面があったが、これはスキップすることもできた。アカウント作成後はすぐにエージェントのセットアップ画面に進むことができた。一方、Dynatraceも同様にメールアドレスなどで登録するが、アカウント作成が完了するまでに4分ほど時間がかかった。また、登録後の画面はやや直感的ではなく、目的の操作を見つけるのに少し時間がかかった。特に、AWSアカウント全体を監視する設定が最初に提示され、個別のインスタンスを監視する方法を見つけるのが大変だった。

次に、監視エージェントのインストールプロセスである。Datadogの場合、サインアップ後すぐにエージェントのインストールページに案内され、AWSのAmazon Linux向けのコマンドが明確に表示されていた。このコマンドを仮想サーバーで実行するだけで、Datadogエージェントは簡単にインストールされ、インフラの基本的なメトリクス（CPU使用率、メモリ使用量など）の監視をすぐに開始した。しかし、アプリケーションの具体的な性能を監視するには、Pythonアプリケーション専用の追加エージェント「ddtrace」をインストールし、アプリケーションの起動コマンドに特別な引数を加える必要があった。UIはこれらの手順を詳しくガイドしてくれた。

Dynatraceのエージェントインストールは、UIの分かりにくさから最初は少し迷った。どこにインストール手順があるのか分からず、最終的に検索して「OneAgent」と呼ばれるエージェントのインストールページにたどり着いた。そこでPaaSトークンを生成し、表示されたコマンドを仮想サーバーで実行した。OneAgentのインストールには少し時間がかかったが、インストールが完了すると、Datadogとは異なり、追加の設定なしでPythonアプリケーションとMongoDBの両方を自動的に監視し始めた。これはDynatraceの大きな特徴と言える。

インフラ監視の画面を見ると、DatadogはCPUやメモリなどの基本的な情報を分かりやすく表示し、APM（アプリケーション性能監視）は別のタブに分かれていた。Dynatraceは、一つの画面でインフラのメトリクスだけでなく、その上で動いているプロセスやアプリケーションの情報をまとめて表示する。この統合されたビューから、例えばPythonアプリケーションの詳細をクリックすると、それがMongoDBとどのように連携しているかまで見られるのは非常に興味深かった。

アプリケーション監視に関しては、DatadogはAPM専用のタブがあり、PythonアプリケーションとMongoDBそれぞれの詳細な性能メトリクス（リクエスト数、エラー率、応答時間など）を明確に確認できた。それぞれの情報がパネルごとに分かれているため、必要な情報を素早く見つけることができた。一方、Dynatraceでアプリケーションメトリクスやログ、トレース（アプリケーション内の処理の流れ）を見るには、再びUIで迷うことになった。結局、OpenTelemetryを使った計装（監視に必要な情報を収集する仕組みを組み込むこと）を選び、ドキュメントを読みながらアクセス用のトークンを生成し、PythonのOpenTelemetryパッケージをインストールしてアプリケーションを再起動する必要があった。この設定はDatadogと比較してやや複雑だった。しかし、一度設定してしまえば、DynatraceのUIは非常に詳細なトレース情報を表示し、そこから関連するログも確認できるなど、深い分析が可能であった。

ログ監視の導入はDynatraceの方が簡単だった。Datadogでは、エージェントの設定ファイルを手動で編集し、ログ監視を有効にした上で、監視したいログファイルのパスを別の設定ファイルで指定する必要があった。これにはコマンドラインでの操作や設定ファイルの編集が伴うため、初心者には少し手間がかかるかもしれない。エージェントを再起動して初めてログの収集が開始された。対照的に、DynatraceはOneAgentをインストールするだけでデフォルトでログ収集を開始し、カスタムのログファイルを監視したい場合も、仮想サーバー側での設定変更は不要で、DynatraceのUIからログファイルのパスを指定するだけで済んだ。この点はDynatraceの利便性が際立っていた。

次に、両者のAI機能を見ていこう。DynatraceのDavis AIは、業界トップレベルのAIOps（AIを活用した運用）機能を提供している。これは、問題が発生した際にその根本原因を自動で特定したり、ユーザーに影響が出る前に異常を予測したり、さらには事前に定義された手順に基づいて問題を自動で修正したりすることも可能だ。複雑な問題を平易な言葉で説明する機能も備えている。一方、DatadogのWatchdogは、メトリクスやログの異常パターンを検出し、関連するアラートをグループ化してノイズを減らす機能がある。インシデント発生時には関連するダッシュボードを推奨してくれるが、最終的な原因特定や解決には人間の手による分析が必要となる。つまり、Dynatraceは完全な自動化を目指しているのに対し、Datadogは強力なツールを提供しつつも、人間の判断と介入を重視していると言える。どちらを選ぶかは、AIによる自動判断を優先するか、それとも人間がコントロールする余地を残したいかによって変わるだろう。

料金体系は両者で大きく異なるため、注意が必要だ。大規模なシステムを想定したシナリオ、例えば100台のサーバーがあり、毎月50TBのログが発生するような場合を考えると、Datadogではインフラ監視、APM、ログ管理など各機能ごとに費用がかかる。さらに、カスタムメトリクス（独自に収集するデータ）の数が増えると料金が大きく跳ね上がる可能性があり、請求が複雑で予測しにくい。一瞬の利用スパイクでも月全体の料金に影響する「99パーセンタイル請求」といった仕組みもあるため、想定外のコストが発生しやすい。一方、Dynatraceは「フルスタック監視」という形で、インフラ、APM、ログ、RUMなどがまとめて提供されるため、1台あたりの基本料金は高いものの、トータルで見るとDatadogよりも安くなる場合がある。特に、追加のカスタムメトリクスで費用が増える心配が少ない。Datadogは個別の機能を選んで利用する際には柔軟性があるが、すべての機能を活用しようとすると非常に高価になる可能性がある。Dynatraceは初期費用が高いが、複雑な大規模環境においては最終的な運用コストが抑えられる可能性があると言える。

公式ドキュメントに関しては、個人的にはDatadogの方が分かりやすく、知りたい情報にすぐにアクセスできた。DatadogはYouTubeに解説動画も多く、学習リソースが豊富である。Dynatraceのドキュメントは複数のページを行き来する必要があり、情報を探し出すのに手間取ることがあった。

最終的な評価としては、Dynatraceは、AIによる強力な自動化、統合されたプラットフォーム、そして大規模なエンタープライズ環境でのトータルコストパフォーマンスの点で優れている。特に、複雑なシステムの問題を自動で特定し、解決までを支援する能力は魅力的だ。一方、Datadogは、開発者にとっての使いやすさ、豊富な統合機能、ダッシュボードの柔軟性、そして活発なコミュニティと充実したドキュメントで優位に立つ。どちらのツールも高価なエンタープライズ向けであるため、システムの規模やチームのスキル、自動化への志向性によって最適な選択は変わるだろう。強力な自動化とエンタープライズ向けの複雑な要件があるならDynatrace、開発者体験と柔軟なカスタマイズを重視し、クラウドネイティブな環境であればDatadogが適していると言える。

ただし、DatadogもDynatraceも高額なツールである。もし費用対効果の高い代替案を探しているのなら、「SigNoz」のようなOpenTelemetryネイティブなソリューションも検討する価値がある。SigNozはメトリクス、トレース、ログを一つのプラットフォームで提供し、オープンスタンダードに基づいているため、特定のベンダーに縛られる「ベンダーロックイン」のリスクを避けられる。また、ホストごとの課金がなく、カスタムメトリクスによる追加料金も発生しないため、コストが予測しやすく、Datadogと比較して70〜90%のコスト削減が報告されている。クラウドサービスとして手軽に始めることも、自社でホストすることも可能で、データのプライバシー要件に応じて柔軟な選択肢が用意されている。OpenTelemetryというオープンな規格は、将来的に様々なツール間でデータを連携させる上で非常に重要な技術となるため、これに対応したツールを選ぶことは、長期的な視点で見ても賢明な選択と言えるだろう。