フロントエンドで収集するべきテレメトリは何か
先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした(※本記事は上記記事の内容を知らなくても読み進められるようになっています)。
というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。
重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。
一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。
そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。
監視 SaaS と OpenTelemetry (OTel)
Datadog, New Relic, Sentry のいずれかを利用することを考えます。
Datadog と New Relic では、アプリケーションを OTel ライブラリで計装している場合、各 SaaS に転送する方法として OTel コレクターを利用するか SaaS のエージェントを利用するかを選ぶことができます。
一方で Sentry では計装にあたって Sentry の SDK を使う必要があり、ブラウザ JS は対応していません。
OpenTelemetry と JavaScript
OpenTelemetry は主にトレース、メトリクス、ログの 3 つのシグナルで構成されていますが、各シグナルの仕様は概ね Stable になっており、言語によっては実装も Stable なものもあります。
JavaScript についてはトレースとログが Stable になっており、ログは Development です。
しかしブラウザ JS については実験的でほとんどが未定義と警告されています。
Client instrumentation for the browser is experimental and mostly unspecified.
以上を踏まえて、本記事執筆時点ではブラウザ JS で OpenTelemetry を利用するのは避け、監視 SaaS ベンダーの SDK を利用した方が良いでしょう。
トレース
フロントエンドも含めた分散トレーシングはパフォーマンス監視において重要です。
パフォーマンスの問題が生じた時にフロントエンド側のスパンがあれば、問題がフロントエンドにあるのかネットワークにあるのかバックエンドより後ろにあるのかを切り分けることができます。
フロントエンドも含めた分散トレーシングは Datadog, New Relic, Sentry の 3 つ全てが対応しています。
メトリクス
パフォーマンス
各 SaaS の RUM (Real User Monitoring) で収集されるデータはパフォーマンスに関するフロントエンドのメトリクスです。
特に Core Web Vitals には全ての SaaS が対応しています。
地理位置情報
グローバルビジネスの場合にはユーザの地理位置情報を収集することも重要です。
Datadog と New Relic の RUM は地理位置情報も収集しています。
Sentry は対応していないので、IP Geolocation や Geolocation API などで自前で収集することになるでしょう。
それ以外は重要ではない
他には何があるでしょうか。
残念ながら上記以外にフロントエンドでのみ収集できる重要なメトリクスはないと考えています。
ビジネスやサービスにとって重要な指標はバックエンドでも収集できるでしょう。
重要度は低いもののNavigator
インターフェースで取得できる情報はユーザの属性を理解するのに役立ちます。
例えばNavigator.connection
, Navigator.deviceMemory
, Navigator.hardwareConcurrency
を収集することで、ユーザがどのようなスペックでアプリケーションを利用しているのか知ることができます。
これらを利用することでフロントエンドのパフォーマンス改善の際にどの程度のスペックを考慮すれば良いか知ることができるでしょう。
またinnerWidth
, innerHeight
を収集しておけば、デザインに当たってどの程度の画面サイズを考慮すれば良いかを知ることができるでしょう。
SaaS のカスタムメトリクス対応状況
Sentry は SDK を利用することでメトリクスを収集することができます。
Datadog と New Relic は REST API にメトリクスを投稿することになります。
ログ
ログはフロントエンドにおいても重要です。
ユーザの意図しない動作(例外や関数の入力が不正な場合、到達不能なはずの行に到達してしまった場合など)にはエラーログを出力べきです。
またエラーや性能、問い合わせなどの調査で必要な情報がフロントエンドにしかない場合にもログを出力しましょう。
SaaS の対応状況
例外監視
例外監視は 3 つの SaaS 全てが対応しています。
カスタムログ
カスタムログには Datadog と Sentry が対応しています。
New Relic は対応していませんが、ブラウザ用の API を利用することで例外以外のエラーも監視することができます。
カスタム属性にログレベルを指定する運用でカスタムログに近いことは実現できます。
まとめ
- テレメトリはフロントエンドでも重要
- 現時点ではブラウザ JS で OpenTelemetry を利用するのは避けた方が良い
- フロントエンドのテレメトリの観点では各 SaaS で実現できることはあまり変わらない
Discussion