合成监控是一种主动监控实践，它从全球多个位置运行计划的脚本检查，以模拟用户旅程和API调用。通过对网站、应用程序和API执行受控测试，它验证可用性、性能和功能正确性，提供系统健康的一致信号，而不依赖于实时用户流量。团队使用自动化测试来模拟重要请求和用户旅程，例如页面加载、登录、搜索、表单提交和结账流程，而不是等待用户报告问题。
由于这些检查按计划运行，合成监控即使在流量低或缺失时也能检测到问题。它通常用于在客户投诉之前识别停机、延迟回归、损坏的页面元素、失败的事务、区域路由问题、SSL问题和API错误。
合成监控在需要主动验证关键用户旅程、从外部位置测量可用性以及在流量低时检测回归时最为有用。它通过提供受控、可重复的检查来补充RUM、APM、日志和基础设施监控，这些检查测量用户在您的基础设施外部的体验。
合成监控如何工作？
合成监控通过定义重要检查，从选定位置运行它们，测量每个结果，并在阈值或功能条件被违反时发出警报。
1. 确定关键端点和旅程
从对用户和业务最重要的流程开始。在大多数环境中，这包括主页可用性、登录、搜索、结账、账户访问和关键公共API。
最佳的初始检查是直接与客户影响相关的检查。如果一次失败会导致支持激增、收入损失或明显的服务中断，它应该在监控列表的顶部。
2. 构建正确类型的合成测试
不同的用例需要不同的测试类型。
- 轻量级可用性检查验证基本的可达性和响应能力。
- 基于浏览器的检查验证在真实浏览器中的渲染、交互性和工作流程行为。
- API检查验证端点行为、延迟、有效负载、头部、身份验证和响应逻辑。
- 事务检查验证多步骤业务流程的端到端。
Dotcom-Monitor支持这种分层方法，提供正常运行时间监控、真实浏览器Web应用程序监控、Web事务监控和API监控。其EveryStep录制器旨在捕获真实的浏览器交互，例如点击、表单输入、导航和身份验证，然后从全球位置按计划运行这些脚本。
3. 从选定位置按计划运行测试
监控平台在配置的检查点以定义的间隔执行测试。Dotcom-Monitor表示它从30多个全球位置运行检查，这有助于团队比较各地区的性能并识别局部故障。
一个实用的起始模型如下所示：
- 轻量级正常运行时间或可用性检查：每1到5分钟
- 关键端点的公共API检查：每1到5分钟
- 高价值用户旅程的浏览器和事务检查：每5到15分钟
- 较重或低风险的工作流程：根据影响和操作价值，频率较低
Dotcom-Monitor的EveryStep配置支持从1到60分钟的检查频率，这使团队能够为关键路径调优更快的检查，并为更昂贵的浏览器流程设置较慢的节奏。
4. 测量技术和功能结果
每次测试运行可以生成数据，例如可用性状态、HTTP状态、TTFB、页面加载时间、DOM时间、步骤持续时间、API延迟、断言结果、事务成功或失败、SSL有效性和支持诊断。
一个有用的合成程序不仅仅确认请求返回了响应。它还验证响应是否正确。例如，成功的API检查可能需要预期的状态码、有效的身份验证结果、特定的响应字段、正确的头部、匹配的内容断言或成功的依赖请求序列。Dotcom-Monitor的API和浏览器监控指导强调断言、内容验证和工作流程成功，而不仅仅是正常运行时间。
5. 对有意义的失败发出警报
如果测试失败、超过阈值或违反断言，平台会发送警报，以便响应者进行调查。
一个好的规则是仅在确认对用户产生影响且持续存在的问题上发出警报。例如，配置一个高优先级警报，仅在检查连续三次失败或至少从两个不同的监控位置确认后触发。对于像区域性减速这样的降级情况，如果没有突破硬性失败阈值，则自动打开一个低优先级的工单进行调查。
值得警报的条件通常包括：
- 多次运行中的重复失败
- 从多个位置确认的失败
- 登录、结账、账户访问或关键API中的硬性失败
- 接近到期的SSL证书有效性问题
- 高优先级端点的大延迟回归
- 完整的事务失败，业务操作无法完成
工单值得的条件通常包括：
- 适度但持续的性能回归
- 非关键的区域性减速
- 一个事务步骤的速度慢于预算但仍然成功
- 不反映客户面临事件的脚本维护问题
- 需要测试更新的内容、选择器或断言的变化
4种常见合成测试类型
1. 正常运行时间和可用性监控
正常运行时间监控使用轻量级测试确认服务是否可达并按预期响应。在实践中，这通常意味着检查URL、主机或端点是否在阈值内回答并返回预期的状态或内容。
这种类型的监控对于确认基本可用性很有用，但并不能证明完整的用户工作流程是健康的。主页可以返回200 OK，而登录、结账或下游API却出现故障。为了解决这个问题，团队使用事务监控来验证整个用户旅程。虽然基本的正常运行时间检查确认可达性，但事务监控确认像结账这样的多步骤过程在功能上是正确的。
2. 浏览器监控
合成浏览器监控在受控的浏览器环境中运行脚本操作，以测试Web应用程序在真实用户交互中的行为。它用于验证渲染、点击、导航、动态内容、表单提交和端到端页面行为。例如，登录页面的真实浏览器测试：
- 断言：检查成功登录和正确的页面重定向。
- 失败：如果登录失败或页面在5秒内未加载，则创建高优先级警报。
Dotcom-Monitor强调真实浏览器监控，以确保准确的渲染和工作流程验证，特别是对于动态应用程序和事务繁重的网站。
3. 事务监控
事务监控验证多步骤业务工作流程，例如登录、搜索、账户访问、预订或结账。这很重要，因为许多可见的用户故障发生在第一次页面请求成功之后。Dotcom-Monitor的事务监控专注于用户是否能够在真实浏览器工作流程中实际完成关键操作，并包括视频捕获和瀑布分析等诊断，以显示事务中断的地方。关键断言示例：
- 断言添加到购物车的项目可见，并且结账页面加载时显示正确的价格。
- 断言支付确认成功，用户到达确认页面。
4. API监控
API合成监控验证应用程序编程接口是否可用、速度是否足够快，并返回预期的输出。强大的API监控检查的不仅仅是正常运行时间。它验证状态码、有效负载结构、头部、令牌、身份验证行为和必要时的链式请求逻辑。例如，在监控产品搜索的REST API时：
- 断言：确认返回200 OK响应，并且有效的JSON有效负载包含所有预期的产品字段（名称、价格、可用性）。
Dotcom-Monitor根据正常运行时间、性能、事务级诊断、身份验证监控和基于断言的验证来描述其API监控。
合成监控与正常运行时间监控的区别
正常运行时间监控是合成监控的一个子集。它专注于基本的可达性和响应验证，例如页面、主机或端点是否可用并在可接受的阈值内响应。
合成监控更广泛。它包括正常运行时间检查，但还涵盖浏览器测试、API断言和多步骤事务监控。换句话说，正常运行时间监控告诉您服务是否看起来正常。合成监控告诉您关键用户旅程或API工作流程是否实际正常工作。
这种区别在生产中很重要。一个网站可以是可达的，而登录失败、结账中断或API返回无效数据。这就是为什么许多团队使用正常运行时间监控进行快速检测，而使用浏览器或事务检查进行更深入的验证。
合成监控与真实用户监控的区别
合成监控和真实用户监控回答不同的问题。
合成监控询问预定义的用户旅程和端点在受控测试条件下是否正常工作。它是主动的、计划的和可重复的。即使没有实时流量，它也能正常工作。
真实用户监控测量实际访客在生产中的体验。它反映真实的浏览器、设备、网络和用户行为，但仅在用户主动生成流量时。
将两者分开的简单方法是：
- 合成监控回答：“用户现在能否完成这个关键旅程？”
- 真实用户监控回答：“真实用户在一段时间内实际体验了应用程序的情况？”
对于生产团队来说，合成监控通常是检测发布或依赖项更改后回归的第一个系统，因为它不需要等待有机流量来暴露问题。
合成监控与APM和可观察性的区别
应用性能监控和更广泛的可观察性工具帮助团队了解应用程序及其基础设施内部发生的事情。它们对于跟踪请求、分析日志、测量服务延迟和在事件期间关联后端行为非常有用。
合成监控回答了一个不同的问题。它显示用户或API消费者是否能够成功访问并从系统外部完成一个流程。
在实践中，这些工具最好结合使用：
- 合成监控从外部视角检测用户可见的故障。
- APM帮助隔离缓慢的服务、失败的依赖项或代码级瓶颈。
- 日志在调查期间提供详细的事件上下文。
- 指标和跟踪帮助解释故障发生的原因及其传播的范围。
合成监控通常是检测用户可见问题的最快方法。可观察性工具通常是解释问题的最快方法。
什么是外部监控？
外部监控意味着从外部用户、浏览器或API消费者的角度测试数字服务，而不仅仅是从应用程序堆栈内部进行测试。
这很重要，因为内部遥测可能显示基础设施是健康的，而用户仍然会遇到故障。身份验证重定向可能会中断，CDN资产可能无法加载，DNS提供商在一个区域可能出现故障，或者第三方API可能超时。这些都是用户可见的问题，仅靠内部健康检查可能会遗漏。
Dotcom-Monitor在网站、应用程序和API中使用外部监控，以从全球检查点验证真实的可用性和事务行为。
合成监控应跟踪哪些关键指标？
最有用的合成指标取决于检查的类型，但技术团队通常跟踪：
- 可用性和成功率
- HTTP状态和错误频率
- TTFB和总响应时间
- 页面加载时间和DOM时间
- 步骤级事务持续时间
- API延迟
- 断言通过或失败率
- SSL证书有效性和到期窗口
- 区域性能差异
- 事务完成率
这些指标在与特定用户旅程和业务影响相关联时最有用。一个通用的响应时间趋势不如知道在一次部署后某个区域的登录成功率下降更具可操作性。
为什么团队使用合成监控？
团队使用合成监控来捕捉停机、延迟回归和损坏的工作流程，以便在用户注意到之前发现它们。它对于关键路径（例如身份验证、搜索、结账、账户访问和公共API）尤其有价值。
在实践中，工程团队使用合成监控来：
- 在发布后验证关键用户旅程
- 在支持量上升之前检测第三方故障
- 确认客户面向的SLA和SLO是否从外部视角得到满足
- 在低流量期间捕捉生产回归
- 验证修复是否真正解决了用户可见的事件
例如，在一次部署后，团队可能会从外部检查点运行基于浏览器的检查，以确认发布没有破坏客户面向的流程。内部基础设施指标看起来可能是健康的，而外部事务仍然因为JavaScript错误、过时的CDN资产、损坏的重定向、身份验证问题或第三方依赖故障而失败。
企业团队的真实案例
SRE和平台团队
SRE和平台团队使用合成监控来验证用户可见的SLI，快速检测外部故障，并确认缓解措施或回滚是否恢复了服务。
应用工程团队
应用团队使用它来验证发布是否破坏了登录、搜索、结账或账户管理流程，并检测内部服务指标可能无法显示的前端回归。
API和后端团队
API团队使用它来验证公共端点、身份验证、有效负载完整性和依赖健康，从外部视角进行验证。
电子商务和数字体验团队
这些团队使用它来保护转化路径、验证结账流程，并在影响大规模收入之前检测第三方脚本或支付问题。
合成监控在生产中捕捉到什么？
合成监控在故障从外部可见但在堆栈内部容易被忽视时最为有用。
它特别擅长捕捉：
- 过期或配置错误的SSL证书
- DNS故障和域解析问题
- 损坏的JavaScript，导致页面或按钮无法正常工作
- 由于身份验证或重定向错误导致的登录失败
- 结账和表单提交失败
- 降级或失败的第三方脚本和API
- 区域特定的延迟或路由问题
- 内容不匹配和不正确的API响应逻辑
- 发布后页面渲染缓慢或步骤级回归
Dotcom-Monitor发布的材料通过SSL监控、多地点检查、真实浏览器执行、基于断言的API验证以及屏幕截图、视频和瀑布图等诊断强调了这些外部故障模式。
常见的合成监控挑战及如何减少警报噪音？
即使是强大的合成监控程序也需要维护和操作纪律。
脚本维护
用户界面会发生变化。选择器会失效。身份验证流程会演变。第三方内容的行为会发生变化。随着应用程序的变化，合成脚本需要更新，以便继续反映真实的工作流程。
警报噪音和波动
一个调优不良的监控策略可能会因瞬时网络条件、脆弱的脚本或过于激进的阈值而产生噪音警报。良好的重试逻辑、合理的警报策略和仔细的脚本设计可以减少误报。
覆盖缺口
合成监控仅验证您选择测试的内容。如果监控集中缺少重要的业务路径，该路径中的故障可能会被忽视。
规模和所有权
随着团队增加更多的区域、API、用户旅程和环境，监控可能变得难以管理。标准命名、所有权、升级政策和仪表板纪律在覆盖范围扩大时变得重要。
为了在实践中减少警报噪音：
- 从一小组高价值的检查开始
- 在发出警报之前要求重复失败
- 对影响用户的警报使用多地点确认
- 将工单条件与警报条件分开
- 围绕业务影响而不是理想基准调整阈值
- 在UI、身份验证或依赖项更改后审查脚本
合成监控最佳实践
从一小组高价值的检查开始
从三到五个对业务至关重要的检查开始，例如主页可用性、登录、搜索、结账和您最重要的公共API。
使用分层监控
不要依赖单一的检查类型。将轻量级正常运行时间监控与浏览器和事务检查结合使用，以验证真实功能，以及API监控以确保后端的正确性。
验证业务结果，而不仅仅是响应
服务响应并不等同于服务正常工作。尽可能使用断言和内容验证，以便测试验证预期行为，而不仅仅是返回的状态码。
从用户关心的位置进行监控
区域测试在与您的用户基础匹配时最为重要。当检查点选择反映实际影响您业务的地理位置时，全球监控最有用。
有意设置间隔和阈值
快速、高影响的检查通常需要更紧的间隔和更清晰的警报阈值。较重、低风险的事务通常在不那么激进的时间表和更多诊断上下文中效果更好。
将合成故障与内部遥测关联
当合成检查失败时，响应者应将该故障与日志、跟踪、指标、部署事件和依赖仪表板进行比较。合成监控告诉您用户在外部受到影响。内部遥测有助于解释原因。
保持脚本可维护
从少量高价值的流程开始。避免在一个脚本中测试每个UI细节。验证关键完成点，在UI和身份验证更改后审查脚本，并在发出警报之前使用多地点确认。
Dotcom-Monitor的合成监控能力
Dotcom-Monitor为网站、Web应用程序、API和多步骤用户旅程提供合成监控，使用真实浏览器测试和全球监控网络。其发布的能力包括：
- 可用性和响应验证的正常运行时间监控
- 动态应用程序的真实浏览器监控
- 登录、表单和结账流程的Web事务监控
- 带有身份验证请求和断言的API监控
- 来自30多个全球位置的监控
- 瀑布分析、屏幕截图、视频捕获和报告等诊断
- SSL证书监控和SLA报告
对于技术团队来说，价值不仅在于知道服务是否可达。还在于知道它是否可用、性能良好且功能正确。
