云基础设施监控：您的服务提供商不会告诉您的内容

您的云控制台是绿色的。警报沉默。支持队列却因为客户无法登录而不断增加。

这种组合比大多数团队承认的更常见，且通常不是配置错误。云原生监控运行于其所报告的基础设施内部——所以当该基础设施遭遇不顺时，其自身的遥测数据是最后能提供独立答案的地方。

如果您正要比较云基础设施监控工具，这种差距应比任何功能矩阵驱动您挑选名单更重要。以下内容包括：您的供应商监控能看到和看不到的内容，如何针对您实际遇到的故障测试供应商，以及大约六个月后让团队惊讶的定价条款。

本指南内容

• 为什么您的云供应商监控看不到故障
• 云原生监控实际测量的内容
• 云仪表盘上显示绿色的三种故障
• 如何评估云基础设施监控工具
• 哪些指标应纳入您的候选测试
• 云监控定价让团队中招的地方
• 每次供应商电话应问的问题
• 云基础设施监控底线
• 常见问题解答

为什么您的云供应商监控看不到故障

每个监控系统都有一个视角。您的供应商的视角在其自身网络内部。

先定义一个概念，因为它决定了之后的论点。这里的云原生监控指您从平台获得的默认资源指标和警报——Amazon CloudWatch、Azure Monitor、Google Cloud Monitoring——而非供应商附带销售的所有可用性功能。

这些默认指标有用。CloudWatch 会告诉您实例 CPU 占用达 100%，自动扩展组新增了容量，数据库连接耗尽。都是实际信号，您应继续收集它们。

但检查是运行在供应商控制平面上，通过供应商网络，调用供应商 API。如果控制平面降级，指标管道也随之受影响。延迟的指标在仪表盘上看起来和健康指标一模一样：不会触发警报，因为没有数据到达会触发警报。

第二个限制对任何面向客户的场景更为重要。那些默认指标测量您的资源，而非用户在圣保罗与您在 us-east-1 区域负载均衡器之间的路径。DNS 解析、BGP 路由、CDN 边缘行为、TLS 协商、第三方脚本、WAF 规则——这些全都在该边界之外，任何一个都能导致您的服务宕机，而 CPU 和内存却保持正常。

运行在故障域内部的监控系统，是最后一个告诉您该域故障的系统。

那 CloudWatch Synthetics 不已经做到了吗？

部分是，这个反对意见值得认真对待。每个主流供应商都有类似产品：CloudWatch Synthetics canaries、Route 53 健康检查、Azure Monitor 可用性测试、Google Cloud 正常运行时间检查。它们会针对您的端点发起真实请求，且有效。

关键是它们的执行位置。这些检查运行在同一供应商的基础设施上，结果发回同一个控制台，供应商区域之外的覆盖薄弱；且大范围的区域性事件会同时影响检查和工作负载。是有用的工具，但不是独立的。

独立性才是真正需求，这点可以反问任何供应商。许多第三方监控服务也运行在主要云上。所以问清检查位置：是在跨多供应商和运营商节点的网络，还是只是您已用云的三个位区？Dotcom-Monitor 运行自己的全球监控网络，而非租用区域，这让检查更有意义。

您也可以自己搭建类似方案。Prometheus Blackbox Exporter 探测端点，对于一两个视角这是合理方案。但当您需要数十个地理位置、真实浏览器渲染，以及有人负责探测自身时，成本显现。

无论如何，检测应从被检测系统外部运行。合成监控 在您设定的计划上通过公共互联网发送请求。若请求失败，您通过检测而非客户获知。

云原生监控实际测量的内容

这是分层划分。与任何供应商交流前，先映射您当前的覆盖范围。

两列指标互不可替代。您的供应商工具是确定根因的最佳利器，一旦您确知有问题。外部检查告诉您问题是否存在，并在供应商管道停滞时持续报告。我们在什么是基础设施监控中对资源级覆盖做了更深入介绍。

二者兼顾。预算也要预留。

云仪表盘上显示绿色的三种故障

这些是模式，不是案例研究。在 AWS、Azure 或 Google Cloud 上运行生产工作负载几年，至少有一个您会觉得熟悉。

半数用户访问失败的 DNS 记录

迁移时有人更新了记录。授权名称服务器上的变更正确，所有内部检查因此通过。旧端点在前一个 TTL 过期前已退役，全球递归解析器仍在分发旧地址，直到其缓存失效。部分流量持续访问无响应的旧服务。

您的实例健康。负载均衡器流量减少但无异常报告。捕获此问题需从外部多个地理位置解析域名，就像真实客户访问一样。这是DNS 监控的作用，也说明了解析器位置在评估中的重要性。

负载均衡器上过期的证书

续期已自动化，因此失败通常静默发生。某个任务中断，没人注意，某一监听器或 CDN 边缘属性的证书过期。

背后的实例正常。CPU正常。应用日志显示请求减少，无错误。浏览器却对每位访问者显示中断警告。提前数周从外部链路检测一条证书完整性链的SSL 证书监控会捕获此类情况。

显示正常运行的区域

供应商状态页通常会等待内部确认后才改变状态颜色。这样可以避免数百万客户收到错误警报，但意味着状态页往往滞后于事件。团队通常在仪表盘变黄前就发现错误。

若您的事件响应依赖状态页，您已把检测时间交给了他人复核流程。独立检查赋予您自己的时间线——事件期间及事后对照 SLA 复核。这是使正常运行时间和 SLA 报告在信用争议中有价值的数据来源。

如何评估云基础设施监控工具

多数供应商比较集中于功能。这告诉不了您多少——功能列表趋于一致，一半功能换了名字讲的是同一事物。反而应根据您自己的故障来测试。

步骤 1：列出您最近发生的五个故障。从工单系统提取，非凭记忆，并注明您如何得知故障。若超过一个通过客户反馈，说明您有检测问题，而非仪表盘问题。

步骤 2：检查供应商的检查执行位置。索要位置清单，而非数量，并询问谁拥有这些位置。聚集在北美和西欧的三十个位置对东南亚用户毫无意义。租用您已用云区位的情况在地域性事件时无效。

步骤 3：测试多步流程，不仅首页探测。主页 200 状态几乎无意义。脚本登录、搜索、加入购物车，使用 Scoped 测试凭证进行 API 调用。仅检查状态码的工具可能通过所有您的测试，却漏掉了让您损失金钱的故障。EveryStep 脚本支持录制的用户流程场景。

步骤 4：试用期间故意制造故障。将检测指向您控制的预发布主机名，然后拉掉 DNS 记录或返回硬 500。计时警报，并解读内容。这是试用中最有用的一小时。

步骤 5：如同警报唤醒您般解读警报。它是否指出失败步骤、位置、错误类别、响应时间？还是只说“站点宕机”？这决定了您的值班工程师是凌晨 2:04 开始修复还是调查。检查告警如何集成到您现有系统——PagerDuty、Slack、Teams、Webhook。

步骤 6：确认警报能触达您内部系统。很多运行的服务非公开：管理面板、内部 API、预发布、VPN 后网络。只看公开互联网的工具意味着您还得买第二个。私有代理在您的网络内部运行检查，结果汇报到同一控制台。

步骤 7：按明年规模预测支出。将现有检查数翻倍，按您实际需要的间隔而非演示中的间隔计算，要求对方书面报价。

哪些指标应纳入您的候选测试

可用率百分比最终进入董事会汇报，但在评估时最没用——正常运行时间数字会四舍五入掉您关心的故障。应要求以下指标：

• 检测时间。从故障发生到警报到达的分钟数。此数字是购买合理性的依据。
• 按地区划分的响应时间。使用地区 p95，而非掩盖慢区域的全球平均值。
• 按层级划分的错误明细。DNS、TCP、TLS、HTTP、内容断言。未指明层级只报告“失败”的工具，将调试留给您自己。
• 故障确认策略。发布警报前需多少位置确认，确认速度如何。策略过宽可能产生噪声，过严则延误。
• 原始检查数据保留。报告用汇总数据即可，事后复盘需个别检查。

分布式后端让这一点变复杂——依赖关系部分失败，症状移动。我们关于监控分布式系统的指南涵盖此类情况。

云监控定价让团队中招的地方

监控费用往往增长快于被监控基础设施，问题主要出在：

按主机计费的自动扩展环境。如果按监控主机计费，且实例随流量扩展，费用也随之飙升。询问如何计数短暂实例及时间窗口。

自定义指标与高基数标签。云原生监控常按每月自定义指标收费。添加高基数标签——客户 ID、容器 ID——计数迅速倍增，无人决定多花钱。

数据摄取、保留、用户数及短信。日志量难回落，须检查各阶梯界限及保留是否和摄取分开计费。有平台还按用户计费，让“给支持访问权限”变成预算问题，短信和语音告警也可能单独计量。

检查频率。按执行次数计费的供应商，从 5 分钟间隔改为 1 分钟，成本增加五倍。其他供应商将执行次数打包或根据计划限制频率，花费形态变化多，但很少免费，频率决定能否捕获短暂故障。请按您实际频率和服务计价。Dotcom-Monitor 的定价按检查数量和间隔计费，计算简便。

将总费用对比您服务的宕机成本。对大多数团队而言，监控费用相较单次严重宕机小时极小——记住这点，为续费对话做好准备。

每次供应商电话应问的问题

带着这些问题参加演示，答案会快速筛选工具：

• 您的检查位置归谁所有——自有节点、运营商设施，还是租用的 AWS、Azure 或 Google Cloud 区域？
• 检查使用真实浏览器还是 HTTP 客户端？这对检测内容有什么影响？
• 如何监控需要 OAuth 或 SSO 的端点？
• 发布告警前需要多少检查位置失败？该值可调吗？
• 保留原始检查结果多长时间？能导出吗？
• 如果我检查数翻倍、间隔减半，费用如何？

关于更广泛的选型流程——供应商稳定性、支持、合同条款——我们另有监控平台选型指南。

云基础设施监控底线

保留供应商监控。它是您进行资源级诊断的最佳工具，已部署且基本指标随计算而来。注意自定义指标、日志和保留引起的费用，但仍应保留。

只是不建议把它作为故障检测器。它从被监控系统内部报告，默认指标无法覆盖网络路径、公共 DNS 解析、边缘证书或客户依赖的登录流程。这些才是最先进入您的支持队列的故障。

有效评估简短：列出真实故障，针对故障测试候选，试用时故意制造故障，按实际运行配置定价。一款能比您上五次故障早五分钟发现的工具，已自我回本。

常见问题解答