網站監視常見問題 (FAQ)

頁面視圖、載入和轉移之間的差異為何?

單頁應用程式和多頁應用程式 (或 「傳統網站」) 的運作方式與技術觀點相當不同。 這一差異對於判斷績效、從而判斷使用者體驗至關重要。 因此，我們會區分頁面視圖、頁面載入和頁面轉移。 在這些術語的幫助下，我們可以清楚地傳達如何使用網站。

• 頁面載入: 擷取起始 HTML 文件及所有後續動作，直到瀏覽器中的下一個導覽為止。 例如，需要載入新的 HTML 文件的導覽。 一般而言，網站內容會在伺服器上呈現為 HTML ，然後遞送給使用者。 多頁面應用程式 (或 「傳統網站」) 幾乎只會有頁面載入。 維基百科是實作此架構的網站範例。

• 頁面轉移: 網站可能會變更使用者透過 JavaScript查看的內容。 相對於頁面載入，這不會使用傳統瀏覽器導覽。 通常會透過 JavaScript 載入新的網站內容，然後轉換成 HTML。 然後將此 HTML 放入文件中，以強化/取代已存在的文件。 單一頁面應用程式大量使用此技術。 對於單一頁面應用程式，頁面轉移的數目通常遠大於頁面載入的數目。 實作此架構的網站範例是 Instana 的產品。

  透過 API變更頁面名稱時，會觸發頁面轉移。

• 頁面視圖: 為了判斷網站上的一般活動，無論實作何種架構，都會引進術語「頁面視圖」。 頁面視圖是頁面載入和頁面轉移的總和。

何謂信標?

JavaScript 代理程式會將小型監視有效負載傳輸至 Instana 伺服器，以對網站頁面視圖的生命週期內發生的特定事件進行建模，例如頁面載入、資源擷取及 HTTP 要求。 術語引標來自 W3C 引標規格。

何謂原點?

原點是 Web 的核心部分，特別是 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)

當所有三個部分 (即架構、主機名稱及埠) 都相等時，兩個原點是相同的。 這表示下列四個範例彼此不相等。

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

同原點及跨原點呼叫或資源共用是在提及原點時經常使用的術語。 特別是 Web 安全機制 同原點原則 及 跨原點資源共用 機制通常是已知的。 當來源原點 (HTML 文件的原點) 與目標原點 (API 伺服器的原點) 不同時，會將呼叫視為跨原點。 因此，不是相同來源。

起源的概念不應與類似的概念混淆，但 網站的概念在實作和意圖方面明顯不同。

網站度量值是什麼意思?

大部分網站度量值都是從各種 W3C 規格中收到。 具體

• 資源計時，
• 導覽計時，
• 繪製計時 及
• 網路資訊 API

其他我們使用一般 Web 術語，例如來自 Web 生命項目專案。

• 最大內容繪製 (LCP)，
• 第一個輸入延遲 (FID)，
• 累積佈置 Shift (CLS) 和
• 第一個位元組的時間 (TTFB)。

我們正盡可能遵守這一術語。 此外，我們還使用下列度量:

• onLoad 時間: 每一個頁面載入都有這個計時，並建模導覽完成之前的時間，亦即載入微調按鈕已停止。 它定義為 loadEventEnd - fetchStart (請參閱導覽計時)。 在使用者介面內，我們一律區分 onLoad 時間 與 onLoad 事件時間 ，以明確說明 Instana 使用者介面與導覽計時規格之間的術語差異。
• DOM: 在導覽計時中定義的計時變異。 此度量定義為 domContentLoadedEventStart - domLoading (請參閱導覽計時)。 它被視為比導覽計時的 處理 時間更有用的計時明細。 請參閱如下所示的圖片，以瞭解 DOM 時間。
• 子項: 在導覽計時中定義的計時變異。 此度量定義為 loadEventEnd - domContentLoadedEventStart (請參閱導覽計時)。 它被視為比導覽計時的 onLoad 時間更有用的計時明細。 另請參閱如下所示的圖片，以瞭解 子項 時間。

對於 Instana Web REST API 的使用者，我們會公開 API 端點以瞭解技術度量值 ID (metricId)。 此端點回應中所參照的度量 ID 可用來透過我們的各種 網站監視 Web REST API來查詢度量值。

為何部分網站度量值並非一律可用及/或具有奇怪值?

這裡最重要的因素是使用者互動和 Web 瀏覽器支援。 讓我們從更容易瞭解的主題開始，亦即使用者互動。

在收集度量的時間範圍內，部分度量需要使用者互動，例如「第一輸入延遲」。 如果沒有使用者互動，則沒有可用的度量值。

第二個重要因素是 Web 瀏覽器支援。 部分度量值需要尚未廣泛支援的 Web 瀏覽器特性。 這方面的良好範例是大部分現代 Web 生命體徵。 這意味著部分網站整體、部分頁面或僅單一頁面載入可能不包含度量值的任何相關資訊，例如累積佈置 Shift。 不同的 Web 瀏覽器支援也會造成一些令人混淆的狀況。 例如， First-Contentful Paint (FCP) 比 Largest-Contentful Paint (LCP) 更受支援。 這意味著一組觀察值的統計聚集會導致 LCP 小於 FCP 值。 雖然無法觀察單一頁面載入的情況，但在 Web 瀏覽器支援的差異下，可能會出現一組頁面載入的情況，如下列範例所示。

• 觀察到的第一個內容污染值: 1000 ms、 1400 ms、 1600 ms。 平均值: 1333ms。
• 觀察到的最大內容油漆值: 1000 ms、 UNSUPPORTED METRIC、 1600 ms。 平均值: 1300ms。

為何針對我的部分 HTTP 呼叫所記錄的計時如此巨大?

我們的網站監視會記錄要求開始之間的時間，例如 XMLHttpRequest#send， 以及成功事件，例如 XMLHttpRequest#onreadystatechange 搭配 readyState === 4。 這兩個事件之間的時間會有很大差異，且會受到 ...

• HTTP 重新導向
• DNS 查閱時間
• 建立 TCP/TLS 連線的時間
• 伺服器回應時間
• 要求佇列時間
• 延遲和傳輸量
• 要求和回應大小
• 頁面節流控制

雖然大多數這些專案都得到了充分理解，但最後一項往往令人驚訝。 瀏覽器可能會決定對看不見的網頁進行節流控制，甚至停止處理。 頁面節流控制很可能是大量計時的原因。 請參閱 Google關於此主旨的部落格文章 或個別 Mozilla Developer Network Page Visibility API 頁面 ，以進一步瞭解。

為何遺漏地理資訊?

Instana 的網站監視會根據 IP 位址/地理位置對映來收集地理資訊。 IP 位址資訊是使用反向 Proxy 伺服器來收集。 如果網站監視使用者介面上遺漏地理資訊，您可以檢查 Javascript 代理程式的報告 URL 是否配置為略過反向 Proxy 伺服器，並將資料直接傳送至內部監視端點 (通常是 2999)。

反向 Proxy 伺服器會在 Instana 自行管理 (內部部署) 設定的過程中自動安裝。 如需相關資訊，請參閱 向一般使用者公開監視端點。

如何收集此資訊?

Instana 的網站監視是以我們稱為 weasel的開放程式碼程式庫為基礎。 Weasel 會從 瀏覽器導覽計時 API 收集資訊，並以有效的形式進行傳輸。 您可以在 GitHub 上檢查其原始碼，以取得您可能需要的所有資訊。

支援哪些瀏覽器?

JavaScript 代理程式支援所有常用瀏覽器。 不過，部分 API 和 JavaScript 語言特性在較舊的瀏覽器中不受支援。 在那些情況下， JavaScript 代理程式可能無法收集所有想要的資料點，例如導覽、資源及繪製計時資訊可能遺漏。

在非常舊的瀏覽器中，例如 Internet Explorer 6 之前的所有項目， JavaScript 代理程式可能無法載入。 這又表示不會收集任何資料。 不過，網站不應受到此影響。

如何處理不支援導覽計時 API 的瀏覽器?

對於不支援導覽計時 API 的瀏覽器，我們提供大約計時。 這些計時不可靠，我們不鼓勵您過度依賴這些追蹤資料的大約頁面載入計時。 當 Instana 必須採用頁面載入時間的近似值時，統計資料會排除這些值。 這表示近似值不是聚集頁面載入時間的一部分，例如平均、最小及最大載入時間。

我們可以進行何種類型的 ineum 呼叫?

網站監視 API 文件中提供廣域 ineum 函數的詳細資料。

您為何被 Adblock 或類似瀏覽器延伸封鎖?

雖然大部分這些延伸都不是為了顯示廣告而建立，但大部分已發展成延伸，防止網站擁有者 追蹤其使用者。 Instana 監視 Script 已在其中許多延伸中結束，我們無法讓它們回復其決策。 如果您對使用者有一些控制，您可以要求他們在其新增封鎖程式中容許 EUM Script。

後端相關性如何使用 AJAX 呼叫?

我們有 專用文件 ，說明所有後端相關性機制。

使用哪些 HTTP 標頭?

JavaScript 代理程式會利用下列 HTTP 標頭來達到後端相關性。

• 要求標頭 (至後端):
  • X-INSTANA-T
  • X-INSTANA-S
  • X-INSTANA-L
• 回應標頭 (到前端):
  • Server-Timing

為何沒有 GoogleBot 及其他資料?

由於機器人通常會操作 JavaScript API 以傳回可預測/可重現的結果， Instana JavaScript 代理程式和伺服器會識別並封鎖各種機器人的資料收集。 這會在刮除 Web 時產生正面影響，但不幸的是，當想要監視一般使用者體驗時，會造成問題。 例如 GoogleBot的 JavaScript API ...

• Date.now() 不會傳回現行時間 (毫秒) ，而是傳回一些看似固定的時間戳記。 因此，無法信任透過差異 Date.now() 所獲得的兩個時間戳記所記錄的持續時間。
• Math.random() 和 crypto.getRandomValues() 會從預先定義值儲存區中傳回值。 這會導致用戶端產生的 ID 發生問題，例如導致錯誤的後端相關性參照。

一般使用者對哪些 HTTP 端點進行呼叫 (適用於 SaaS)?

不需要配置任何項目，即可正確將資料傳輸至 Instana 的 SaaS 平台。 Instana 使用者介面一律會呈現正確的追蹤 Snippet ，其中包含必要的 URL。 請參閱我們的 網站監視端點 清單，以瞭解我們的各種端點。

是否可以 Proxy HTTP 端點 (適用於 SaaS)?

我們嚴格建議 不要 嘗試對 HTTP 端點進行 Proxy 處理。 我們 不 支援任何 Proxy 設定，也不支援因使用 Proxy 而可能產生的任何問題。 如果您仍想要 (或必須) 執行此動作，可能會發現下列指標很有用:

• 設定適當的 Host HTTP 標頭。
• 尊重 eum.instana.io 與 eum-{region}.instana.io 伺服器之間的差異。
• 請確定我們的伺服器知道一般使用者 IP。 使用一般使用者的 IP ，將 X-FORWARDED-FOR 標頭傳送至我們的伺服器。 或者，將 X-REALER-IP HTTP 標頭 (是，故意不 X-REAL-IP) 傳送至包含一般使用者 IP 的 Instana 伺服器。
• 傳遞 Instana 伺服器包含在回應內文中的所有 HTTP 標頭。
• 不要在 Proxy 中執行任何快取。

您正在從 WebSockets收集任何資料嗎?

Instana 的 JavaScript 代理程式不會收集任何 WebSockets相關資訊。 WebSockets 本身沒有語意模型，除了在用戶端與伺服器之間流動的訊息之外，我們還可以有效地監視這些語意模型。 因為 WebSocket 訊息具有任意格式 (僅字元序列或位元組) ，所以我們無法從這些訊息推斷任何類型的要求/回應或成功/失敗狀態。

雖然理論上可以將每一個透過 WebSockets 傳輸/接收的訊息傳輸至 Instana 的伺服器，但這有數個問題:

• 非常有可能收集不應該在監視系統中登陸的機密資料。
• 從每個一般使用者收集大量資料，這會為一般使用者帶來額外負擔。
• 通常，所收集資料中的信號與雜訊比率非常低。
• 資料中缺少標準化語意模型表示我們無法為您最佳化資料的存取權。

基於這些原因， Instana 不會自動收集任何關於 WebSockets的資料。 不過，我們瞭解客戶在 WebSockets之上實作要求/回應和訂閱機制。 為了深入瞭解這些，我們建議使用我們的 自訂事件 API。 透過 自訂事件 API ，您甚至可以實現 WebSocket 型要求/回應系統的後端相關性。

為何 eum.js 是所有 XMLHttpRequest 及 Fetch 呼叫的起始者?

我們的 JavaScript 代理程式會測試 Web 瀏覽器的 XMLHttpRequest 和 fetch API ，以瞭解網站正在進行的呼叫。 此檢測會導致 JavaScript 代理程式 (eum.js) 在 Web 瀏覽器開發人員工具內顯示為起始者，如下列擷取畫面所示。 請注意，我們的 JavaScript 代理程式似乎只會進行這些呼叫。 其實是我們正在監控的網站在打這些電話。

我們的 JavaScript 代理程式只會直接與 Instana 使用者介面所顯示之 JavaScript Snippet 內所定義的伺服器進行通訊，或與適用於內部部署的伺服器進行通訊。

網際網路/網路連線不正確的使用者會發生什麼情況?

可能發生兩種情況:

1. 網站造訪者可能無法下載我們的 JavaScript 代理程式。 在這些情況下，無法收集任何資料。
2. 從您的網站造訪者到我們伺服器的資料傳輸要求可能無法運作。 在這些情況下，我們不會重新嘗試遞送，也不會儲存資料以供稍後遞送。

您的 Script 標籤為何包含 defer 屬性?

我們有時會收到 JavaScript Snippet、其結構及我們選擇的方法的相關問題。 我們仔細設計 Snippet ，以平衡我們客戶的需求。 在此區段內，我們為好奇且謹慎的客戶提供一些洞察。

啟用 JavaScript 代理程式的除錯記載

我們的 JavaScript 支援除錯記載，您可以利用這些記載來深入瞭解配置錯誤、資料傳輸、限制等。 若要啟用 JavaScript 代理程式的除錯記載，您需要在監視 Snippet 內將 URL 變更為 JavaScript 代理程式。

編輯監視 Snippet ，並取代從 eum.min.js 至 eum.debug.js的檔案參照，如下列 Snippet 所示。

<!-- 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 代理程式具有每個瀏覽器標籤資料收集限制，可保護我們的系統及一般使用者免於錯誤配置及循環監視型樣。 限制如下所示：

• 任何傳輸的引標 (除了頁面資源之外，除了後面提及的更具體規則之外，還會套用規則)
  • 每個 10s: 128
  • 每個 10min: 4096
  • 每頁最大載入數: 8096
• 頁面變更
  • 每個 10s: 32
  • 每個 10min: 128
• 自訂事件
  • 每個 10s: 32
  • 每個 10min: 128
• 透過 window.fetch 起始的 HTTP 呼叫引標
  • 每個 10s: 32
  • 每個 10min: 256
• 透過 window.XMLHttpRequest 起始的 HTTP 呼叫引標
  • 每個 10s: 32
  • 每個 10min: 256

您正在收集可唯一識別使用者的資料嗎?

依預設， Instana JS 代理程式 不 包含可唯一識別使用者的資料。 此外， Instana JS 代理程式也 不 套用 裝置/瀏覽器指紋之類的技術。

使用者特定資料可以透過 使用者 API提供給 Instana 使用。

您對傳輸至 Instana 的使用者資料執行了什麼動作?

客戶可以配置 使用者 API ，以將使用者識別資訊傳輸至 Instana。 此資訊僅用來提供產品內可見的特性。 Instana 不會以任何其他方式解譯此資料，也不會在多個客戶之間產生關聯。

在傳輸至 Instana 之後，是否可以刪除使用者資料?

支援非經常性刪除要求，例如符合 GDPR。 如果您預期經常或定期刪除要求，請改為將匿名化資料傳輸至 Instana (例如: 雜湊式使用者 ID)。

您是否匿名 IP?

是， IP 已匿名化。 依預設， IPv4 位址的最後一個八位元組及 IPv6 位址的最後 80 位元會設為零。 透過 Instana 使用者介面內網站儀表板中的配置標籤，可以配置更嚴格的匿名化規則。

如何取得一般使用者 IP 的存取權?

我們的 JavaScript 代理程式無法存取 IP 位址。 我們透過一般使用者與我們伺服器建立的網路連線來存取一般使用者的 IP 位址。 我們的伺服器會使用 匿名化 IP 位址來強化從 JavaScript 代理程式接收的資料。

您要使用 Cookie 嗎?

我們的網站監視本身不是直接使用 Cookie。 不過，為了安全起見，我們的 Content-Delivery Network (Cloudflare) 會設定名為 __cfduid 的 Cookie。 如需此 Cookie 的相關資訊，請參閱 Cloudflare 常見問題 (FAQ) 文章 。

您正在使用 localStorage / sessionStorage嗎?

依預設， Instana JavaScript 代理程式不使用 localStorage 和 sessionStorage 技術。 不過，當您開啟 階段作業追蹤時，會使用 localStorage 。 依預設，在 Instana JavaScript 代理程式中，階段作業追蹤特性是 已停用 。

您儲存網站監視資料的位置?

網站監視資料的儲存位置取決於特定的 Instana 安裝架構。 一般而言，資料儲存在其歐洲或美國區域內的 Amazon 或 Google 雲端中。 您可以根據 Instana 追蹤 Snippet 中顯示的 reportingUrl ，以及 JavaScript 代理程式的報告端點清單，來識別資料的儲存位置。

您的 CDN (Cloudflare) 是否儲存一般使用者的任何相關資料?

一般使用者正在使用 Cloudflare 提供的「內容遞送網路 (CDN)」下載 JavaScript 代理程式。 Cloudflare 會將使用者資料 (包括 IP 位址) 在其日誌內保留一小段時間。 如需相關資訊，請參閱 Cloudflare 常見問題。

我們已備妥「內容-安全-原則」，有任何需要我們執行的動作嗎?

Instana JS 代理程式從 eum.instana.io 非同步載入，且可以透過 HTTP (S) 載入。 請確定可以從此網域載入 Script。

資料會透過 映像檔載入 以及 HTTP GET 和 POST 要求 (透過 XMLHttpRequest) 傳輸至 Instana。 在追蹤 Snippet 中可以看到用於資料傳輸的原點。

下列 Content-Security-Policy 定義顯示 Instana 的 SaaS 產品所需的內容:

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

同源原則對網站監視有何影響?

同源原則 是最基本的網站安全概念之一。 每一個網站都會受到它的約束，因為所有 Web 瀏覽器都會施行它。 身為網站監視提供者，我們無法控制您網站或瀏覽器的安全。 因此，我們只能在強制的安全限制下工作。 不幸的是，這限制了我們的監控能力。

• 瀏覽器將存取錯誤訊息和堆疊追蹤限制為相同原點的 Script。
• 瀏覽器會限制跨原點要求所容許的 HTTP 標頭。 這表示後端相關性並非一律可能。

若要在涉及多個原點時解除鎖定這些特性，可以使用 跨原點資源共用 (CORS) 。 CORS 是在同原點原則安全機制內用來開啟小受控制孔的機制。 下圖詳細說明需要採取哪些措施來解決相同來源的政策強加的限制。

您可以在 專用後端相關性文件中進一步瞭解我們的後端相關性機制，以及 Web 安全如何影響這些機制。

為何詳細資源擷取明細並非一律可用?

洞察網路時間、快取統計資料及資產大小的可用性，取決於 資源計時功能。 這些功能在 最現代的 Web 瀏覽器 中可供使用 (如果相同來源原則容許的話)。

若要針對從 https://example.com:443載入的 HTML 文件啟用對跨原點資源 (例如原點 https://cdn.example.com:443 ) 之資源的見解，可以使用 Timing-Allow-Origin HTTP 標頭。 下圖顯示如何設定標頭。 此外，如需相關資訊，請參閱 資源計時規格 。

如何深入瞭解 Script 錯誤?

內嵌大量協力廠商 Script 的網站通常會遇到穩定數目的 Script Error。 Script Errors 指出 (取消) 在協力廠商 Script 中捕捉到 JavaScript 錯誤。 為了安全起見， Web 瀏覽器會將實際錯誤訊息取代為 Script Error ，並清除堆疊追蹤，以限制存取協力廠商 Script 的 JavaScript 錯誤。

在 Web 上，您可以使用下列方式來深入瞭解 Script Error:

• 您可以指示 Web 瀏覽器公開錯誤訊息和堆疊追蹤，方法是指出協力廠商 Script 不包含機密資料。
• 您可以在 Web 安全模型中使用 漏洞 (不建議且不保證運作)。

建議您使用第一個選項，因為這是達到 Script Error 見解的適當設計方式。 若要實作第一個選項，請執行下列動作:

• 將 crossorigin="anonymous" 屬性新增至 Script 標籤。
• 請確定包含 Script 來源的 HTTP 回應正在傳送 Access-Control-Allow-Origin 回應標頭。

使用 JavaScript 代理程式時為何會收到相同網站 Cookie 警告?

分析相同網站 Cookie 警告時，必須區分兩個案例。

1. 使用者已登入 Instana 的產品 (SAAS 或自行管理) ，其已設定與其登入及我們的產品使用相關的 Cookie。
2. 您的網站訪客與 Instana 無關，且通常不知道 Instana。

對於先前的群組，亦即 Instana 使用者，我們和我們的夥伴正在設定 Cookie。 作為網站監視的一部分， Web 瀏覽器會將這些 Cookie 傳輸至 Instana 伺服器。 我們的伺服器從未預期這些 Cookie 會存在，以進行網站監視。 因此，如果 Web 瀏覽器開始封鎖這些瀏覽器，就完全沒有問題。 用於網站監視的唯一 Cookie 是 Cloudflare 的 Cookie -我們的 CDN 提供者。

對於後一個群組 (即您網站的訪客) ，我們目前不知道任何 SameSite Cookie 問題。 我們的 CDN 提供者 會使用有效的 SameSite=Lax Cookie 配置來設定 Cookie。

建議您利用 incognito/InPrivate 瀏覽器視窗來檢查潛在 SameSite Cookie 問題。 透過這個隱式/InPrivate 瀏覽器視窗，您可以像訪客一樣體驗您的網站。

何謂 JavaScript 堆疊追蹤轉換?

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。

JavaScript 堆疊追蹤轉換如何運作?

轉換可利用 來源對映來運作。 來源對映可讓我們將不可執行的堆疊追蹤轉換成可執行的堆疊追蹤。 更具體而言，它們可讓我們將檔案、名稱、行和直欄的參照轉換成其實際的原始碼對應項目。

為了達到此目的， Instana 會執行下列步驟:

1. JavaScript 代理程式會向 Instana 的伺服器報告 JavaScript 錯誤。 例如，假設堆疊追蹤包含 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.map 透過使用 HTTP 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 伺服器可以建立 TCP/TLS 連線?

Instana 伺服器會從 AWS / Google Cloud 伺服器發出要求。 因此，通常可以從網際網路存取 JavaScript 和來源對映檔，這一點很重要。 此外，您還需要確保伺服器具有 完整憑證鏈的工作中 TLS 配置。 您可以使用免費 SSL Labs/Qualys 的 SSL 測試 ，或在指令行上執行下列指令，來檢查是否有任何 TLS 問題。

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

如何將來源對映檔上傳至 Instana?

如需如何將來源對映檔上傳至 Instana 的相關資訊，請參閱 將來源對映檔上傳至 Instana。