今一度振り返る Datadog の強み ─ 観測から行動へ（Datadog Live Tokyo 2025 登壇内容振り返り）
はじめに
皆様こんにちは、初めまして。Datadog で Sales Engineer をしている azush と申します！
先日 12/16、今年最後の Datadog イベントとなる冬版の Datadog Live Tokyo 2025 が開催されました。ご登壇、ならびにご来場いただいた皆様、誠にありがとうございました。
僭越ながら、この日私も登壇させていただき、「観測から行動へ: Datadog で実現する"活きる"オブザーバビリティ」というタイトルでお話しさせていただきました。
本記事では、登壇内容をサマライズしながら、Datadog の活用例をいくつかご紹介できればと思います。
あらためてオブザーバビリティとは
オブザーバビリティが Observe と Ability を組み合わせた造語であることを踏まえ、
「データを取って終わりではなく、"活用" できてはじめてオブザーバビリティです！」
という論調から、可視性や操作性の重要さをお伝えしました。
つまるところ、オブザーバビリティツールには
- 欲しいデータがちゃんと取得できるのか
はもちろんのこと、
- 収集したデータをいかに "簡単に活用できる" か
が求められ、これがそのまま技術観点の選定基準になると考えています。
Datadog では何ができるのか
Datadog はプロダクトのカバー範囲が幅広いだけでなく、「画面の見やすさ」や「直感的に操作できる」ことにかなりの重きを置いています。
当日序盤のデモでは、
- 「複数台あるサーバのどれが高負荷な状態にあるのか」を容易に確認し、
- そこから「どのプロセスが高負荷に起因しているのか、ログからどんな問題が発生しているのか」を特定し、
- 「接続先エンドポイント側に問題がある（※）」ことを
すべてクリック操作のみで紹介し、Datadog では複数のシグナルを直感的に行き来できることを示しました。
（※）エンドポイントまでのネットワーク経路や接続状況を可視化するプロダクトとして、Datadog Network Path を紹介しました。Network Path については、以前執筆した記事があるので、こちらも合わせてご覧ください。
UI を持つ現代システムのオブザーバビリティ
上記では単一サーバを例に紹介しましたが、現代のシステムはマイクロサービス化や外部連携により、「監視対象が多面化してきた」という投げかけから、現代システムにおいて何を Observe（観測）すべきか を整理しました。
オブザーバビリティの文脈では、メトリクス・ログ・トレースの 3 つのシグナル が重要だと言われますが、これは主にバックエンドの話だと言えます。
UI を持つシステムでは、バックエンドだけを見ていても十分ではなく、実際のユーザー体験（e.g. ページの表示速度、操作時の待ち時間など）といった情報も取得することで、より良い監視や分析につながります。
そのため、現代的なシステムでは
- メトリクス
- ログ
- トレース
- フロントエンド（ユーザー体験）
という 4 つのシグナルを揃えて観測すること が今後より重要になってきます。
そしてその上で 『Observe（観測）だけでなく、Ability（活用）できて初めてオブザーバビリティですよ！』 と繰り返しお伝えしました。
Datadog における 4 つの観測データの活かし方
今回の登壇ではより実践的なイメージを持ってもらうために、私が事前に用意したサンプルアプリケーションを用いた参加型のリアルタイムデモを行いました。
会場の皆さんに実際にアプリへアクセスしていただき、その場で発生したデータを Datadog 上で一緒に確認していく、という初の試みでした。
障害対応：ユーザー体験から原因までを辿る
このアプリでは、「大量に購入操作を行うとエラーが発生する」ような挙動を意図的に仕込んでいました。
ここで、仮にエラーの最初の気づきが 「ユーザーからの問い合わせ」 であった場合を考えてみます。
Datadog では、まず問い合わせに含まれるユーザー名を起点に、そのユーザーのフロントエンド上での挙動やエラーを確認できます。
さらに、「そのときユーザーがどのような画面操作を行っていたのか」を Datadog 上で再生動画として確認できるため、ユーザーへ詳細なヒアリングを行わずとも、エラーの再現方法や発生条件を把握することが可能です。
※このスクリーンショットは、私の操作履歴です
Datadog では、こうしたフロントエンドの情報とバックエンドのデータを相関させることができ、同じ画面から 「このときバックエンドでは何が起きていたのか」 を容易に辿ることができます。
今回の例では、INT 型の最大値を超える数値が入力され、その値が SQL クエリ実行まで一度も検証（バリデーション）されなかったことが原因で、Internal Server Error がフロントで発生していました。
パフォーマンス分析： ボトルネックの特定
当日のアクセス状況を確認すると、講演開始時間付近でアクセス数が一気に増加しており、その中でも処理に時間のかかっているリクエストと、短時間で完了しているリクエストが混在していました（当日アクセスしていただいた皆様、ありがとうございました）。
グラフ上で分析したい対象のトレース・スパンを ドラッグして長方形で囲む ことで、通常とは異なる unusual な処理と、一般的な typical な処理に分類できます。
これにより、それぞれのグループに含まれるトレース・スパンが、どのような属性や条件を持っているのか を容易に確認できます。
デモアプリでは、あらかじめ 一つだけ処理に時間のかかるステッカー を用意していましたが、来場者のアクセスによって「どのステッカーの処理が遅くなっているのか」を容易に可視化することができました。
フロントエンド分析： ユーザーの操作傾向
最後にフロントエンドの分析例として、ヒートマップやファネルビューを用いた分析を紹介しました。
ヒートマップでは、ユーザーが実際にどこをクリックしているのかを可視化でき、「本来はクリックできない箇所が頻繁に押されている」といった UI 上の課題にも気づくことができます。
また、ファネルビューを用いることで、特定の操作フローにおいてどの段階でユーザーが離脱しているのかを把握でき、ユーザー体験の改善ポイントを明確にすることができます。
このように、バックエンドの状態だけでなく、ユーザーの操作や体験そのものを観測できる点も、UI を持つ現代システムにおいて必要になります。
余談ですが、当日のアクセスデバイスを分析すると、iOS + Safari ユーザーが半分を占めていることがわかりました。やはり iPhone ユーザー多いですね。
このような分析も Datadog で行うことができます、というご紹介でした。
※デモアプリで個人を特定できる情報は収集していません。
おわりに
本記事では、Datadog Live Tokyo 2025 の登壇内容を振り返りながら、 現代システムにおけるオブザーバビリティの考え方と、Datadog を用いた具体的な活用例をご紹介しました。
オブザーバビリティは、単にデータを集めることがゴールではなく、「気づき、原因を理解し、次の行動につなげる」 ためのものだと考えています。
Datadog では、バックエンドからフロントエンドまでのデータを横断的に扱い、状況に応じて自然に行き来できることで、観測をそのまま行動へとつなげることができます。
本記事が、皆様のシステム運用や改善のヒントになれば幸いです。
最後までお読みいただき、ありがとうございました！
Discussion