了解并排除WxCalling的HAR日志故障

简介

本文档介绍对HAR日志的了解和故障排除。

功能概述

HAR日志（HTTP存档日志记录的简称）是特定会话期间浏览器与网站之间所有网络活动的日志。

当您访问网站时，浏览器会向服务器发送请求并接收响应。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 > Replicate 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设计中使用每种方法的时机和原因提供了上下文。
• Request Body：指示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.授权：包含用于身份验证的凭据，例如令牌或基本身份验证凭据。

• 示例：授权：Bearer <token>

6. Cookie:包括客户端发送到服务器的cookie。

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

7.内容类型：指示在请求正文中发送的数据类型（对于POST/PUT请求）。

• 示例：Content-Type:application/json

8.仲裁人：标识将客户端引用到当前资源的页面的URL。

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

通用响应报头

1.内容类型：指定资源的MIME类型（例如text/html、application/json）。

• 示例：Content-Type:application/json

2.内容长度：表示响应正文的大小（以字节为单位）。

• 示例：Content-Length:1234

3.缓存控制：指定资源的缓存策略（例如是否可缓存，以及缓存时间长度）。

• 示例：Cache-Control: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）。

• 示例：内容编码：gzip

10. Access-Control-Allow-Origin:指定允许哪些源访问资源（用于CORS）。

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

注意：与Webex呼叫最相关的就是跟踪报头，因为这是您可以在LMA工具中查找的ID。

有效载荷

HTTP请求或响应正文中发送或接收的数据。

它通常与POST、PUT或PATCH请求相关联，客户端向服务器发送数据，例如表单提交、文件上传或API的JSON数据。

负载也可以存在于HTTP响应中，其中包含服务器返回的数据，例如HTML、JSON或二进制内容（例如图像、文件）。

有效载荷出现在HAR日志中的位置

负载通常位于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. 点击需要很长时间才能加载的Request。
4. 查看日志的Timing选项卡：

5.检查响应时间和慢速加载元素。

6.收集该报头的Trackingid。

7.打开EasyLMA并使用轨迹标记进行搜索。

解释的计时细分阶段

下面是有关Timingtab中可以看到的每个阶段的详细信息：

• 排队。浏览器会在连接开始前及以下时间对请求进行排队：
  • 存在更高优先级的请求。请求优先级由资源类型以及资源在文档中的位置等因素确定。有关详细信息，请参阅fetchpriority指南的resource priority部分。
  • 此来源已打开六个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. 分析请求/响应报头。
   
   “禁止访问”表示模板为用户隐藏了这些选项。
2. 您需要查看ORG的模板，然后打开一号通，以便用户能够在用户中心中看到该模板。

示例：

无法启用功能

呼叫记录示例：

尝试为用户启用呼叫录制时，您会收到错误消息：“呼叫录制更改失败”。

要排除的故障：

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"
},
"sendAllCalls":{
"已启用":假
},
"sendBusyCalls":{
"已启用":正确，
“问候语”："默认"
},
"sendUnansweredCalls":{
"已启用":正确，
“问候语”："默认",
"maxRings":3
},
"TransferToNumber":{
"已启用":假
},
"邮件副本":{
"已启用":正确，
"电子邮件ID":"lazoclaudiafi+faxmessaging@gmail.com"
},
"传真消息":{
"已启用":假，
"电话号码":"+12099193323",
"扩展":null
},
"消息存储":{
"MWIEnabled":正确，
"存储类型":"内部",
"外部电子邮件":"lazoclaudiafi+faxmessaging@gmail.com"
}

要在EasyLMA中有效地跟踪此信息，请参阅此处提供的详细指南： 

类别：TrackingID
子类别：全局
Webex跟踪ID:ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

上报信息

• HAR日志文件
• 错误截图
• 重现问题的步骤
• 事件时间戳
• LMA日志

请在打开BEMS升级之前回答以下问题，因为这样有助于进一步进行故障排除：

• 您看到什么错误？
• 您看到什么跟踪ID?
• 您是否查看了LMA中的跟踪ID?
• 您在LMA中看到了什么？
• 这是否真的需要BEMS?