スタックトレース監視: ユーザー体験のギャップ

フランクフルトの買い物客が「支払う」ボタンをクリックし、スピナーを10秒間見つめた後、あきらめます。その間、あなたのAPMダッシュボードはずっと緑のままです。例外は発生せず、スタックトレースも捕捉されません。コードに何の失敗もなかったからです。支払いプロバイダーのスクリプトがハングし、ページは最後までレンダリングされず、注文は流れました。バックエンドは最終チェックアウトリクエストさえ受け取っていないため、検査すべき失敗トランザクションは存在しません。アプリケーションの視点では、何も起こっていません。ユーザーの視点では、唯一重要なステップが失敗したのです。

これがこの記事で扱う盲点です。スタックトレース監視はその役割において真に優れています。コードが例外を投げたときに、開発者にファイル名、行番号、そこに至る呼び出しの連鎖を知らせます。問題は、構造的に見えないものです。ユーザーに直接影響する多くの障害は、リクエストがコードに到達する前、レスポンスがコードを離れた後、あるいはエラーが発生しないまま起こります。

ここではスタックトレース監視がうまく捉えるもの、ユーザー体験の測定における5つのギャップ、そして合成リブラウザ監視がカバーする領域を説明します。

スタックトレース監視とは？

スタックトレースとは、エラー発生時点での呼び出しスタックのスナップショットです。どの関数がどのファイルの何行目で実行されていたか、どの順番で呼び出されたかが分かります。コンソールエラーでメソッドとファイルパスの連鎖が表示されたことがあれば、それを読んだことになります。

スタックトレース監視はアプリケーションパフォーマンス監視（APM）ツールが一般的に行うもので、これらのトレースを自動的に捕捉、グルーピングし、例外の発生頻度を追跡します。チェックアウトサービスでNullPointerExceptionが発生し始めると、APMは開発者に正確な場所と問題の広がりを知らせます。通常ログファイルに埋もれる例外が順位付けされ、傾向が見え、担当者が割り当てられる仕事となります。

このトリガー条件に注意してください。この記事の全てはここから導かれます。スタックトレースはコードが実行されてエラーが発生したときだけ存在します。この両方の条件が重要です。コードが一度も実行されなかったり、エラーを出さずに実行された場合、ユーザーが何を経験してもトレースは存在しません。

覚えやすい実用的な認識としては、コードが実行されて例外を出せばトレースが得られる。コードが遅く実行されたが例外がなければトレースはない。コードに到達する前にブラウザが失敗した場合はトレースなし。レスポンス後にコード外の何かが妨げた場合もトレースなし。4つの状態のうち証拠があるのは1つだけで、ユーザーはその4つのすべての状態にいます。

スタックトレース監視が捉えるもの

以下はAPMに対する批判ではありません。コードに起因する障害に対して、スタックトレースは症状から修正までの最速のルートです：

• 迅速な根本原因特定。 トレースは失敗した行とそれに至る呼び出し経路を指し示し、手動デバッグに必要な推測のほとんどを排除します。
• 詳細なエラーコンテキスト。 良いトレースはメソッドの引数、変数の状態、リクエストのメタデータも含むため、コードが壊れた場所だけでなく、どのような条件下で壊れたかも開発者に伝えます。
• エンジニアリングチーム共通の言語。 トレースは正確かつ再現可能です。チケットに貼り付けることで長文の説明以上に多くを伝えられます。
• コード品質の傾向。 どの例外がどこで再発しているかを追跡することで、障害を起こす前にリファクタリングすべき脆弱なモジュールや悪いパターンが明らかになります。

APMツールは保ち続けましょう。問題はスタックトレースが役立つかではなく、それがユーザー体験を表しているかです。表していません。そのギャップは5つの異なるカテゴリーに分類されます。

ギャップ：スタックトレースがユーザー体験について見逃すもの

これら5つのギャップは偶然の盲点ではありません。境界における問題です。借用コード、アプリケーション前のインフラ、ブラウザの実行、地理的要素、時間です。スタックトレースはアプリケーション境界内では強力ですが、ユーザーの旅がそこを越える場所では弱いのです。

サードパーティスクリプトと外部API

現在の典型的なページは、他社のサーバーから支払いウィジェット、タグマネージャー、チャット、解析、広告スクリプトを読み込みます。これら依存先の1つが停止したり遅くなったりすると、ユーザーのページは停止しますが、失敗したコードは自分のものではないため、計測は何も捕捉しません。明確な例外があるとは限らず、第三者のエンドポイントは応答しますがレンダリングをブロックするほど遅いことが多いです。サードパーティコンテンツは典型的にユーザーが影響を受ける一方、内部のダッシュボードはすべて緑のままのケースです。

DNS、TLS、CDNの障害

リクエストがアプリケーションに届く前に、ドメインの解決、TLSハンドシェイクの交渉、多くの場合CDNエッジを通過する必要があります。DNSレコードの誤設定、期限切れの証明書、障害のあるエッジノードはユーザーを玄関口で止めます。コードは一度も実行されないため、定義上スタックトレースは生成されません。インフラ内から最も分かりやすい症状は沈黙です。トラフィックが減少し、原因の説明はありません。DNS、TCP、TLS、HTTPレイヤーは外部からのチェックでしか観測できない形で失敗します。

フロントエンドのレンダリングとUI障害

サーバーサイドAPMはバックエンドが有効なレスポンスを適切な時間内に返したことを確認しますが、ブラウザの動作は何も保証しません。あるブラウザバージョンで壊れるJavaScriptバンドル、モバイルで崩れるレイアウト、クリックハンドラがバインドされないボタンなど、サーバーログはきれいな200を記録していてもユーザーは壊れたページを見続けます。クライアントサイド例外は別に収集可能ですが、遅いレンダリング、レイアウトシフト、操作不能なコントロールはほとんど例外を投げず、静かにユーザーを失います。Next.jsアプリのハイドレーション障害は現代の代表例です。サーバーは完全に形成されたHTMLで完璧な200を返しますが、クライアントのJavaScriptが失敗し、ユーザーは見た目は正しいが何もしないページを受け取ります。監視すべきイベントはJavaScriptが例外を投げたかではなく、マイルストーンが完了したかです：ボタンのクリック可能、フォームの送信、確認表示。スタックトレースは例外を記録しますが、ユーザーはマイルストーンの欠如を体験します。

地域的な障害

計測はインフラ内で集計されます。ある地域とサーバー間のキャリア経路が劣化したり、特定地域のCDNエッジが障害を起こしても、ユーザーはそこでタイムアウトを経験し、平均値はほとんど動きません。スタックトレースはユーザーの位置を一切認識せず、実行中のコードのみを知っています。地域的な障害はコード中心の視点では構造的に見えません。

遅いことは例外ではない

最も微妙なギャップです。パフォーマンス低下は決して例外を投げません。ページ読み込みが2秒から8秒に遅くなってもエラーは生成されず、ユーザーは徐々に離脱します。一般的にマーケティングがファネルの低下で最初に気づき、エンジニアの呼び出しよりかなり早いです。コードの視点からは何も壊れていないからです。スタックトレース監視はまた、エラー発生後に報告する受動的な性質があり、出力はコードベースを知る人しか読めません。トレース自体は応答時間やページ読み込み速度、ユーザー向けパフォーマンス指標を記録しません。アプリケーションは使い物にならないほど遅くても、スタックトレースの観点では完全に健全なのです。

合成監視がギャップを埋める方法

合成監視は問題に逆方向からアプローチします。コードに計測を入れてエラーを待つのではなく、世界中の実際のブラウザからスケジュールされたスクリプトによるチェックを実行し、該当の場所と瞬間のユーザーが実際に得る体験を正確に測定します。この反転は各ギャップを直接カバーします：

• コードだけでなくページ全体をロードする。 リアルブラウザチェックはページ内のすべてのサードパーティスクリプトを実行します。タグマネージャがハングしたり支払いウィジェットが遅ければ検知し、ウォーターフォールチャートでどのリソースがどれだけ遅延したかを示します。
• ユーザーが始める場所から開始する。 すべてのチェックはネットワーク外部からDNS解決、TLS交渉、CDN経路をたどります。期限切れ証明書や故障したエッジノードは1サイクル内に検出され、不明なトラフィック減少として後から表面化しません。
• 実際のブラウザでレンダリングする。 ブラウザエンジンを動かすため、壊れたスクリプト、応答しない要素、レンダリング障害は失敗したステップとして現れ、クライアント側の見えない問題になりません。
• 多くの地理的場所から実行する。 世界中の拠点からのチェックは地域的障害を特定します。フランクフルトで失敗しダラスは合格すると、ユーザーのツイート前に問題の範囲がわかります。
• エラーの有無にかかわらず速度を測定する。 各チェックはロードや各ステップのタイミングを記録します。8秒かかったページは設定したしきい値でアラートを出し、技術的に何も壊れていない段階でも早期検出します。

ここから導かれるトリアージルールはこうです。最初のバイト前で失敗したチェックはDNS、TLS、CDNに起因。ウォーターフォールでサードパーティドメインが止まればアプリチームではなくベンダー管理者が初期対応。APMが例外を示しながらチェックがバックエンドに到達する場合はスタックトレースを添えてエンジニアに通知されます。

複数ステップのフローも同様に扱えます。EveryStepスクリプティングを使えば、スケジュールでログイン、検索、カート追加、支払いまでを24時間体制で検証し、収益につながる経路が常時確認されます。

合成監視がコード内部を見ないことは明確にしておきます。バックエンドが例外を投げてチェックが失敗した場合、修正すべき行はブラウザではなくスタックトレースが教えます。だから両方を併用すべきなのです。

APMと合成監視：一緒に使うべき理由

二者択一ではなく、そのように扱うとチームは不意打ちを食らいます。スタックトレース付きAPMは内側から監視し、なぜコードが失敗したのか？に答えます。合成監視は外側から監視し、ユーザーは今いる場所で本当に重要なことをできているか？に答えます。お互いの盲点を補完し合います。

危険な故障とは、各ツール単独では見逃すものです。APMはベンダーのスクリプトによるチェックアウト停止、合成チェック単独は稀な入力でのみ発生する例外。両方を使えばどちらのタイプも見逃しません。

実際には両者はパイプラインを形成します。フランクフルトの合成チェックがチェックアウトフローを失敗させると、ウォーターフォールチャートがDNS、CDN、サードパーティ呼び出し、自社バックエンドのどれかを特定します。もしアプリケーションで終われば、APMのスタックトレースが引き継ぎ、例外を投げた関数を示します。外からの検出、内での診断、ダッシュボードの表示とユーザー体験の間に空白はありません。チーム間対立も解消します。APMだけでは金庫の中に監視カメラがあっても玄関にないのと同じで、不正が起きた後に映像を見て気づく状況です。

Dotcom-Monitorは合成監視の側に位置します。APMプラットフォームではなく、New RelicやDatadogのようなツールの代替ではありません。リアルブラウザ合成監視をグローバルなロケーションネットワークから提供し、各ステップのタイミング、ウォーターフォール詳細、フローが遅延や故障した際のアラートを備えています。

まとめ

スタックトレース監視はその地位に値します。コードが例外を投げたとき、開発者を失敗行にいち早く導きます。しかしそのトリガー条件、すなわちコードの実行とエラー発生は、見えない領域を正確に定義します。サードパーティスクリプト、DNSやCDNの障害、フロントエンドレンダリングの破損、地域的障害、そして遅いがエラーなしの劣化は、文字通りの意味で痕跡を残さずユーザーに影響します。

合成リアルブラウザ監視はユーザーが通る全経路を試験し、関心があるすべての地域からスケジュール通りに問題をサポートチケットに先んじて検出し、そのギャップを埋めます。スタックトレースは診断に残し、外から内へのチェックを検出に導入しましょう。ユーザーは全経路を体験するので、監視も全経路をカバーすべきです。

よくある質問