跳到主要内容
跳到主要内容

远程演示数据集

以下指南假设您已使用 一体化镜像的说明仅本地模式 部署了 ClickStack,并完成了初始用户创建。

本入门指南使用一个可在演示服务器上访问的数据集,该数据集在用户首次部署 HyperDX 时可以使用。该数据集托管在公共 ClickHouse 实例上,网址为 sql.clickhouse.com

它包含从 ClickHouse 版本的官方 OpenTelemetry(OTel)演示中捕获的大约 40 小时的数据。数据每晚重放,时间戳调整为当前时间窗口,允许用户利用 HyperDX 的集成日志、跟踪和指标来探索系统行为。

数据变体

由于数据集从每天午夜重放,因此确切的可视化效果可能会因您探索演示的时间而异。

演示场景

在本次演示中,我们调查一个涉及销售望远镜及相关配件的电子商务网站的事件。

客户支持团队报告称,用户在结帐时遇到支付完成问题。该问题已上报给网站可靠性工程(SRE)团队进行调查。

SRE 团队将使用 HyperDX 分析日志、跟踪和指标来诊断和解决问题,然后审查会话数据,以确认他们的结论是否与实际用户行为一致。

演示架构

此演示重用官方 OpenTelemetry 演示。它由用不同编程语言编写的微服务组成,这些微服务通过 gRPC 和 HTTP 相互通信,还有一个使用 Locust 生成虚拟用户流量的负载生成器。

版权: https://opentelemetry.io/docs/demo/architecture/

有关演示的更多细节,请参阅 官方 OpenTelemetry 文档

演示步骤

我们已经使用 ClickStack SDKs 对此次演示进行了注入,在 Kubernetes 中部署了服务,并收集了指标和日志。

连接到演示服务器

仅本地模式

如果您在本地模式中部署时点击了 连接到演示服务器,可以跳过此步骤。如果使用此模式,数据源将以 Demo_ 为前缀,例如 Demo_Logs

导航到 团队设置 并点击 编辑 以修改 本地连接

将连接名称更改为 Demo,并按照以下演示服务器的连接详细信息填写后续表单:

  • 连接名称: Demo
  • 主机: https://sql-clickhouse.clickhouse.com
  • 用户名: otel_demo
  • 密码: 保持为空

修改数据源

仅本地模式

如果您在本地模式中部署时点击了 连接到演示服务器,可以跳过此步骤。如果使用此模式,数据源将以 Demo_ 为前缀,例如 Demo_Logs

向上滚动到 数据源,并修改每个数据源 日志跟踪指标会话,使其使用 otel_v2 数据库。

备注

您可能需要重新加载页面,以确保每个数据源中列出所有数据库。

调整时间范围

使用右上角的时间选择器,将时间调整为显示过去 1天 的所有数据。

您可能会在概述条形图中观察到错误数量的微小差异,多根连续条形中的红色部分有所增加。

备注

条形图的位置可能因您查询数据集的时间而有所不同。

过滤错误

为了突出错误的发生,请使用 SeverityText 过滤器并选择 错误,以仅显示错误级别的条目。

错误应该更加明显:

识别错误模式

借助 HyperDX 的聚类功能,您可以自动识别错误并将其分组为有意义的模式。这在处理大量日志和跟踪时加速了用户分析。要使用此功能,请从左侧面板的 分析模式 菜单中选择 事件模式

错误集群揭示了与支付失败相关的问题,包括一个名为 未能下订单 的模式。附加集群还表明存在信用卡收费和缓存已满的问题。

请注意,这些错误集群可能源自不同的服务。

探索错误模式

点击最明显的错误集群,它与我们报告的用户能够完成支付的问题相关:未能下订单

这将显示与 前端 服务关联的此错误的所有发生实例的列表:

选择任何一个结果错误。日志元数据将详细显示。向下滚动 概览列值,表明由于缓存问题导致的信用卡收费失败:

未能收费:无法收费信用卡:rpc 错误:代码 = Unknown 描述 = Visa 缓存已满:无法添加新项目。

探索基础设施

我们已识别出与缓存相关的错误,这可能导致支付失败。我们仍需要确定此问题在我们的微服务架构中来源于哪里。

鉴于缓存问题,调查基础设施是合乎逻辑的 - 可能我们在相关 Pods 中存在内存问题?在 ClickStack 中,日志和指标是统一的,并在上下文中显示,使快速查找根本原因变得更加容易。

选择 基础设施 标签以查看与 前端 服务的底层 Pods 相关的指标,并扩大时间范围至 1天

问题似乎与基础设施无关 - 在该时间段内没有指标显著变化:无论是在错误发生之前还是之后。关闭基础设施标签。

探索跟踪

在 ClickStack 中,跟踪也会自动与日志和指标相关联。让我们探索与我们选择的日志相关的跟踪,以识别责任服务。

选择 跟踪 以可视化相关跟踪。向下滚动,通过后续视图,我们可以看到 HyperDX 如何能够在微服务之间可视化分布式跟踪,连接每个服务中的跨度。一次支付明显涉及多个微服务,包括执行结账和货币转换的服务。

向下滚动到视图底部,我们可以看到 支付 服务导致了错误,这反过来又向上传播至调用链。

搜索跟踪

我们已经确定用户由于支付服务中的缓存问题未能完成购买。让我们更详细地探索此服务的跟踪,以查看是否可以了解更多关于根本原因的信息。

通过选择 搜索 切换到主搜索视图。为 跟踪 切换数据源,选择 结果表 视图。确保时间跨度仍然在过去一天内。

该视图显示了过去一天内的所有跟踪。我们知道问题起源于支付服务,因此将 ServiceName 过滤器应用于 支付

如果我们选择 事件模式 对跟踪应用事件聚类,我们可以立刻看到支付服务中的缓存问题。

为跟踪探索基础设施

通过单击 结果表 切换到结果视图。使用 StatusCode 过滤器和 错误 值进行错误过滤。

选择 错误:Visa 缓存已满:无法添加新项目。 错误,切换到 基础设施 标签并将时间跨度扩大至 1天

通过将跟踪与指标关联,我们可以看到内存和 CPU 随着 支付 服务的增加而上升,然后下降到 0(我们可以将其归因于 Pod 重启) - 这表明缓存问题引发了资源问题。我们可以预期这影响了支付完成时间。

事件增量以加快解决时间

事件增量通过将性能或错误率的变化归因于特定数据子集,帮助揭示异常 - 使快速定位根本原因变得更容易。

虽然我们知道 支付 服务存在缓存问题,导致资源消耗增加,但我们尚未完全确定根本原因。

返回结果表视图,选择包含错误的时间段以限制数据。确保您选择错误之前和之后的若干小时(问题可能仍在发生):

移除错误过滤器,并从左侧 分析模式 菜单中选择 事件增量

顶部面板显示了时间分布,颜色指示事件密度(跨度的数量)。主要集中之外的事件子集通常是值得调查的。

如果我们选择持续时间大于 200ms 的事件,并应用 按选择过滤 的过滤器,我们可以将分析限制在较慢的事件:

对数据子集进行分析后,我们可以看到大多数性能峰值都与 visa 交易相关。

使用图表获取更多上下文

在 ClickStack 中,我们可以从日志、跟踪或指标中图示任何数值,以获取更多的上下文。

我们已确立:

  • 我们的问题出在支付服务
  • 缓存已满
  • 这导致资源消耗增加
  • 该问题阻止了 Visa 支付的完成 - 或至少导致其完成时间很长。

从左侧菜单中选择 图表浏览器。填写以下值以按照图表类型显示支付完成所需的时间:

  • 数据源: 跟踪
  • 指标: 最大
  • SQL 列: 持续时间
  • 条件: ServiceName: payment
  • 时间段: 过去 1 天

点击 ▶️ 会显示支付性能随时间的减退情况。

如果我们将 分组依据 设置为 SpanAttributes['app.payment.card_type'](只需输入 card 进行自动完成功能),我们可以看到与万事达卡相比,Visa 交易的服务性能如何衰退:

注意,一旦出现错误,响应会以 0s 返回。

更深入探索指标的上下文

最后,让我们将缓存大小作为指标绘图,以查看它随时间的变化,从而提供更好的上下文。

填写以下值:

  • 数据源: 指标
  • 指标: 最大
  • SQL 列: visa_validation_cache.size (gauge)(只需输入 cache 进行自动完成功能)
  • 条件: ServiceName: payment
  • 分组依据: <empty>

我们可以看到缓存大小在 4-5 小时内增加(可能是在软件部署后),然后达到最大值 100,000。通过 匹配事件示例,我们可以看到我们的错误与缓存达到此限制相关,之后记录的大小为 0,响应也返回为 0s

总之,通过探索日志、跟踪和最后的指标,我们得出以下结论:

  • 我们的问题出在支付服务
  • 由于可能的部署,服务行为发生变化,导致 Visa 缓存在 4-5 小时内缓慢增加 - 达到最大值 100,000
  • 这导致缓存增长时资源消耗增加 - 很可能由于实现不佳
  • 随着缓存的增长,Visa 支付的性能下降
  • 当达到最大尺寸时,缓存拒绝支付并报告其大小为 0

使用会话

会话让我可以重播用户体验,从用户的角度提供有关错误如何发生的可视化说明。尽管通常不用于诊断根本原因,但它们在确认客户支持报告的问题时很有价值,还可以作为更深入调查的起点。

在 HyperDX 中,会话与跟踪和日志相关联,提供有关根本原因的完整视图。

例如,如果支持团队提供了遇到支付问题的用户电子邮件 [email protected],通常更有效的做法是先查看他们的会话,而不是直接搜索日志或跟踪。

从左侧菜单导航到 客户端会话 标签,确保数据源设置为 会话,时间范围设置为 过去 1天

搜索 SpanAttributes.userEmail: Braulio 找到我们的客户会话。选择该会话将显示该客户会话的浏览器事件和关联跨度在左侧,用户的浏览器体验将重新渲染在右侧:

重播会话

通过按 ▶️ 按钮来重播会话。在 高亮所有事件 之间切换,允许不同程度的跨度粒度,其中前者突出显示关键事件和错误。

如果我们向下滚动到跨度的底部,可以看到一个与 /api/checkout 相关的 500 错误。为这个特定跨度按 ▶️ 按钮将重播移动到会话的这一点,让我们确认客户体验 - 支付似乎就是无法完成,没有错误显示。

选择这个跨度我们可以确认这是由内部错误引起的。通过点击 跟踪 标签并滚动浏览连接的跨度,我们能够确认客户确实是我们缓存问题的受害者。

该演示通过处理电子商务应用中的支付失败事件,展示了 ClickStack 如何通过统一的日志、跟踪、指标和会话重播帮助揭示根本原因 - 探索我们的 其他入门指南,深入了解特定功能。