为什么您的可用性监控显示一切正常，而用户却看到白屏

那是周四晚上 11:47，Slack 消息开始不断涌入。

“嘿，结账页面看起来坏了。”

“网站宕机了吗？我看到的是空白屏幕。”

“试了三个不同的浏览器，情况都一样。”

我打开了我们的运行时间监控面板。显示绿色。所有检查均通过。响应时间正常。HTTP 状态码全部为 200。根据监控跟踪的每一项指标，网站都是健康的。

但事实并非如此。

结账页面——整个应用中最重要的单一页面——对每个用户都显示完全白色的屏幕。这种情况已经持续了大约 40 分钟。而我们的监控系统毫无察觉。

那一晚让我们付出了约四小时的调查时间、凌晨两点的补丁修复，以及一份我更愿遗忘的事后分析报告。根本原因是由一个第三方 A/B 测试脚本触发的 JavaScript 运行时错误，该脚本异步加载，而在我们监控系统的简单 HTTP 检查已经返回 200 状态码并结束检查之后才执行。

监控系统正在完全按照其设计初衷工作。而这正是问题所在。

Ping 监控实际上检查的是什么

让我们准确说明大多数运行时间监控工具的工作原理，因为我认为许多开发人员对此的认知模型是模糊的。

基本的运行时间监控器会向你的统一资源定位符（URL）发出超文本传输协议（HTTP）请求。它检查：

仅此而已。有些监控器会增加字符串匹配功能——“检查响应体是否包含‘主页’一词”或其他类似内容。这稍微好一些，但提升有限。

问题是，你的用户并不关心这些。他们关心的是页面是否正常工作——他们期望的内容是否可见，他们需要点击的按钮是否存在，以及他们试图执行的操作是否真正可行。

带有空白主体的 HTTP 200 响应仍然是 HTTP 200。返回了外壳超文本标记语言（HTML）但未能挂载任何 React 组件的页面仍然是 HTTP 200。缓存的内容分发网络（CDN）响应即使已过时三周，也仍然是 HTTP 200。

以下是我见过（或亲自造成）的实际生产环境事故，而 Ping 监控器会完全遗漏这些情况。

加载时的 JavaScript 崩溃

你的服务器渲染页面并返回有效的 HTML。但在客户端打包文件中，某处存在未处理的异常——空引用、导入失败或应用程序编程接口（API）返回了意外的数据结构。页面保持空白、部分渲染或卡在加载状态。服务器是正常的。HTTP 响应也是正常的。但用户体验却糟透了。

这些问题尤其棘手，因为它们通常只影响特定的浏览器、特定的屏幕尺寸，或处于特定状态的用户（已登录与未登录、购物车中有商品与购物车为空）。

内容分发网络（CDN）提供过时内容

你部署了一个修复程序。你的源服务器正在运行新代码。但由于缓存失效未正确传播，或者有人忘记添加缓存破坏标头，或者 CDN 的清除 API 返回了 200 状态码但实际上并未执行操作，导致你的 CDN 边缘节点仍向 80% 的用户提供旧的、损坏的版本。

你的监控器访问源服务器。一切正常。用户访问 CDN 边缘节点。出现故障。

React/Next.js 水合失败

你正在对 React 应用进行服务器端渲染。服务器发送了 HTML，这在监控器的响应检查中看起来很棒。然后客户端 JavaScript 尝试对该 HTML 进行“水合”——附加事件监听器、协调状态——但出现了问题。页面看起来已渲染，但没有任何交互性。按钮无响应。表单无法提交。水合错误正存在于

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。