⛳
【オブザーバビリティ】DatadogとDynatraceの主な機能比較(初心者向け)
概要📝
オブザーバビリティツールである、DatadogとDynatraceを比較することにより、まだあまり知られていないDynatraceについて知ってもらう🙇♂️
対象読者🔖
- SRE、オブザーバビリティの初級者で興味がある方
- Dynatraceをあまりよく知らない方
- よくわからないけど、興味がある方
筆者は、クライアントに対してオブザーバビリティツールを導入・運用支援を行う会社でエンジニアとして働いています。オブザーバビリティに関わってまだ1年程度ですので、初心者向けの内容となります✨
筆者の経験として、あるクライアントに対してPoCとしてDatadogとDynatraceの比較検討を行ったことがあり、それをベースにしています📝
オブザーバビリティとは❓
初心者向けということで、従来の監視とオブザーバビリティの違いをざっくりイメージいただく表を用意しました📈
オブザーバビリティ自体は「可観測性=どれだけ観測しやすいか」を示す英単語ですが、よりエンジニアの文脈に沿って説明しています📝
オブザーバビリティツールでは、フロント・バック・インフラを一貫したコンテキストとして理解できるので、根本原因の特定がしやすく、より信頼性の高いシステム運用に貢献できます👓
項目 | 監視 | オブザーバビリティ |
---|---|---|
何を問題だと考えるか (障害あるいは障害につながる問題の定義) | CPU・メモリなど、システム運用者の視点から問題を定義することが多い | トラフィック、レスポンスタイム、エラー率など、アプリのユーザー視点で「ビジネスとして実際にユーザーに影響があるのか」を問題として定義できる |
問題の検知 | 静的な閾値によるため、問題を事前に予測する必要がある 既知の問題への対応がメイン | AIによる学習と静的な閾値を両方利用できる 学習した傾向からの逸脱を検知することにより、未知の問題にも対応可能 |
問題の影響範囲の特定 | コンテキストによる分析が難しいので、影響範囲の特定に時間がかかる | コンテキストベースで分析できるため、画面UIで影響範囲をトポロジカルに可視化できる |
問題の根本原因の分析 | フロント、バック、インフラのログが別々の場所に存在するため、コンテキストによる分析が難しい 分析者の経験により分析の質が変わる | フロント、バック、インフラのログがつながっているため、コンテキストベースで分析できる 根本原因と考えられる部分を、画面UIで確認できるので、誰でも質の高い分析ができる |
情報の集約と可視化 | ログやデータが散らばっているため、取りまとめが難しい | ログやデータが一か所に集約しているので、カスタムのダッシュボードを作成しやすい |
問題のポストモーテム (解決過程や再発防止策) | ログやデータが散らばっているため、取りまとめが難しい | ログやデータが一か所に集約しているので、ポストモーテムの過程を記録しやすい |
Datadog・Dynatraceの比較&対応表👓
DatadogとDynatraceの主な機能について比較します👓
正直、大きな差異があるのはエージェントの導入容易性くらいですので、比較表というより対応表と見た方がいいかもしれません🙇♂️
特にDynatraceは初心者には若干UIがわかりづらいので、この機能ってここにあるのか!と整理になるかと思います👇
項目 | Datadog | Dynatrace |
---|---|---|
エージェント | datadog.yamlなどの構成ファイルに記述を追加することで、APMなどさまざまな監視設定を有効化していく (一部インストール時に、引数を与えることで有効化できるものもある) |
インストールすれば、自動的にフロント~バック~インフラまでつながった状態で監視が有効化される |
RUM(Real User Monitoring) フロントエンド監視 |
RUM→リアルユーザーの体験などを分析 Session Replay→実際のセッションを動画で確認 ページパフォーマンスの監視→ウォーターフォール分析と同じ |
RUM→画面ではWeb Session Replay Waterfall analysis→フロントからバックまでの一連の処理の流れを分析 |
APM(Application Performance Monitoring) バックエンド監視 |
APM→バックエンド処理を中心に分析 Distributed tracing→トレースの一覧 |
APM→画面ではServices Distributed traces |
インフラ監視 |
インフラストラクチャ ライブプロセス |
Host Process analysis Process group availability→同じ機能を複数ホストにわたって実行するものを自動でグループ化 |
ログ・イベント監視 | 設定ファイルに記載したログファイルのみを取得(ワイルドカードなどは使用可能) 検索時は直感的に操作可能 |
エージェントインストールすれば自動でログを取得。特定のログを除外などは可能 検索時はDQLという独自言語でクエリする |
SLO | SLO | SLO |
AIによるアラート | Watchdog →AI学習によりパターンからの逸脱を検知、根本原因や影響範囲を自動分析 |
Anomaly Detection→AI学習によりパターンからの逸脱を検知 Problem→上記で検知した内容について、根本原因や影響範囲を自動分析 |
ユーザー定義によるアラート | モニター | Metric Events |
サービスマップの可視化 | サービスマップ | Smartscape→アプリ、サービス、プロセス、ホスト、データセンターのどこで問題が起きているのかを可視化 |
ダッシュボードなどの可視化 |
ダッシュボード ノートブック |
Dashbords Notebook |
他サービスとの連携 | インテグレーション | Hub |
UIの使いやすさ | 私見ですが、直感的に操作できる見やすいUIです | 私見ですが、操作には多少の慣れが必要です |
さいごに
まだまだ細かい機能で差があるかもしれませんが、基本的には機能は同じか代替手段があると感じました。
複数のオブザーバビリティツールを比較したり、顧客に提供したりすると頭が混乱することがありますので、このようなざっくりした表でもあると助かると思いました。
何か気づきがあれば、更新していきます🙇♂️
Discussion