Webサイト・モニタリングのFAQ

シングルページアプリケーションでは、ブラウザ上のコンテンツの変更は、ほぼ例外なく、 JavaScript を使用して単一の HTML ドキュメントを修正することで行われます。 ブラウザは1つのページのみを読み込み、通常はそのページから移動することはありません。 多くの場合、シングルページアプリケーションは、 Angular や React といった JavaScript フレームワークを使用して作成されます。 このアーキテクチャを採用しているウェブサイトの例として、 Instana が挙げられます。

マルチページアプリケーションでは、アプリケーションの各セクションが独立したページとなっており、ブラウザはそれらを個別に読み込む必要があります。 ページには動的な JavaScript 要素が含まれている場合がありますが、アプリケーションの異なる部分間の遷移を処理する役割は担っていません。 複数ページのアプリケーション Web サイトの例として、Wikipedia があります。

お使いのアプリケーションの種類によって、 Instana によるそのアプリケーションの監視方法が異なります。

単一ページ・アプリケーションと複数ページ・アプリケーションは、技術的な観点からは異なる働きをします。 この違いは、パフォーマンス、ひいてはユーザー・エクスペリエンスを評価する上で極めて重要です。 これらの用語は、Web サイトの使用方法を伝えるのに役立ちます。

• ページ・ロード: ブラウザーでの次のナビゲーションまでの初期 HTML 文書および後続のすべてのアクションの取得。 例えば、新規の HTML 文書をロードする必要があるナビゲーションです。 通常、ウェブサイトのコンテンツはサーバー上でHTMLとして生成され、その後ユーザーに配信されます。 マルチページアプリケーションには、ページの読み込みしかありません。

• ページ遷移: Web サイトは、ユーザーが JavaScriptを使用して表示しているコンテンツを変更する場合があります。 ページ・ロードとは対照的に、ページ遷移は従来のブラウザー・ナビゲーションを使用しません。 通常、新しいウェブサイトのコンテンツは JavaScript で読み込まれ、その後HTMLに変換されます。 その後、この HTML が文書に配置され、既存の文書が拡張または置換されます。 単一ページ・アプリケーションは、この技法を使用します。 単一ページ・アプリケーションの場合、ページ遷移の数はページ・ロードの数よりも大きくなります。

  API を使用してページ名を変更すると、ページ遷移がトリガーされます。

• ページ・ビュー: 実装されているアーキテクチャーに関係なく、Web サイトでの一般的なアクティビティーを判断するために、ページ・ビューという用語が導入されました。 ページ・ビューは、ページ・ロードとページ遷移の合計です。

JavaScript エージェントは、Webサイト上のページビューのライフサイクル内で発生するモデル固有のイベント（ページの読み込み、リソースの取得、 HTTP リクエストなど）をモデル化した軽量な監視ペイロードを、 Instana サーバーに送信します。 「ビーコン」という用語は、 W3C のビーコン仕様に由来しています。

オリジンは、Web セキュリティー・メカニズムの中心部分です。 オリジンに関する詳細については、 クロスオリジンリソース共有 （ CORS ）を参照してください。 スキーム（プロトコルとも呼ばれる）、ホスト名、およびポートの組み合わせが、オリジンを構成します。 以下の例をご覧ください： URL ：

https://shop.example.com/articles/hoverboard/ratings
 

先の URL の原点は https://shop.example.comです。

- Scheme: `https`
- Hostname: `shop.example.com`
- Port: 443 (based on the default for the HTTPS protocol)
 

3 つの部分 (スキーム、ホスト名、およびポート) がすべて等しい場合、2 つの起点は同じです。 以下の例では、すべてが互いに等しくありません。

• https://shop.example.com
• http://shop.example.com
• https://example.com
• http://example.com

同一発信元およびクロス発信元の呼び出しまたはリソース共有は、発信元に言及する際に頻繁に使用される用語です。 Webセキュリティの仕組みである「 同一オリジンポリシー 」や「 クロスオリジンリソース共有 （CORS）」は、広く知られている。 ソースオリジン（HTMLドキュメントのオリジン）とターゲットオリジン（APIサーバーのオリジン）が異なる場合、その呼び出しは「クロスオリジン」と見なされ、「同一オリジン」とはみなされません。

「起源」という概念は、類似しているものの、その具体化や意図において著しく異なる 「場所」 という概念と混同してはならない。

ほとんどの Web サイト・メトリックは、各種の W3C 仕様から引き継がれています。 具体的には以下のとおりです。

• リソース・タイミング
• ナビゲーションのタイミング
• 描画のタイミング
• ネットワーク情報 API

Instana Web Vitalsプロジェクトで用いられている一般的なWeb用語を使用しています。

• 最大コンテンツ・ペイント (LCP)
• 最初の入力遅延 (FID)
• 累積レイアウト・シフト (CLS)
• 最初のバイトまでの時間 (TTFB)

Instana この用語法に可能な限り従う。 Instana 以下の指標を使用しています：

• onLoad Time: このタイミングは、ページのロードごとに存在し、ナビゲーションが完了するまでの時間をモデル化します (つまり、ロード中のスピナーは停止します)。 loadEventEnd - fetchStart として定義されます (ナビゲーション・タイミングを参照)。 ユーザーインターフェース内では、「 onLoad Time」と「 onLoad Event Time」を区別することで、「 Instana 」のユーザーインターフェースとナビゲーションタイミング仕様との間の用語の違いを明確にしています。
• DOM: ナビゲーションのタイミングで定義されたタイミングのバリエーション。 このメトリックは、domContentLoadedEventStart - domLoading として定義されます (ナビゲーション・タイミングを参照)。 これは、ナビゲーション・タイミングの処理時間よりも有用なタイミング明細と見なされます。 DOM 時間を理解するには、以下の図を参照してください。
• 子: ナビゲーションのタイミングで定義されたタイミングのバリエーション。 このメトリックは、loadEventEnd - domContentLoadedEventStart として定義されます (ナビゲーション・タイミングを参照)。 これは、ナビゲーション・タイミングの onLoad 回数よりも便利なタイミング明細と見なされます。 子の時間を理解するには、以下の図を参照してください。

Instana のWebサイト（ REST API ）をご利用のお客様は、技術メトリックID（metricId）を確認するために、 API エンドポイントが表示されます。このエンドポイントのレスポンスで参照されるメトリックIDを使用すると、 Instana のWebサイト監視用REST API を利用して、さまざまなメトリックを照会することができます。

最も重要な要因は、ユーザーとの対話と Web ブラウザーのサポートです。

メトリックが収集される時間フレーム内の一部のメトリック (First-Input Delay など) には、ユーザー対話が必要です。 ユーザー対話がなければ、メトリック値を使用できません。

2 番目に重要な要因は、Web ブラウザー・サポートです。 一部のメトリックには、まだ広くサポートされていない Web ブラウザー機能 (最新の Web バイタルなど) が必要です。 サポートされない Web ブラウザー機能は、一部の Web サイト全体、一部のページ、または単一ページのロードに、メトリックに関する情報 (例えば、累積レイアウト・シフトに関する情報) が含まれていない可能性があることを意味します。 Web ブラウザー・サポートが異なっていることで、混乱する状況が生じることもあります。 例えば、ファースト・コンテンツ・フル・ペイント (FCP) は、最大コンテンツ・フル・ペイント (LCP) よりも広くサポートされています。 その結果、一連の観測値に対する統計的集計を行うと、LCP値はFCP値よりも小さくなる。 単一ページ・ロードの監視は困難ですが、以下の例に示すように、Web ブラウザー・サポートの違いを考慮すると、一連のページ・ロードに対して統計集約が行われる可能性があります。

• 観測された最初の満足度のペイント値: 1000 ms、 1400 ms、 1600 ms。 平均: 1333ms。
• 観測された最大-満足度のペイント値: 1000 ms、 UNSUPPORTED METRIC、 1600 ms。 平均: 1300ms。

Instana Webサイト監視では、リクエストの開始（XMLHttpRequest#send）と成功イベント（XMLHttpRequest#onreadystatechange）の間の時間を、 readyState === 4で記録します。 以下の要因は、前の 2 つのイベント間の時間に影響します。

• HTTP リダイレクト
• DNS ルックアップ時間
• TCP または TLS への接続を確立する
• サーバー応答時間
• 要求キューイング時間
• 待ち時間およびスループット
• 要求サイズおよび応答サイズ
• ページ・スロットル

ページ・スロットルの場合、ブラウザーは、表示されていない Web ページの処理をスロットルするか停止するかを決定することがあります。 ページスロットリングが、タイミングが長くなっている主な原因である可能性が高い。 詳細については、 この件に関する Google のブログ記事、または Mozilla Developer Network の「ページの可視性（Page Visibility）」ページ（ API ）をご覧ください。

Instana のウェブサイト監視サービスは、IPアドレスまたは地理位置情報マッピングに基づいて地理情報を収集します。 IP アドレス情報は、リバース・プロキシー・サーバーを使用して収集されます。 Webサイト監視のユーザーインターフェースに地理情報が表示されない場合は、 JavaScript エージェントのレポート用 URL が、リバースプロキシサーバーを経由せずに、内部の監視エンドポイント（通常は 2999）へ直接データを送信するように設定されているか確認してください。

リバース・プロキシー・サーバーは、Instana Self-hosted (オンプレミス) セットアップの一部として自動的にインストールされます。 詳細については、 「エンドユーザーへの監視エンドポイントの公開」 を参照してください。

Instana のウェブサイト監視機能は、weasel というオープンソースライブラリを基盤としています。 Weaselは、 Browser Navigation Timing（ API ）から情報を収集し、効率的な形式で送信します。 weasel に関する詳細については、 GitHub のソースコードをご覧ください。

JavaScript エージェントは、一般的に使用されているすべてのブラウザーをサポートしています。 ただし、一部の API および JavaScript 言語機能は古いブラウザーではサポートされていません。 このような場合、 JavaScript エージェントは、ナビゲーション、リソース、ペイントのタイミング情報など、必要なすべてのデータ・ポイントを収集できない可能性があります。

古いブラウザー (Internet Explorer 6 より前のすべてのブラウザー) では、 JavaScript エージェントがロードに失敗する可能性があります。 その結果、データは収集されません。

navigation timing API をサポートしていないブラウザの場合、 Instana がおおよその時間を表示します。 これらのタイミングは信頼性がないため、これらのトレースをあまり信頼しません。 Instana がページの読み込み時間を概算値で算出せざるを得ない場合、その値は統計から除外されます。つまり、概算値は平均、最小値、最大値といった集計されたページの読み込み時間には含まれません。

global ineum 関数に関する詳細については、 Webサイト監視のドキュメント（ API ）をご覧ください。

アドブロッキング拡張機能のほとんどは広告を表示しないように作成されていますが、そのほとんどは、Web サイト所有者がユーザーを追跡できないようにする拡張機能に進化しています。 Instana の監視スクリプトは、多くの広告ブロック拡張機能に含まれています。 ユーザーを制御できる場合は、そのユーザーのアドブロッキング拡張で EUM スクリプトを許可するようにユーザーに要求することができます。

バックエンドの相関メカニズムに関する詳細については、 「バックエンドの相関」 を参照してください。

JavaScript エージェントは、 HTTP へのリクエストを送信するWebブラウザ上で動作します。 JavaScript エージェントは、 HTTP の一般的なエラーを収集します。これには、 HTTP のレスポンスコード 4XX を伴うクライアントエラー や、 HTTP のレスポンスコード 5XX を伴うサーバーエラーが含まれ、これらは HTTP のレスポンスコードで識別されます。 また、Webブラウザが HTTP のリクエストを不完全な状態で処理した場合、エージェントは以下のエラーを検出することもできます：

• タイムアウト
• 要求が異常終了しました
• XHR オブジェクトのオープン・エラー
• HTTP 以外のエラー

JavaScript エージェントは、バックエンドの相関付けを行うために、以下の HTTP ヘッダーを使用します。

• 要求ヘッダー (バックエンドへ):
  • X-INSTANA-T
  • X-INSTANA-S
  • X-INSTANA-L
• (フロントエンドへの) 応答ヘッダー:
  • Server-Timing

JavaScript のAPIを操作して予測可能または再現可能な結果を返すボットが存在するため、 Instana の JavaScript エージェントおよびサーバーは、さまざまなボットを識別し、そのデータ収集をブロックします。 データ収集をブロックすると、Web をスクレイピングする際にプラスの影響がありますが、残念ながら、ユーザー・エクスペリエンスをモニターする必要がある場合には問題が発生します。 例えば、 GoogleBot's、 JavaScript、 API ：

• Date.now() は、ミリ秒単位の現在時刻を返さず、修正したとみられるタイム・スタンプを返します。 その結果、 Date.now() によって取得された 2 つのタイム・スタンプを差異化することによって記録された期間は信頼できません。
• Math.random() および crypto.getRandomValues() は、事前定義された値のプールから値を返します。 これにより、誤ったバックエンド相関参照を引き起こすなど、クライアント・サイドで生成された ID に関する問題が発生します。

Instana の「 SaaS 」プラットフォームへのデータ送信が正常に行われるよう、特別な設定を行う必要はありません。 Instana ユーザー・インターフェースでは、必要な URL を含む正確なトラッキング・スニペットが常に表示されます。 エンドポイントの詳細については、「 Webサイト監視エンドポイント 」をご覧ください。

HTTP のエンドポイントに対してプロキシ設定を行わないでください。 Instana プロキシの設定や、プロキシの使用に起因する問題については、サポート対象外となります。 それでもプロキシを設定したい（あるいは設定する必要がある）場合は、以下のヒントが役立つかもしれません：

• 適切な Host HTTP ヘッダーを設定します。
• eum.instana.io サーバーと eum-{region}.instana.io サーバーの違いに注意してください。
• Instana サーバーがユーザーのIPアドレスを認識していることを確認してください。 ユーザーのIPアドレスを含むヘッダー X-FORWARDED-FOR を Instana のサーバーに送信する。 あるいは、ユーザーのIPアドレスを含む HTTP ヘッダー X-REALER-IP （） X-REAL-IPを、 Instana サーバーに送信してください。
• Instana サーバーが応答本文に組み込むすべての HTTP ヘッダーをパススルーします。
• プロキシーでのキャッシングは一切行わないでください。

Instana の JavaScript エージェントでは、WebSocket に関する情報を収集していません。 WebSockets クライアントとサーバーの間をやり取りされるメッセージ以外に、 Instana が効果的に監視できるような意味論的モデルが存在しない。 WebSocket のメッセージは任意の形式（単なる文字列やバイト列）であるため、 Instana はリクエスト、レスポンス、成功、または失敗の状態を推測することができません。

理論的には、 WebSockets を通じて送受信されるすべてのメッセージを Instana のサーバーに転送することは可能ですが、そのような転送にはいくつかの問題があります：

• 監視システムに決して着陸してはならない機密データが収集される可能性が高い。
• すべてのユーザーから大量のデータが収集されるため、ユーザーにとって負担となっている。
• 通常は、収集されたデータの信号対雑音比が低くなります。
• データに標準化された意味モデルがないため、 Instana はデータへのアクセスを最適化することができません。

以上の理由により、 Instana は WebSockets に関するデータを自動的に収集することはありません。 ただし、一部のお客様は、 WebSocketsで要求または応答およびサブスクリプションのメカニズムを実装しています。 詳細については、 カスタムイベント「 API 」を参照してください。 カスタムイベント「 API 」を使用することで、 WebSocket-based のリクエストまたはレスポンスシステムに対するバックエンド相関を実現できます。

Instana JavaScript エージェントは、 XMLHttpRequest WebブラウザのAPI fetch を利用して、Webサイトが行っている呼び出しを把握します。 この設定により、以下のスクリーンショットに示すように、Webブラウザの開発者ツール内で JavaScript エージェント（ eum.js ）が発信元として表示されるようになります。 Instana JavaScript のエージェントが、これらの呼び出しを行っているようです。 ただし、これらの呼び出しは、 Instana が監視しているウェブサイトによって行われます。

Instana の JavaScript エージェントは、 Instana のユーザーインターフェースに表示される、またはオンプレミス展開用に調整された JavaScript スニペット内で定義されているサーバーとのみ直接通信します。

次の 2 つの状況が生じる可能性があります。

1. Web サイト訪問者が JavaScript エージェントをダウンロードできなくなる可能性があります。 このような場合、データを収集できません。
2. Web サイト訪問者からサーバーへのデータ送信要求が機能しない可能性があります。 Instana このような場合、再配信は行われず、 Instana も後日の配信のためにデータを保存することはありません。

JavaScript のスニペットやその構成、そして Instana が採用したアプローチに関する質問がよく寄せられます。 このスニペットは、お客様のニーズのバランスを取るように慎重に設計されています。 以下のセクションでは、これらの疑問について考察します。

Instana の JavaScript は、設定ミス、データ転送、制限などに関するさらなる情報を得るために利用できるデバッグログ機能をサポートしています。 JavaScript エージェントのデバッグログを有効にするには、モニタリングスニペット内で URL を JavaScript エージェントに変更してください。

モニタリング・スニペットを編集し、次のスニペットに示すように eum.min.js から eum.debug.js へのファイル参照を置換します。

<!-- before -->
<script defer crossorigin="anonymous" src="https://{{hostname}}/eum.min.js"></script>

<!-- after -->
<script defer crossorigin="anonymous" src="https://{{hostname}}/eum.debug.js"></script>
 

JavaScript エージェントには、設定ミスや循環監視パターンから Instana システムおよびユーザーを保護するため、ブラウザのタブごとにデータ収集の上限が設定されています。 制限は次のとおりです。

• すべての伝送ビーコン (ページ・リソースを除き、後述する具体的なルールに加えてルールが適用されます)
  • 10 秒ごとの最大: 128
  • 10 分当たりの最大数: 4096
  • 1ページあたりの最大読み込み数：8096
• ページの変更
  • 10 秒ごとの最大: 32
  • 10 分当たりの最大数: 128
• カスタム・イベント
  • 10 秒ごとの最大: 32
  • 10 分当たりの最大数: 128
• HTTP を使用して起動されるビーコンを呼び出す window.fetch
  • 10 秒ごとの最大: 32
  • 10 分当たりの最大数: 256
• HTTP を使用して起動されるビーコンを呼び出す window.XMLHttpRequest
  • 10 秒ごとの最大: 32
  • 10 分当たりの最大数: 256

デフォルトでは、 Instana JavaScript のエージェントには、ユーザーを個別に特定できるデータは含まれていません。 また、 Instana （ JavaScript ）のエージェントも、デバイスやブラウザのフィンガープリンティングなどの手法は使用していません。

ユーザー固有のデータは、ユーザー API を使用することで、 Instana に提供できます。

ユーザー 「 API 」は、顧客が設定することで、ユーザーを特定する情報を「 Instana 」に送信するようにできます。 この情報は、製品内に表示される機能を提供するためにのみ使用されます。 Instana では、このデータを他の方法で解釈することはなく、複数のお客様間で相互に関連付けることもありません。

Instana GDPRへの準拠など、まれな削除要請にも対応しています。 頻繁または定期的に削除依頼が寄せられることが予想される場合は、代わりに匿名化されたデータ（ハッシュ化されたユーザーIDなど）を Instana 宛てに送信してください。

IP は匿名化されます。 デフォルトでは、 IPv4 アドレスの最後のオクテットと IPv6 アドレスの最後の 80 ビットはゼロに設定されます。 Instana のユーザーインターフェース内のウェブサイトダッシュボードにある「設定」タブを使用することで、より厳格な匿名化ルールを設定できます。

JavaScript エージェントは IP アドレスにアクセスできません。 ユーザー IP アドレスは、サーバーに対して確立されたネットワーク接続を介してアクセスされます。 JavaScript エージェントから受信したデータは、 匿名化された IP アドレスを使用してサーバーによってエンリッチされます。

Web サイトのモニタリング自体は、Cookie を直接使用しません。

デフォルトでは、 Instana JavaScript エージェントは および sessionStorage テクノロジー localStorage を使用しません。 ただし、 セッション・トラッキングをオンにすると、 localStorage が使用されます。 デフォルトでは、 Instana JavaScript エージェントではセッション追跡機能は利用できません。

Web サイト・モニタリング・データの保管場所は、それぞれの Instana インストール済み環境によって異なります。 通常、データはAmazonまたは Google のクラウドに保存され、その保存先は欧州または米国のリージョンとなります。 データの保存場所は、 Instana のトラッキングスニペットに表示される reportingUrl および JavaScript エージェントのレポート用エンドポイント一覧に基づいて確認できます。

ユーザーは JavaScript エージェントを、アカマイが提供するコンテンツ・デリバリー・ネットワーク (CDN) を使用してダウンロードします。 アカマイはサービス運営個人データを収集および保管します。 詳細については、 Akamai のFAQをご覧ください。

Instana のJSエージェントは、 eum.instana.io から非同期で読み込まれ、 HTTP (S) を使用して読み込むことができます。 このドメインからのスクリプトのロードが可能であることを確認してください。

データは、 画像の読み込み、 HTTP へのGETリクエスト、および POST へのリクエスト（） XMLHttpRequestを通じて Instana に送信されます。 データ伝送に使用される起点は、トラッキング・スニペットに表示されます。

次のコンテンツ・セキュリティー・ポリシー定義は、Instana の SaaS 製品に何が必要かを示しています。

script-src *.instana.io;
img-src *.instana.io;
connect-src *.instana.io;
 

セルフホスト版の場合、 Instana のJSエージェントは、ドメイン eum.instana.io から読み込まれるのではなく、セルフホストのバックエンドから読み込まれます。 エージェントスクリプトを読み込むには、前述 Content-Security-Policy の定義値（例：）を、セルフホスト型バックエンドで使用されている *.instana.io 具体的なネットワークドメインに置き換える必要があります。

「 同一オリジンポリシー 」は、Webサイトのセキュリティにおいて最も基本的な概念の一つです。 すべての Web ブラウザーで適用されるため、すべての Web サイトがポリシーの対象となります。 ウェブサイト監視サービスプロバイダーである Instana は、お客様のウェブサイトやブラウザのセキュリティを管理することはできません。 Instana 課されたセキュリティ上の制約の範囲内でのみ動作する。 残念ながら、これにより Instana の監視機能が制限されてしまいます。

• ブラウザーは、同一オリジンのスクリプトへのエラー・メッセージおよびスタック・トレースへのアクセスを制限します。
• ブラウザーは、クロス・オリジン要求で許可される HTTP ヘッダーを制限します。 したがって、バックエンド相関は常に可能であるとは限りません。

複数のオリジンが関与する場合、これらの機能を利用するには、 クロスオリジンリソース共有（ CORS ） を使用できます。 CORS これは、同一生成元ポリシーのセキュリティメカニズムに対して、制御された例外を設定する仕組みです。 以下の図は、同一生成元ポリシーによる制限に対処するために何を行う必要があるかを詳細に説明しています。

Instana のバックエンド相関メカニズムの詳細、およびWebセキュリティがこれらの相関メカニズムに与える影響については、 「バックエンド相関」 を参照してください。

ネットワーク時間、キャッシング統計、およびアセット・サイズに対する洞察の可用性は、 リソース・タイミング機能に依存します。 これらの機能は、同一オリジン・ポリシーによって許可されている場合、 最新の Web ブラウザー で使用できます。

クロスオリジンリソース（たとえば、から読み込まれるHTML https://example.com:443ドキュメントのオリジン https://cdn.example.com:443 など）に関する情報を取得するには、 HTTPTiming-Allow-Origin ヘッダーを使用できます。 以下の図は、ヘッダーの設定方法を示しています。 また、詳しくは、 リソースのタイミングの指定を参照してください。

多くのサード・パーティー・スクリプトを埋め込む Web サイトでは、通常、安定した数のスクリプト・エラーが発生します。 Script Error は、サード・パーティー・スクリプトの JavaScript エラーを示します。 セキュリティー上の理由から、Web ブラウザーは、実際のエラー・メッセージを Script Error に置き換え、スタック・トレースをクリアすることによって、サード・パーティー・スクリプトの JavaScript エラーへのアクセスを制限します。

Web では、以下の方法を使用して Script Errorに関する洞察を得ることができます。

• サード・パーティー・スクリプトに機密データが含まれないことを示すことで、Web ブラウザーにエラー・メッセージやスタック・トレースを公開するよう指示できます。
• Web セキュリティー・モデルで 抜け穴 を使用できます (推奨されないため、機能することは保証されません)。

Script Error の洞察を得るための設計された適切な方法であるため、最初のオプションを使用することをお勧めします。 最初のオプションを実装するには、以下のアクションを実行します。

• crossorigin="anonymous" 属性を script タグに追加します。
• スクリプトのソースを伝達する HTTP 応答で Access-Control-Allow-Origin 応答ヘッダーが送信されていることを確認します。

同一サイト Cookie の警告を分析する場合は、以下の 2 つのケースを区別する必要があります。

• Instana の製品（SaaS版またはセルフホスト版）にサインインしているユーザーで、サインインおよび Instana 製品の利用に関連するCookieが設定されているユーザー。
• Instana との関連がなく、通常は Instana を認識していない Web サイト訪問者。

前者のグループ（つまり、 Instana のユーザー）に対しては、 Instana およびそのパートナー企業がCookieを設定しています。 Web ブラウザーは、これらの Cookie を Web サイト・モニタリングの一部として Instana サーバーに送信します。 Instana サーバーは、ウェブサイトの監視のためにこれらのクッキーが存在することを想定していません。 したがって、Web ブラウザーによる Cookie のブロックは問題ではありません。

後者のグループ（つまり、あなたのウェブサイトの訪問者）に関しては、「 SameSite 」クッキーに既知の問題はありません。 Instana's

CDNプロバイダーは、 有効な SameSite=Lax クッキー設定を含むクッキーを設定します。

匿名またはプライベートのブラウザー・ウィンドウを使用して、 SameSite Cookie の潜在的な問題がないかどうかを確認します。 この匿名または InPrivate ブラウザー・ウィンドウを使用して、訪問者のように Web サイトを体験できます。

JavaScript スタック・トレース変換は、Instana 内でより明確かつ実用的なスタック・トレースを提供します。

Before:
at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559

After:
at ProductDetails.js 26:11
 

変換されていないスタック・トレースの行では、エラーが実用的ではないという問題が起こります。 開発者は、多くの（通常は小さな）ファイルを扱います。 パフォーマンス上の理由から、これらのファイルはバンドルおよびミニファイされた形式でユーザーのブラウザに送信されるため、スタックトレースに含まれるファイル名、行番号、列番号は、人間が読み取ったり、具体的なアクションを起こしたりできる形式ではなくなっています。

変換されたスタック・トレースを使用すると、 …/main.b1510333.chunk.js:1:1559 で発生するエラーが実際には at ProductDetails.js 26:11であることが分かります。

この翻訳はソースマップを使用して行われます。 ソース・マップを使用すると、実行不能なスタック・トレースを実行可能なスタック・トレースに変換できます。 具体的には、ファイル、名前、行、および列に対する参照を実際のソース・コードの参照に変換できます。

これを実現するために、 Instana は以下の手順を実行します：

1. JavaScript エージェントが JavaScript エラーを Instana のサーバーに報告します。 例えば、スタック・トレースに行 at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559 が含まれているとします。
2. Instana のサーバーは、このファイルに対応するソースマップを特定するために、 JavaScript ファイルのダウンロードを試みます。
3. HTTP のレスポンスが解析され、 Instana がソースマップへの参照を検索します。
4. ソースマップファイルが参照されると、 Instana は HTTP へのGETリクエストを使用してソースマップファイルをダウンロードするか、 ユーザーがアップロードしたソースマップファイルの中から該当するものを検索します。
5. ダウンロードまたはルックアップが成功すると、ソース・マップ・ファイルを使用して、ファイル、名前、行、および列の参照が変換されます。

スタック・トレース行 at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559については、以下のステップを参照してください。

1. エラーが Instana のサーバーに報告されます。
2. Instana のサーバーは、http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js に対して HTTP GET 要求を発行します。
3. ソース・マップ参照 //# sourceMappingURL=main.b1510333.chunk.js.map は JavaScript ファイルにあります。
4. ソースマップファイルは、 http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.mapHTTP への GET リクエストを使用してダウンロードするか、アップロードされたソースマップファイルの中から見つけることができます。
5. ソース・マップが解析され、スタック・トレースが読みやすくなります。

Instana がスタックトレースを検知すると、自動的に HTTP リクエストを発行し、 JavaScript およびソースマップファイルを取得します。 以下の呼び出しは、行われた呼び出しの最も近い表現を示しています。

curl -H 'Accept: */*' \
  # Use a fake user-agent to bypass simple bot blockers
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36' \
  {{url of JavaScript or source map files}}
 

上記のコマンドを使用すると、 Instana がサーバーから JavaScript ファイルやソースマップファイルをダウンロードするために必要な設定を確認できます。 HTTP へのリクエストは、 AWS ( Amazon Web Services ) または Google Cloud 内で稼働しているサーバーから送信されます。 高度なボット検知機能により、 AWS または Google Cloud からのリクエストがブロックされる可能性があります。 したがって、ボット検出メカニズムを回避するために、 Instana がサーバーに送信する必要がある追加のヘッダーを設定することを検討してください。

Instana サーバーは、 AWS または Google Cloud サーバーからリクエストを送信しています。 したがって、 JavaScript およびソースマップファイルはインターネットからアクセス可能です。 また、サーバーの TLS 設定が正しく機能しており、完全な証明書チェーンが構築されていることを確認する必要があります。 SSL Labs/Qualysが提供する無料の「 SSL 」テストを利用するか、以下のコマンドを実行することで、 TLS に関する問題の有無を確認できます：

openssl s_client -showcerts -connect {{YOUR_DOMAIN_HERE}}:443
 

Instana へのソースマップファイルのアップロードについては、 「 Instana へのソースマップファイルのアップロード 」を参照してください。

ウェブサイトが常に最新の Instana EUMスクリプトを読み込むようにするには、以下の2つの方法のいずれかを行ってください：

• スクリプトを自社のCDNまたはサーバーでホストする

  最新の Instana EUMスクリプトをダウンロードし、ご自身のCDNやサーバーにホストすることで、ウェブサイトのコードを変更することなく、更新を完全に管理することができます。

1. Instana から最新のスクリプトをダウンロードしてください。
2. https://yourdomain.com/js/eum.min.jsスクリプトを自分のドメインまたはCDN（例：）にアップロードしてください。
3. HTML内でスクリプトを参照してください。

   <script defer src="https://yourdomain.com/js/eum.min.js"></script>

• Instana （ URL ）をバージョン指定なしで実行する
  バージョンを指定せずに、公式の Instana URL から「 Instana 」EUMスクリプトを直接参照できます：

  <script defer src="https://eum.instana.io/eum.min.js"></script>

  公式の Instana URL から、バージョンを指定せずに Instana の EUM スクリプトを直接参照すると、ブラウザは自動的に最新バージョンを読み込みます。

  この方法では、スクリプトの整合性を確認するために SRI を適用することはできません。