可用性监控

可用性监控 回答的是站点此刻能不能被访问这件事：端口通不通、域名解析到不到、HTTPS 握手成不成、页面返回的是 200 还是 500。它一般从站外多个位置发起探测，因此与只看服务器自身指标的监控互补^[1]。

要探的四层

DNS 层看解析是否存在、TTL 是否与变更计划一致。TCP 层看端口是否可达，被安全组挡住时这里就断^[2]。TLS 层看证书链与有效期，链不完整或过期时浏览器与抓取工具都会拒绝。HTTP 层看关键路径的状态码与响应时间，首页、分类页、文章页、站点地图各设一条^[3]。

与抓取的接点

抓取失败在 Search Console 里有对应类别：服务器错误、网络错误、被 robots 挡住。Google 明确说，服务器处理问题与网络问题会让抓取无法完成，并会因 5xx 降低抓取速度^[3][4]。可用性监控的价值在于这些情况发生的第一分钟就有人知道，而不是等收录掉了一片再查。

探测设置的三条

频率要与故障代价对齐。营销活动期间要高密度的探测，静态档案站可以放宽。

判定不能只看状态码。返回 200 但是错误页，同样算不可用，检查串里要包含页面特征。

多区域发起。只在同城探测，发现不了 DNS 与路由层面的问题^[1]。

常见误用

第一种是把面板或云控制台自带的实例状态当可用性，机器活着不等于站能用。第二种是探测路径太少，首页正常但深层页面全错没人知道^[3]。第三种是不记录历史，事后无法判断故障起点。

附录

参见

• 服务器监控
• 性能监控
• 告警
• 站点监控
• 抓取错误
• 证书链与续期

参考资料

官方（境外）

1. 《Uptime 监控说明》，SentryOne/Pingdom。
2. 《Google 搜索中的 HTTP 与网络错误》，Google 搜索中心。
3. 《排查抓取问题》，Google 搜索中心。
4. 《优化抓取预算》，Google 搜索中心。

外部链接

• Search Console 设置页，Google。