Web アプリケーションモニタリング（RUM）のベストプラクティス¶

前提条件¶

Guance公式サイトにアクセスしてアカウントを登録し、登録済みのアカウント/パスワードでログインします。
サーバー<DataKit をインストール>

Web アプリケーションモニタリング（RUM）の紹介¶

RUM は Real user monitor（リアルユーザーエクスペリエンス管理） の略称です。モバイルインターネットの発展に伴い、ますます多くの企業が最終的なビジネス成果をエンドユーザー側、すなわち RUM 側に集約しています。具体的な形態としては、Mobile-APP、Web ページ、ミニプログラム（WeChat、Alipay、ByteDance など）があります。インターネット業界の発展に伴い、各業界で競争が激化しており、エンドユーザーの端末体験は、新規ユーザーの獲得、維持、企業イメージ、さらには企業の収益に直接影響します。そのため、エンドユーザーの使用体験を向上させることは、インターネット業界はもちろん、デジタルトランスフォーメーションを進めている、あるいは今後進める予定の従来型企業にとって重要な課題となっています。

RUM の原理の概要¶

原理の説明： RUM のデータ収集方法は何世代にもわたって進化してきました。現在、一般的に使用されているのは、W3C（World Wide Web Consortium）が定義した[navigation-timing] 標準に基づくものです（下図参照）。この標準では、さまざまなブラウザイベントが詳細に定義されています。ブラウザイベントの簡単な計算により、フロントエンドページのファーストビュー、ホワイトスクリーン、DOM 読み込み、HTML 読み込みなどの時間を算出できます。テスト環境の F12 デベロッパーツールと比較して、本番環境における実際のユーザーのフロントエンド体験をより効果的に収集できるため、H5 アプリケーションのシナリオが増加している現在、非常に普及しています。国内の商用ソフトウェア（聽雲、博睿、Cloudwise、OneAPM）は、いずれもこの標準に基づいてカスタマイズされた Web 監視システムを採用しています。この標準は、ほとんどの H5 シナリオに適用されます。

ブラウザ（特に Chrome）やフロントエンド技術の発展に伴い、navigation-timing の限界がますます顕著になっています。例えば、フロントエンドとバックエンドの分離に伴い、シングルページアプリケーションが増加しており、このようなシナリオでは、navigation-timing に基づくデータ収集は煩雑になります。そのため、W3C は新しい標準 [PaintTiming-github] [PaintTiming-api] を発表しました。この標準で新たに提案された指標には、First Paint（初回描画）、First Contentful Paint（初回コンテンツ描画）などが含まれ、実際のユーザーが Web ページにアクセスする際の体験により適しています。DF-RUM は、PaintTiming 仕様をサポートするデータ収集を採用しています。この仕様に興味がある方は、[Paint Timing API を使用したパフォーマンス向上] [painttiming の使用] をご参照ください。

DF が現在サポートしている RUM 監視方法は次のとおりです：

Web アプリケーション：[Web アプリケーションを DF 監視に導入] [Webアプリケーションモニタリングのベストプラクティス]
APP（Android & iOS）：[ Android を DF 監視に導入] [ iOS を DF 監視に導入] [APPモニタリングのベストプラクティス-未作成][]
ミニプログラム（WeChat）：[f] [ミニプログラムモニタリングのベストプラクティス-未作成]

Web ページに RUM を導入する手順¶

1. Guance にログイン¶

2. RUM → アプリケーションを作成 → Web タイプを選択 → 同期読み込みを選択¶

備考：ここでは CDN 同期読み込みを選択します
•フロントエンドの index.html ページを編集します（cp バックアップを忘れずに）
の前に、コピーした JS コードを追加します：

導入方式	説明
NPM	SDK コードをフロントエンドプロジェクトにバンドルします。この方法では、フロントエンドページのパフォーマンスに影響を与えませんが、SDK 初期化前のリクエストやエラーの収集を見逃す可能性があります。
CDN 非同期読み込み	CDN キャッシュを利用して、SDK スクリプトを非同期で読み込みます。この方法では、SDK スクリプトのダウンロードがページの読み込みパフォーマンスに影響を与えませんが、SDK 初期化前のリクエストやエラーの収集を見逃す可能性があります。
CDN 同期読み込み	CDN キャッシュを利用して、SDK スクリプトを同期的に読み込みます。この方法では、すべてのエラー、リソース、リクエスト、パフォーマンス指標を収集できますが、ページの読み込みパフォーマンスに影響を与える可能性があります。

3. フロントエンドページの index.html に RUM 可観測性 JS ファイルを導入¶

$ cd /usr/local/ruoyi/dist/index.html

// バックアップを忘れずに
$ cp index.html index.html.bkd

// index.html に df-js を追加
// DF プラットフォームの JS コードをコピーし、index.html の </head> の前に配置して保存します。例：
// datakitOrigin：DataKit のアドレス。DF における RUM データの流れは：rum.js ファイル → DataKit → DataWay → DF プラットフォーム
// 本番環境の場合は、この IP をドメイン名に設定します。テスト環境の場合は、DataKit がインストールされたサーバーの 9529 ポートに対応する内部 IP を入力します。
// trackInteractions：ユーザーアクション収集の設定項目。ページ上のユーザー操作の統計を実現します。
// allowedTracingOrigins：フロントエンドとバックエンド（RUM と APM）を連携するための設定項目。必要に応じて設定します。フロントエンドページとやり取りするバックエンドサーバーのドメイン名または IP を入力します。127.0.0.1 は単なる例です。

$ vim index.html

<head> 
<script src="https://static.guance.com/browser-sdk/v2/dataflux-rum.js" type="text/javascript"></script>
<script>
  window.DATAFLUX_RUM &&
    window.DATAFLUX_RUM.init({
      applicationId: 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
      datakitOrigin: 'http://127.0.0.1:9529', 
      env: 'test',
      version: '1.0.0',
      trackInteractions: true,
      traceType: 'ddtrace', 
      allowedTracingOrigins: ['http://127.0.0.1']
    })
</script>
</head>

注意事項：

datakitOrigin：データ送信先アドレス。本番環境でドメイン名を設定している場合、ドメイン名のリクエストを DataKit の 9529 ポートがインストールされた任意のサーバーに転送できます。フロントエンドのアクセス量が大きい場合は、ドメイン名と DataKit サーバーの間に SLB を配置し、フロントエンド JS が SLB にデータを送信し、SLB が複数の DataKit（9529 ポート）サーバーにリクエストを分散できます。複数の DataKit が RUM データを処理しても、フロントエンドリクエストの再利用によりセッションデータは中断されず、RUM データの表示にも影響しません。

例：

allowedTracingOrigins：フロントエンドとバックエンド（APM と RUM）の連携を実現します。このシナリオは、フロントエンドに RUM、バックエンドに APM がデプロイされている場合にのみ有効です。フロントエンドページとやり取りするバックエンドアプリケーションサーバーのドメイン名（本番環境）または IP（テスト環境）を入力します。ユースケース：フロントエンドユーザーのアクセスが遅い場合、バックエンドコードのロジック異常が原因である可能性があります。フロントエンド RUM の遅いリクエストデータから、APM データに直接ジャンプして、そのリクエストのバックエンドコード呼び出し状況を確認し、遅延の根本原因を特定できます。実装原理：ユーザーがフロントエンドアプリケーションにアクセスすると、フロントエンドアプリケーションはリソースとリクエストの呼び出しを行い、RUM JS がパフォーマンスデータ収集をトリガーします。RUM JS は trace-id を生成し、リクエストの request_header に書き込みます。リクエストがバックエンドに到達すると、バックエンドの ddtrace がこの trace_id を読み取り、自身のトレースデータに記録します。これにより、同じ trace_id を介して APM と RUM のデータ連携が実現されます。
env：必須。アプリケーションの環境（test、product など）を指定します。
version：必須。アプリケーションのバージョン番号。
trackInteractions：ユーザーアクションの統計（ボタンクリック、フォーム送信など）。
traceType：オプション。デフォルトは ddtrace。現在、ddtrace、zipkin、skywalking_v3、jaeger、zipkin_single_header、w3c_traceparent の6種類をサポートしています。

4. ページを保存、検証、公開¶

ブラウザで対象ページにアクセスし、F12 デベロッパーツールでネットワークリクエストに RUM 関連のリクエストがあるか、ステータスコードが 200 であるかを確認します。

注意事項：F12 で RUM 関連のリクエストのステータスコードが 200 以外、または connection refused の場合は、telnet IP:9529 でポートが開いているか確認します。開いていない場合は、/usr/local/datakit/conf.d/datakit.conf の http_listen を localhost から 0.0.0.0 に変更します（この設定は、現在のサーバーの 9529 ポートへの外部からのアクセスを制御します。127.0.0.1 または localhost に設定すると、ローカルまたは内部ネットワークからのみアクセス可能になります。0.0.0.0 に設定すると、内部ネットワークと外部ネットワークの両方からアクセス可能になります。RUM データの多くは外部ネットワークからのものなので、DataKit サーバーの 9529 ポートへの外部アクセスを許可する必要があります）。例：

RUM と APM のデータ連携（フロントエンドとバックエンドの trace ID による関連付け）¶

前提条件：バックエンドアプリケーションサーバーに APM 監視（ddtrace、dd-agent）がインストールされている必要があります。詳細は分散型トレーシング（APM）のベストプラクティスを参照してください。フロントエンドに df-rum 監視を追加します。
設定方法：フロントエンドの HTML に追加した df-rum-js に allowedTracingOrigins タグを追加し、フロントエンドに対応するバックエンドのドメイン名を入力します。例えば、dataflux.cn に RUM 監視を追加する場合、allowedTracingOrigins に https://www.dataflux.cn/ を設定します。複数のドメインがある場合は、カンマ区切りで複数設定します。サードパーティのドメインは設定しなくても構いません。

連携後の効果の例：

DF Web アプリケーションモニタリング（RUM）の分析¶

関連パラメータの説明：

パラメータ	タイプ	必須	デフォルト値	説明
`applicationId`	String	はい		DataFlux で作成されたアプリケーション ID
`datakitOrigin`	String	はい		DataKit データ送信 Origin 注釈: `协议（包括：//），域名（或IP地址）[和端口号]` 例： https://www.datakit.com, http://100.20.34.3:8088
`env`	String	いいえ		Web アプリケーションの現在の環境。例：prod：本番環境、gray：カナリア環境、pre：ステージング環境、common：日常環境、local：ローカル環境
`version`	String	いいえ		Web アプリケーションのバージョン番号
`resourceSampleRate`	Number	いいえ	`100`	リソースメトリクスデータの収集率： `100` は全収集、 `0` は収集しないことを示します。
`sampleRate`	Number	いいえ	`100`	メトリクスデータの収集率： `100` は全収集、 `0` は収集しないことを示します。
`trackSessionAcrossSubdomains`	Boolean	いいえ	`false`	同じドメインのサブドメイン間でキャッシュを共有する
`allowedTracingOrigins`	Array	いいえ	`[]`	`ddtrace` コレクターに必要なヘッダーを注入するためのすべてのリクエストリスト。リクエストの origin または正規表現を指定できます。origin: `协议（包括：//），域名（或IP地址）[和端口号]` 例： `["https://api.example.com", /https:\\/\\/.*\\.my-api-domain\\.com/]`
`trackInteractions`	Boolean	いいえ	`false`	ユーザーアクション収集を有効にするかどうか

Web サイトのコア指標¶

DataFlux の Web アプリケーション分析は、Google の Web コア指標（LCP、FID、CLS）を統合し、Web サイトの読み込み速度、インタラクティブ性、ページの安定性を測定します。

指標	説明	目標値
LCP（Largest Contentful Paint）	ページの視覚範囲内で最大のコンテンツ要素が読み込まれるまでの時間を計算します	2.5秒未満
FID（First Input Delay）	ユーザーが初めてページとインタラクションした際の遅延時間を計算します	100ms未満
CLS（Cumulative Layout Shift）	ページ読み込み時にコンテンツが動的に読み込まれることでレイアウトが移動する度合いを計算します。0は変化なし。	0.1未満

シナリオ分析¶

DataFlux は、可視化された Web アプリケーション分析を提供します。概要、ページパフォーマンス分析、リソース読み込み分析、JS エラー分析など、多様な Web アプリケーションモニタリングデータのシナリオが組み込まれています。

概要¶

Web アプリケーションの概要シナリオでは、ページアクセスのエラー数、エラー率、セッション数、セッション分布、ブラウザ、OS、最も人気のあるページ、リソースエラーランキングなどを統計し、ユーザーが Web ページにアクセスする際のデータ統計を可視化します。ユーザーが Web アプリケーションにアクセスする際の問題を迅速に特定し、ユーザーアクセスのパフォーマンスを向上させます。環境やバージョンでフィルタリングして、既に導入済みの Web アプリケーションを表示できます。

パフォーマンス分析¶

Web アプリケーションのページパフォーマンス分析では、PV 数、ページ読み込み時間、Web サイトのコア指標、最も注目されているページのセッション数、ページのロングタスク分析、XHR & Fetch 分析、リソース分析などの指標を統計し、Web アプリケーション全体のページパフォーマンスをリアルタイムで可視化します。最適化が必要なページをより正確に特定できます。環境やバージョンなどでフィルタリングして、既に導入済みの Web アプリケーションを表示できます。

リソース分析¶

Web アプリケーションのリソース分析では、リソース分類、XHR & Fetch 分析、リソース所要時間分析などの指標を統計し、Web アプリケーション全体のリソース状況をリアルタイムで可視化します。リソースリクエストランキングを統計することで、最適化が必要なリソースをより正確に特定できます。環境やバージョンなどでフィルタリングして、既に導入済みの Web アプリケーションを表示できます。

エラー分析¶

Web アプリケーションの JS エラー分析では、エラー率、エラー分類、エラーバージョン、ネットワークエラーステータス分布などの指標を統計し、Web アプリケーション全体のエラー状況をリアルタイムで可視化します。影響を受けたリソースエラーの統計により、リソースエラーを迅速に特定できます。環境やバージョンなどでフィルタリングして、既に導入済みの Web アプリケーションを表示できます。