WebView2 モニタリング¶
Windows RUM SDK は、WPF、WinForms、WinUI 3 の Microsoft Edge WebView2 コントロールを関連付け、ページ内の View、Action、Resource、Error をホストの Windows Session と View に関連付けることができます。
WebView2 データモニタリング¶
前提条件¶
- アプリが Windows SDK 導入 を完了していること;
- プロジェクトに Microsoft Edge WebView2 がインストールされ、正常に初期化できること;
- 対象コントロールが
CoreWebView2とEnsureCoreWebView2Async()を公開していること。
自動検出¶
EnableWebView はデフォルトで true です。デスクトップ自動収集を有効にすると、SDK はサポートされているコントロールツリー内で WebView2 を検出します:
GuanceSdk.EnableAutomaticInstrumentation(new AutomaticInstrumentationOptions
{
EnableWebView = true
});
動的に作成される WebView2、ライフサイクルが独立している WebView2、または導入タイミングを明示的に制御したい WebView2 には、明示的な関連付けを推奨します。
明示的な関連付け¶
拡張メソッドを使用することもできます:
同じコントロールを重複して関連付けても、二重注入は行われません。コントロールが不要になった場合は、明示的に切り離すことができます:
コントロールが Disposed または Unloaded をトリガーすると、SDK も関連付けを自動的にクリーンアップします。
収集内容¶
| データ型 | 収集内容 |
|---|---|
| View | 初期ナビゲーション、完全ナビゲーション、History API のルート変更、ページタイトルと最終 URL |
| Action | ページのクリックとサポートされているユーザーインタラクション |
| Resource | fetch、XMLHttpRequest、Performance Resource エントリ |
| Error | JavaScript Error と未処理の Promise rejection |
SDK は関連付けた各コントロールに独立したブリッジトークンを注入し、ホスト側で app_id、Session、View、SDK アイデンティティなどの予約フィールドを上書きします。ページスクリプトはブリッジメッセージを介してホストの関連フィールドを変更できません。
ホスト View との関係¶
WebView2 のページデータはホストの Windows Session を引き継ぎ、現在のホスト View に関連付けられます。ページナビゲーションによってページ View データが生成されますが、独立した Windows SDK クライアントは作成されません。
1 つのウィンドウに複数の WebView2 が含まれる場合は、各コントロールを個別に関連付け、コントロールのライフサイクルを安定させてください。
Log と Trace の境界¶
- Windows ホストは
GuanceSdk.AddLog()を使用して Log を書き込み、現在のホスト RUM コンテキストに基づいて関連付けることができます。 - WebView2 ブリッジは現在、ページの
console出力を自動的に Windows Log に変換しません。 - Windows の
HttpClientTrace 設定はホストが開始したリクエストにのみ適用され、renderer 内のfetchやXMLHttpRequestに Header を注入しません。 - ページ側で独立した Log または Trace 機能が必要な場合は、ページで採用している Browser SDK の設定を使用し、同じ Resource を重複して収集しないようにしてください。
プライバシー境界¶
- URL クエリパラメータには、ホスト Resource と同じマスキング設定が適用されます。
- ページメッセージ内の URL フィールドは、RUM キューに入る前に再度処理されます。
- 認証 Header、Cookie、Token などのパラメータはデフォルトでマスキングされます。
- パスワード、Token、ファイルの絶対パス、ユーザー入力の原文をページのカスタムフィールドで送信しないでください。
詳細な設定については、プライバシーと権限の説明 を参照してください。
実験的 Session Replay¶
Windows Session Replay はデフォルトで無効ですが、WebView2 はホストで GuanceConfig.SessionReplay.Enabled = true を設定した後、明示的に有効にして検証できます。SDK は Android WebView と互換性のある FTWebViewJavascriptBridge を注入します。ネイティブ設定で Replay が許可されると、getCapabilities() は records を返し、ページの Browser collector が生成した rrweb record をホストが Windows Session と WebView View に関連付け、ネイティブ Replay キューを介してアップロードします。
ページでは Browser RUM を読み込み、window.DATAFLUX_RUM が利用可能になった後に最小限の初期化を実行する必要があります。まず init() を呼び出し、次に Session Replay を開始します:
window.DATAFLUX_RUM &&
window.DATAFLUX_RUM.init({
// Bridge モードでも受信アドレスの検証は行われますが、RUM データは
// FTWebViewJavascriptBridge 経由で送信されるため、このアドレスへのリクエストは発生しません。
datakitOrigin: "http://127.0.0.1",
});
window.DATAFLUX_RUM &&
window.DATAFLUX_RUM.startSessionReplayRecording();
ここでの datakitOrigin は Browser RUM の初期化検証にのみ使用されます。http://127.0.0.1 を Bridge 検証用のプレースホルダー値として固定し、ローカルページで無効な Origin が発生するのを防ぎます。実際のアプリケーション ID、レポートアドレス、Session、サンプリング、プライバシーポリシーはすべてホストの Windows SDK が提供するため、ページ側で重複して設定しないでください。
Replay のサンプリングとプライバシーポリシーはホスト設定によって決定され、ページ側で上書きすることはできません。この機能は依然として実験的であり、安定互換の保証には含まれません。導入と検証の方法については、RUM 設定 と Electron ネイティブ Bridge を参照してください。
制限¶
- WebView2 renderer 内の Long Task は、現在のブリッジによる収集範囲には含まれません。ホスト UI スレッドのカクつきは引き続き Windows SDK が収集します。
- クロスオリジン iframe は、ブラウザの同一オリジンポリシーとスクリプト注入境界の制約を受けます。
- WebView2 Session Replay は実験的な機能です。クロスオリジン Frame、Canvas、カスタムレンダリングコンテンツ、プレイヤーの互換性は、対象アプリケーションで個別に検証する必要があります。
一般的なトラブルシューティング¶
検証¶
- コントロールを関連付け、ページナビゲーションを 1 回完了します。
- ページ内のボタンをクリックします。
fetchまたはXMLHttpRequestを 1 回実行します。- 制御可能な JavaScript Error を 1 回発生させます。
- コンソールで、ページの View、Action、Resource、Error がホスト Session に関連付けられていることを確認します。
初期化に失敗した場合は、GuanceSdk.AddDiagnosticListener() を使用して、WebView2 initialization failed、did not succeed、コントロールタイプの不一致などの診断を確認してください。