基于对 OpenTelemetry 深入理解的合成监控解决方案提高了可视性和可测试性。
译自 Synthetic Monitoring With OpenTelemetry,作者 Ken Hamric。
合成监控用于主动测试和监控生产系统,确保性能、可用性、关键功能并评估用户体验。监控类型多种多样,从简单的 ping 到全自动的 Web 交互。
现代工程团队现在使用 OpenTelemetry 和分布式追踪进行生产监控和故障排除,但主要以手动、被动的方式进行。在主动的合成监控测试中使用 OpenTelemetry 有什么优势?
大多数合成监控工具存在两个主要局限性,更好的可见性可以消除这些局限性:
让我们将这些问题归类为可见性和可测试性问题。我们如何做得更好?
现代 DevOps 和站点可靠性工程 (SRE) 团队使用可观测性,特别是 OpenTelemetry,来快速诊断和解决生产故障。特别是分布式追踪,是为了解决当今现代系统的复杂性而构建的,包括:
这些复杂性使得工程师难以完全理解系统在进程或 API 调用失败时发生的情况。然而,使用分布式追踪,工程师可以查看跨各种微服务的交易的完整详细信息。这种可见性有助于管理这些复杂的系统,提供对微服务和整个系统运行所需的洞察。
OpenTelemetry 可以通过提高可见性和可测试性来增强合成监控。
可见性相当简单。如果您在生产环境中运行合成监控器,并且它失败了,哪个工程师不想查看该失败交易的分布式追踪?
您可能会想,“没问题,我会检查我的生产可观测性解决方案并获取追踪。”不幸的是,大多数高流量生产系统依赖于采样,因此从这次特定执行中获取追踪的可能性很小。
其次,即使将采样设置为 100% 的追踪,您仍然需要将一次合成监控交易与该时间窗口内发生的数千次交易相关联。这不是一项容易、快速或可靠的任务。
要使用 OpenTelemetry 提供的可见性,您需要一个合成监控系统,该系统:
合成监控解决方案需要以 OpenTelemetry 为中心构建。
使用可观测性来提高可测试性同样重要。几乎所有基于 API 的合成测试都局限于运行黑盒测试,无法根据被测系统的任何内部细节设置断言。基于浏览器的合成测试虽然可以更深入地了解浏览器的内部结构,但对后端系统也完全一无所知。
幸运的是,OpenTelemetry 通过一种称为 基于追踪的测试 的技术提供了解决方案。这种方法允许您不仅对 API 调用的结果进行断言,还可以对追踪中公开的任何系统进行断言。您可以向任何合成测试添加各种其他验证,例如:
基于跟踪的测试通过 使用 OpenTelemetry 公开的可观测性表面 来实现。此附加的响应数据可以作为合成 API 或基于浏览器的测试的一部分进行断言。
使用对 OpenTelemetry 有深入了解构建的合成监控解决方案可以提高可见性和可测试性。利用这种力量的组织将获得许多好处:
Tracetest 是一种现代测试解决方案,它利用 OpenTelemetry 为每个测试提供跟踪和基于跟踪的测试功能。Tracetest 与您现有的测试(如 Playwright、Cypress、Postman 或 k6)以及您现有的生产可观测性解决方案(如 Tempo、Honeycomb、Datadog 或 Dynatrace)协同工作,以主动利用分布式跟踪数据在您的 CI/CD 流程中。现在能够 运行由 Playwright 测试触发的合成监控,Tracetest 充分利用 OpenTelemetry 作为合成监控的一部分。