瞭解並排除WxCalling的HAR日誌故障

簡介

本文檔介紹對HAR日誌的瞭解和故障排除。

功能概述

HAR日誌（HTTP Archive Logging的縮寫）是特定會話期間瀏覽器與網站之間所有網路活動的日誌。

當您訪問網站時，瀏覽器會向伺服器傳送請求並接收響應。HAR檔案捕獲所有這些請求、響應和時間資訊。

它們對於診斷Web效能問題、排除網路錯誤以及分析API事務都至關重要。

HAR日誌有助於識別載入緩慢的資源、失敗的請求以及跟蹤使用者與Web應用程式的互動。

限制

• HAR檔案可能很大，並且難以手動分析。
• 可以記錄敏感資料；確保在共用前進行資料清理。
• 某些安全策略可以阻止完全的HAR捕獲。

注意：HAR檔案以明文形式包含請求和響應的全部內容（包括密碼、會話ID、cookie等）。 因此，您不得將會話中拍攝的HAR檔案共用給公共可用的服務。如果在輸入密碼時開啟了Network頁籤，則在HAR檔案中會以明文顯示。您希望在共用HAR檔案之前刪除這些憑據。在文本編輯器中開啟儲存的HAR檔案，找到密碼並將其替換為「」等隨機文本。 在進行此更改時，請勿修改檔案的JSON格式，因為之後未對其進行正確分析以供檢視。

HAR消毒工具

歷史記錄

2023年，Okta發生安全漏洞，其支援案例管理系統中的HAR檔案被盜。攻擊者使用這些檔案中的訪問令牌和cookie來訪問其客戶帳戶。作為回應，Okta實施了一個清理工具。

當前狀態

目前，我們實施了持續的自動化，試圖從跟蹤中去除敏感材料，但保留其餘部分不變，以保留對問題進行故障排除和分析的能力。

上傳HAR檔案時，該工具會自動執行以下操作：

1. 檢測到已上傳HAR檔案
2. 使用https://har-sanitize.cisco.com對HAR檔案進行淨化
3. 將已清理的檔案上傳到案例
4. 使用GPG加密原始HAR檔案
5. 將加密的HAR檔案上傳到案件
6. 從案例中刪除原始HAR檔案
7. 在案例中新增一條註釋，說明已完成的工作以及指向此工具的連結

附註：如果無法使用HAR檔案的消毒版本解決問題，您可以按照下一節中的說明提交例外檔案，然後獲取原始HAR檔案的副本。

如何提取HAR日誌

在瀏覽器中生成HAR檔案

請參閱：在瀏覽器中生成HAR檔案。

從文檔提取：

• Chrome:
  開啟Developer Tools(F12)> Network Tab > Preserve Log > Start Recording > Regenerate Issue > Export HAR File。
• Firefox:
  開啟Developer Tools(F12)> Network Tab > Engine Icon > Check "Persist Logs" > Start Recording > Save HAR。

分析HAR日誌之前有用的資訊

HTTP方法

HTTP方法（也稱為HTTP動詞）定義客戶端要在給定資源（如資料或網頁）上執行的操作的型別。

每種方法都有特定的目的和語義。

最常見的HTTP方法有：GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS和TRACE。

* PATCH一般是冪等的，但它取決於實施。

列說明

• 安全：指示HTTP方法是否被視為安全，這意味著它不會修改資源或伺服器狀態安全方法僅用於檢索，而不用於進行更改。它們通常用於只讀操作。
• 冪等：指定多次重複同一個HTTP請求是否與重複一次具有相同的效果。冪等方法意味著無論重複請求多少次，結果都會保持不變（在第一個成功的請求之後）
• 典型用法：說明使用HTTP方法的公共用途或方案。這將提供您在Web開發或API設計中使用每種方法的時間和原因的上下文。
• 請求正文：指示HTTP請求通常是否包含正文（傳送到伺服器的資料）。 請求正文通常用於將資料（如JSON、XML、表單資料）傳送到伺服器，例如在建立或更新資源時。 
• 響應正文：指定HTTP響應是否通常包含正文（伺服器返回的資料）。響應正文是從伺服器發回客戶端的資料，例如請求的資源、狀態消息或操作的確認。

HAR測井儀的剖析

附註：在嘗試載入組織Control HUB中的位置時，將拍攝此部分中的所有示例影象

標頭

捕獲在HTTP請求和響應期間客戶端（瀏覽器）與伺服器之間交換的後設資料。

報頭提供有關要傳送或接收的資料的上下文，例如內容型別、身份驗證資訊、快取策略等。

標頭包含在HAR日誌的以下部分中：

1. 請求標頭：這些請求作為HTTP請求的一部分從瀏覽器（客戶端）傳送到伺服器。
2. 響應報頭：伺服器會響應請求將其返回給瀏覽器。

報頭儲存為鍵 — 值對的陣列，其中：

• 主要:標頭的名稱。
• 值：與標頭關聯的值。

通用請求標頭

1.主機：指定伺服器的域名(如as example.com)和埠號。

• 示例：主機：www.example.com

2.使用者代理：標識發出請求的瀏覽器或客戶端，以及其版本和作業系統。

• 示例：User-Agent:Mozilla/5.0 \(Windows NT 10.0;Win64;x64\)

3.接受：指示客戶端可以處理的內容型別（如HTML、JSON、影象）。

• 示例：接受：text/html，application/xhtml+xml

4. Accept-Encoding:指定客戶端可以解碼的編碼型別（如gzip、deflate）。

• 示例： Accept-Encoding:gzip，deflate

5.授權：包含用於身份驗證的憑據，例如令牌或基本身份驗證憑據。

• 示例：Authorization:持有人<token>

6. Cookie:包括由客戶端傳送到伺服器的cookie。

• 示例： Cookie:sessionId=12345;userPref=darkMode

7. Content-Type:指示在請求正文中傳送的資料型別（對於POST/PUT請求）。

• 示例： Content-Type:application/json

8.仲裁人：標識將客戶端引用到當前資源的頁面的URL。

• 示例：Referer:https://www.example.com/

通用響應報頭

1.Content-Type:指定資源的MIME型別（如text/html、application/json）。

• 示例： Content-Type:application/json

2. Content-Length:指示響應正文的大小（以位元組為單位）。

• 示例： Content-Length:1234

3.快取控制：指定資源的快取策略（例如資源是否可快取以及快取時間）。

• 示例：快取控制：no-cache、no-store、must-revalidate

4.伺服器：標識伺服器軟體/版本。

• 示例：伺服器：Apache/2.4.29

5. Set-Cookie:包含伺服器希望客戶端儲存的cookie。

• 示例： Set-Cookie:sessionId=67890;路徑=/;安全

6.日期：伺服器生成響應的日期和時間。

• 示例：日期：2023年10月10日星期二12:00:00（格林威治標準時間）

7.地點：在重定向中使用，指示客戶端必須導航到的URL。

• 示例：位置：https://www.example.com/new-page

8. ETag:資源的唯一識別符號，通常用於快取和版本控制。

• 示例： ETag: 12345abcd

9.內容編碼：指示響應正文的編碼方式（如gzip、deflate）。

• 示例： Content-Encoding:gzip

十、Access-Control-Allow-Origin:指定允許哪些源訪問資源（用於CORS）。

• 示例：Access-Control-Allow-Origin:*

附註：與Webex Calling最相關的Trackingid Header，因為這是您可以在LMA工具中查詢的ID。

有效載荷

HTTP請求或響應正文中傳送或接收的資料。

它通常與POST、PUT或PATCH請求相關聯，客戶端將資料傳送到伺服器，例如表單提交、檔案上載或API的JSON資料。

負載也可以存在於HTTP響應中，HTTP響應包含伺服器返回的資料，如HTML、JSON或二進位制內容（如影象、檔案）。

有效載荷出現在HAR日誌中的位置

Payload 通常位於HAR日誌的兩個主要部分：

1. 請求負載：從HTTP請求正文中從客戶端（瀏覽器）傳送到伺服器的資料。
2. 響應負載：伺服器在HTTP響應正文中返回給客戶端的資料。

預覽

是response.content對象的一部分，以結構化和易於讀取的格式（如果可用）提供伺服器返回的資料的表示。

Preview通常用於以使用者友好的方式（如JSON、XML或其他格式）顯示來自響應主體的已分析資料或結構化資料。

本節對於調試API、檢查返回的資料或瞭解伺服器響應的結構特別有用。

響應

響應提供有關伺服器針對特定請求傳送到客戶端（瀏覽器）的HTTP響應的詳細資訊。此部分包含後設資料、標頭、內容詳細資訊以及其他關鍵資料，這些資料可幫助您瞭解伺服器在請求 — 響應週期中的行為。它提供了伺服器對HTTP請求的回覆的詳細快照。

啟動器

啟動器可深入瞭解在載入網頁期間觸發特定HTTP請求的原因。它標識網路請求的源或原因，幫助開發人員瞭解導致該請求的一系列事件。啟動器還可幫助跟蹤請求的起源，並可指向負責生成請求的確切代碼行或資源。

計時

定時提供處理HTTP請求和響應所涉及的各個階段的詳細細分。它幫助開發人員瞭解請求 — 響應週期的每個步驟從啟動連線到接收最終響應所花費的時間。計時還跟蹤瀏覽器向伺服器發出請求並接收響應時發生的事件順序和持續時間。它包括DNS解析、建立連接、傳送請求、等待伺服器響應以及下載響應資料的詳細度量。

疑難排解

檢視HAR日誌的內部工具

導航到EasyLmaSearch > Import HAR/Saz file。

一般疑難排解步驟

1.在中開啟HAR檔案。
2.識別失敗的請求（例如HTTP 4xx/5xx錯誤）。

3.檢查響應時間和慢速載入元素。

4.分析請求/響應報頭以瞭解身份驗證和CORS問題。

5.在網路請求和中查詢跟蹤ID。
6.如果可能，對照響應交叉檢查故障。

票證故障排除示例

慢速載入元素

範例：

• 控制中心載入某個位置的號碼需要很長時間

疑難排解:

• 請求問題的影片（嘗試載入位置的號碼頁面）
• 在嘗試載入位置號碼時請求HAR日誌

1. 在HAR檢視器或瀏覽器開發者工具中開啟HAR檔案。
   
2. 識別瀑布中的請求 檢視
   
3. 按一下載入時間較長的「請求」。
4. 檢視日誌的Timing頁籤：

5.檢查響應時間和慢速載入元素。

6.收集該報頭的Trackingid。

7.開啟EasyLMA並使用trackingid搜尋。

已解釋計時中斷階段

下面是有關Timingtab中可以看到的每個階段的詳細資訊：

• 正在排隊。瀏覽器在連線開始之前和以下時間對請求進行排隊：
  • 存在更高優先順序的請求。請求優先順序由資源型別及其在文檔中的位置等因素決定。有關詳細資訊，請參閱fetchpriority指南的資源優先順序部分。
  • 此來源已開啟六個TCP連線，這是限制。（僅適用於HTTP/1.0和HTTP/1.1。）
  • 瀏覽器正在簡要分配磁碟快取中的空間。
• 停了。由於排隊中描述的任何原因，連線開始後請求可能會停止。
• DNS查詢。瀏覽器正在解析請求IP地址。
• 初始連線。瀏覽器正在建立連線，包括TCP握手或重試以及協商SSL。
• 代理協商。瀏覽器正在與代理伺服器協商該請求。
• 請求已傳送。正在傳送請求。
• ServiceWorker準備。瀏覽器正在啟動服務工作人員。
• 向ServiceWorker請求。正在將請求傳送給服務工作人員。
• 正在等待(TTFB)。 瀏覽器正在等待響應的第一個位元組。TTFB表示到第一個位元組的時間。此計時包括1次往返延遲和伺服器準備響應所用的時間。
• 內容下載。瀏覽器直接從網路或從服務人員接收響應。此值是讀取響應正文所花費的總時間。大於預期值可能表示網路速度慢，或者瀏覽器正忙於執行其他工作，這會延遲讀取響應。

資源不可用

範例： 

「我已經在管理控制中心上為我的使用者啟用了SNR，但是當我登入到user.webex.com門戶時，我看不到設定SNR號的選項。
您能否檢查我的組織和使用者，瞭解我為什麼無法在使用者中心上看到它？」

疑難排解:

1.通過請求工作使用者和非工作使用者的螢幕截圖來確認使用者看到的內容。

2.在為使用者載入選項時請求HAR日誌。

後續步驟：

1. 在HAR檢視器或瀏覽器開發者工具中開啟HAR檔案。 
   
2. 確定請求：

服務請求瞭解使用者的服務(GET)

呼叫終端使用者功能訪問模板請求(GET)向使用者顯示的服務的模板：

1. 分析請求/響應報頭。
   
   「No Access（禁止訪問）」表示模板為使用者隱藏了這些選項。
2. 您需要檢視ORG的模板，然後啟用Single number reach，以便使用者能夠在使用者中心中看到該模板。

範例：

無法啟用功能

呼叫錄音示例：

嘗試為使用者啟用呼叫錄音時，您會收到一條錯誤消息：「呼叫記錄更改失敗」。

要排除故障，請執行以下操作：

1.通過請求完整的錯誤消息文本來確認錯誤。

2.請求獲取該錯誤的螢幕截圖。

3.嘗試在受影響的使用者中啟用「呼叫錄音」時，請求HAR日誌。

4.在HAR檢視器或瀏覽器「開發人員工具」中開啟HAR檔案。

5.確定失敗的請求（例如HTTP 4xx/5xx錯誤）。

6.在EasyLMA中查詢跟蹤ID。


7.除cpapi例外，您可以開啟BEMS:

8.使用收集到的資訊開啟BEMS:

• 螢幕截圖
• 完整錯誤消息
• 跟蹤ID
• cpapi異常
  
  

9.在Dubber空間中或BU團隊與Dubber團隊一起檢查錯誤：
"錯誤響應摘要：400:無效產品：在Dubber中建立啞點失敗。HTTP狀態：502"

傳真訊息

下面是描述調配流在微服務中移動的圖：

在排查Control Hub中的傳真消息調配問題時，收集HAR跟蹤以詳細瞭解問題的本質並了解調配失敗的原因非常重要。 

啟用傳真消息功能時，HAR跟蹤會捕獲並顯示從CH到CPAPI的相關請求。該捕獲請求遵循特定格式。

來自CH → CPAPI:

補丁
請求URL:https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/語音郵件
TrackingID ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

發佈資料{
"已啟用":沒錯，
"通知":{
"已啟用":沒錯，
"目的地":"lazoclaudiafi+faxmessaging@gmail.com"
},
"傳送所有呼叫":{
"已啟用":假
},
"sendBusyCall":{
"已啟用":沒錯，
"問候語":"預設"
},
"sendUnansweredCalls":{
"已啟用":沒錯，
"問候語":"預設",
"maxRings":3
},
"TransferToNumber":{
"已啟用":假
},
"EmailCopyOfMessage":{
"已啟用":沒錯，
"emailId":"lazoclaudiafi+faxmessaging@gmail.com"
},
"傳真消息":{
"已啟用":假，
"電話號碼":"+12099193323",
"擴展":空
},
"messageStorage":{
"MwiEnabled":沒錯，
"儲存型別":"內部",
"externalEmail":"lazoclaudiafi+faxmessaging@gmail.com"
}

要在EasyLMA中有效跟蹤此資訊，請參閱此處提供的詳細指南： 

類別：TrackingID
子類別：全域性
Webex跟蹤ID:ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

上報資訊

• HAR日誌檔案
• 錯誤螢幕截圖
• 重現問題的步驟
• 事件的時間戳
• LMA日誌

請在開啟BEMS升級之前回答以下問題，因為這樣有助於進一步進行故障排除：

• 您看到什麼錯誤？
• 你看到了哪些跟蹤ID?
• 您是否檢視了LMA中的跟蹤ID?
• 您在LMA中看到了什麼？
• 這是否真的需要BEMS?