网站宕机怎么第一时间发现？在线监控与告警方法

网站最麻烦的故障，不一定是持续时间最长的，而是发生以后很久都没人知道。比如企业官网凌晨开始返回 502，第二天上班以后才被发现；商城首页一直能够打开，但结算接口已经连续半小时报错；还有一些网站只在部分地区或者某个运营商网络下访问异常，站长自己测试始终正常，直到用户不断反馈才意识到出了问题。所以，网站上线以后不能只考虑“出问题以后怎么修”，还要考虑到：网站什么时候开始异常，我们能不能第一时间知道？

靠人工偶尔刷新首页显然做不到这一点。更稳妥的方式，是建立持续的网站在线监控，让外部节点按照固定频率访问网站、接口或者端口。一旦连续出现连接失败、HTTP 状态异常或者响应时间明显升高，再自动进入告警流程。这样至少能够把“等用户告诉你网站挂了”，变成“监控先发现问题，再由技术人员处理”。那么该如何对网站进行有效监控呢？今天我们就来具体了解一下网站在线监控与告警方法。

一、为什么网站宕机后经常不能第一时间发现？

很多中小型网站并没有 7×24 小时值班人员。白天出现问题可能很快有人注意，但如果故障发生在凌晨、周末或者节假日，只要没有配置自动监控，异常就可能持续很长时间。

还有一个常见误区，就是把“服务器在线”和“网站正常”当成一回事。实际上，即使服务器还能够 Ping 通，网站也可能已经无法正常使用。比如：

Ping                    正常
TCP 443                 正常
网站首页                 502 Bad Gateway
登录接口                 500 Internal Server Error
订单 API                 Timeout

出现这种情况时，服务器本身没有掉线，但 Web 服务、应用程序、数据库或者 CDN 回源链路已经发生故障。如果只监控服务器是否在线，就很容易漏掉真正影响用户的问题。首页正常也不能代表整个业务正常。对于电商网站来说，商品页面能够打开，但购物车或者订单接口异常，同样会直接影响交易；对于 SaaS 来说，官网能够访问，但登录和 API 已经不可用，本质上也属于严重故障。

真正实用的网站监控不能只盯着服务器，也不能只监控一个首页地址，而应该尽量覆盖用户真正会使用的关键链路。

二、想第一时间发现网站宕机，不能只靠手动检测

平时排查网站问题时，我们经常会使用 Ping、DNS 查询、网站测速或者 HTTP 状态检测工具。这些工具很有用，但它们解决的是：网站现在有没有异常？

如用户刚刚反馈网站打不开，可以马上进行一次多节点测试，看看不同地区能不能访问、HTTP 返回什么状态、DNS 有没有问题。这种方式非常适合故障发生以后的临时排查。

持续监控解决的则是另一个问题：网站以后什么时候出问题？

工作方式大致是：

10:00    检测正常
10:05    检测正常
10:10    检测正常
10:15    检测失败
10:20    再次失败
            ↓
         确认异常
            ↓
         触发告警

即使站长没有打开任何检测页面，监控任务仍然会按照设定好的周期持续运行。所以手动检测和网站监控并不是二选一。前者更适合故障排查，后者负责长期值守。对于正式运营的网站，更合理的方式通常是平时持续监控，发现异常以后再进行针对性检测。

Chahu 的网站监控页面目前也是按照这个思路设计的：监控任务由独立调度持续运行，而手动测速则属于用户主动发起的一次性诊断。持续监控还会保留可用率、检查历史、故障记录和通知事件。

三、网站在线监控到底应该监控什么？

如果只是做最基础的网站存活检测，HTTP/HTTPS 通常是第一项需要监控的内容。它可以持续访问指定页面或者 API，检查是否能够正常连接、有没有返回预期的 HTTP 状态码，以及响应时间是否超过正常范围。但对于一个正式运营的网站，只做 HTTP 检测通常还不够。

比较常见的监控项目包括：

Chahu 网站监控当前提供 HTTP(S)、Ping、TCP、DNS 和 SSL 五种监控类型。其中 HTTP(S) 可以检查网站和公开 API 的响应状态与耗时，TCP 可以检查指定端口能否正常建立连接，DNS 则支持 A、AAAA、CNAME、MX、NS、TXT、SRV 和 PTR 等记录。

需要注意的是，网站监控最好不要只添加首页。

假设是一个电商网站，除了：

https://example.com/

还可以考虑监控：

/login
/cart
/checkout
/api/order

如果是 SaaS，则可以根据业务情况增加：

/login
/dashboard
/api
监控真正需要确认的是“业务能不能正常使用”，而不只是“首页能不能返回 200”。

四、网站监控应该怎么配置？

确定需要监控哪些内容以后，接下来才是监控频率、节点和故障判定方式。

不想自己搭建完整的监控系统，可以直接用 Chahu 网站监控 ，新建监控以后，可以继续设置检测频率、节点范围、故障阈值以及告警渠道。

1. 先确定检测频率

监控多久执行一次，并没有一个适合所有网站的固定答案。

普通企业官网如果主要用于品牌展示，5 分钟左右检查一次通常已经能够覆盖大多数日常故障；电商、SaaS、在线工具或者重要业务页面，可以根据实际影响适当提高频率。

例如：

企业官网             5～10 分钟
内容网站             5 分钟左右
电商网站             2～5 分钟
登录 / 订单 API      1～2 分钟

这不是固定标准，真正需要考虑的是：如果这个页面连续异常 5 分钟，会不会已经影响业务？

2. 不要只选择一个检测地区

单节点监控最大的问题，是它只能代表这个节点所在网络的访问情况。

例如：

北京联通          正常
上海电信          正常
浙江电信          正常
广州移动          Timeout
深圳移动          Timeout

这种情况下，网站并没有全国宕机，但广东部分移动用户可能已经无法正常访问。如果监控节点刚好位于上海电信，后台可能仍然认为网站一切正常。对使用 CDN、跨运营商线路或者有全国用户的网站来说，多节点监控往往比单节点更有参考价值。

Chahu 网站监控目前可以按照全部节点、中国节点、海外节点或者自定义地区执行检测，也可以进一步筛选中国电信、中国联通、中国移动和海外网络。

这样一旦出现异常，就更容易判断到底是：

全站故障
部分地区异常
单一运营商异常
海外访问异常

排查方向也会清楚很多。

3. 不要一次检测失败就立即报警

网站监控还有一个很现实的问题：误报。

网络偶尔出现一次丢包或者某个检测节点短暂异常，并不一定代表网站真的宕机。如果一次请求超时就发送短信、电话和群消息，时间长了以后告警很容易变成噪声。

比较合理的处理方式是设置连续失败阈值。

例如：

第一次检测失败
        ↓
等待下一轮检测
        ↓
再次检测失败
        ↓
结合其他节点结果
        ↓
确认持续异常
        ↓
创建故障并发送告警

五、网站告警应该怎么设置？

监控系统发现问题以后，下一步才是把异常通知给真正能够处理的人。实际使用时，不建议所有问题都使用同一个告警等级。网站完全无法访问和 SSL 证书即将过期，显然不是同一种紧急程度。可以按照业务影响简单划分：

真正影响业务的故障应该尽快通知值班人员，而响应时间轻微上涨或者证书临近过期，则可以放到相对低一级的通知流程里。

Chahu 当前支持邮件、Telegram、电话、短信、企业微信、钉钉、飞书、Slack、Discord 和 Webhook 等告警渠道。对于个人站长，邮件或者即时通信工具通常已经够用；有专门运维团队的网站，则可以通过 Webhook 接入自己的告警、工单或者自动化处理流程。

这里真正重要的不是通知渠道越多越好，而是严重故障发生以后，消息能够送到真正负责处理的人手里。

六、网站没有完全宕机，也可能已经需要告警

网站监控不能只盯着“在线”和“离线”两个状态，有些故障发生之前，网站往往会先出现明显的性能变化。

比如一个接口平时响应时间一直稳定在 200～300ms：

正常状态      260ms
                ↓
              680ms
                ↓
              1.4s
                ↓
              3.2s

这时候接口可能仍然返回 200，表面上看并没有宕机，但服务器负载、数据库、上游接口或者网络链路已经可能出现异常。

类似情况还包括：HTTP 5xx 开始持续出现；TCP 建连时间明显增加；DNS 查询出现异常；某个运营商连续访问失败；登录或者订单 API 响应越来越慢；SSL 证书即将过期。

比较成熟的网站监控思路不是等页面完全打不开以后才报警，而是在已经出现持续异常趋势时就开始关注。

七、收到网站宕机告警以后，第一步应该检查什么？

收到网站宕机告警以后，不建议第一反应就是登录服务器重启 Nginx 或者重启机器。“网站打不开”只是最终表现，真正的问题可能发生在很多地方：

DNS
 ↓
网络线路
 ↓
CDN
 ↓
源站
 ↓
Web 服务
 ↓
应用程序
 ↓
数据库

在不知道问题发生在哪一层之前直接重启服务，有时候不但解决不了问题，还可能把原本有价值的故障现场信息清掉。

比较实用的第一步，是先确认故障范围。

收到监控告警
      ↓
重新进行多节点检测
      ↓
判断影响范围
      ↓
多个地区同时异常？
 ├─ 是
 │   ↓
 │ 检查 CDN / 源站 / Web服务 / 数据库
 │
 └─ 否
     ↓
 是否集中在某地区或运营商？
     ↓
 检查 DNS / CDN调度 / 网络线路

如果全国多个节点同时出现 502，可以优先检查源站、Web 服务或者 CDN 回源；如果只有移动网络异常，而电信、联通和海外节点正常，那么运营商线路或者 CDN 调度就更值得优先排查。

这时候可以再结合 Chahu 的其他检测工具进行交叉判断：通过在线Ping 检查网络连通性；如果怀疑域名解析异常，则继续检查 DNS。网站监控负责发现问题，Ping、DNS、测速等工具负责继续定位问题。把这两个阶段分开以后，实际故障排查会清晰很多。

结语

服务器、网络、DNS、CDN 和应用程序都很难保证永远不出问题。即使架构做得再完善，也可能遇到上游线路波动、程序发布异常、数据库故障或者证书问题。网站监控真正能够改变的，并不是让这些故障永远不发生，而是把故障发生以后那段“没人知道”的时间尽可能缩短。

对于普通企业官网，可以先从 HTTP 可用性和基础告警开始；如果网站已经承载登录、交易、订单或者 API 请求，再逐渐加入关键页面、接口、DNS、TCP、SSL 和多地区监控。监控频率和告警阈值也不需要一次配置得特别复杂，先保证真正的重要故障能够及时发现，再根据历史结果逐步调整。

相关问答

1. 网站监控和服务器监控，能不能只留一个？

不太行。服务器监控看的是 CPU、内存、磁盘、进程这些指标，Zabbix、Prometheus 都擅长这个。但用户能不能打开网站，是另一回事。机器负载正常，Nginx 配置写错、数据库连不上、证书链有问题，用户照样访问不了。所以一个偏“内部体检”，一个偏“外部拨测”，最好都留着。

2. 需要登录才能看的页面，比如后台、会员中心，怎么监控？

别拿真实用户账号硬编码密码，风险太大。可以建一个只读测试账号，通过登录接口拿 token 或 cookie，再去请求目标页面。遇到验证码、双因素、IP 白名单，就让开发开个专用监控入口。没有入口的话，至少把登录接口和关键 API 单独盯住。

3. 登录后下单这种多步骤流程，普通监控能测吗？

普通 HTTP 监控只能测单个地址，多步骤流程得上合成监控。脚本模拟：打开登录页、提交账号、加购、进结算、调订单接口。每一步都校验状态码和关键元素。别真付款，走到支付前就行。频率不用太高，用测试商品或沙箱环境跑。

4. 有 App 或小程序，只监控网页够不够？

不够。网页正常不代表 App 用的 API 正常，也不代表推送、支付回调、静态资源 CDN 没问题。至少把 App 和小程序调用的 API 域名、关键接口、图片和 JS 资源盯住。小程序还要注意业务域名校验、证书和版本发布后的兼容问题。

5. WebSocket、直播、长连接怎么监控？

普通 HTTP 监控只能测个握手，测不了后面稳不稳定。WebSocket 要专门脚本：建连接、发心跳、等消息、算延迟。直播还得看 m3u8 和 ts 能不能拉、首帧时间多久。没有现成功能就写定时任务，异常了接进现有告警通道。