独立站监控体系：可用性、性能、错误与证书的告警阈值
一、可用性监控：5分钟探测一次，连续失败才算数
可用性监控是最基础的一层：站点能不能打开。很多人用单次探测就告警，结果网络抖动一次就吵醒人，一周后所有人都把告警关了。正确做法是连续探测失败才算事——连续2次失败发黄色消息到群，连续3次失败才发短信和电话。探测间隔5分钟，全球至少3个探测点（比如美东、欧洲、亚太），避免单探测点误报。
监控什么URL不要只监控首页。首页可能因为缓存还活着，但产品页或询盘表单已经挂了。至少监控三个URL：首页、一个产品详情页、询盘表单提交端点。任何一个挂了都算可用性故障。工具用UptimeRobot免费版就够，50个监控位、5分钟间隔、全球多探测点。
| 监控项 | 探测间隔 | 黄色阈值 | 红色阈值 | 通知方式 |
|---|---|---|---|---|
| 首页HTTP状态 | 5分钟 | 连续2次非200 | 连续3次非200 | 群消息→短信电话 |
| 产品详情页 | 5分钟 | 连续2次非200 | 连续3次非200 | 群消息→短信电话 |
| 询盘表单端点 | 10分钟 | 连续2次5xx | 连续3次5xx | 群消息→短信电话 |
| TCP端口22/3306 | 5分钟 | 不可达 | — | 群消息（仅工作时间） |
| SSL证书 | 24小时 | 剩余30天 | 剩余15天 | 邮件→企业微信 |
场景示例：一个出海站用UptimeRobot监控首页，配了连续3次失败才告警。某天晚上新加坡探测点连续3次失败，但美东和欧洲探测点正常——是新加坡本地网络问题，不是站点挂了。如果用单次探测告警，值班人凌晨2点被叫醒，起来一看站点好好的，下次就不信了。多探测点加连续失败，把误报率压到最低。
可用性和灾难恢复RTO/RPO是配套的：可用性告警触发，就按恢复流程走。CDN节点故障时怎么判断，见CDN全球加速。
二、性能监控：盯LCP，不盯综合分
性能监控最容易犯的错是盯综合评分。Google PageSpeed的分数波动很大，同一页面上午测85分下午测65分，这种波动发告警没意义。真正要盯的是Core Web Vitals三个核心指标，尤其是LCP（最大内容绘制）——它直接影响用户感知和SEO排名。
性能告警不要用单一阈值，要用持续时间。LCP偶尔超过2.5秒可能是某个用户网络差，持续超过10分钟才是真问题。黄色阈值LCP超过2.5秒持续10分钟，红色阈值LCP超过4秒持续15分钟。工具用BrowserStack SpeedCurve或者Chrome User Experience Report的公开数据，按月看趋势。
| 指标 | 合格线 | 黄色阈值 | 红色阈值 | 说明 |
|---|---|---|---|---|
| LCP最大内容绘制 | ≤2.5秒 | >2.5秒持续10分钟 | >4秒持续15分钟 | 最核心，直接影响SEO和转化 |
| INP交互响应 | ≤200毫秒 | >200毫秒持续10分钟 | >500毫秒持续15分钟 | 表单提交卡顿要盯 |
| CLS布局偏移 | ≤0.1 | >0.1持续10分钟 | >0.25持续15分钟 | 广告或懒加载图片引起 |
| TTFB首字节 | ≤600毫秒 | >600毫秒持续10分钟 | >1.5秒持续15分钟 | 后端慢或数据库问题 |
| 全站错误率 | <1% | >1%持续5分钟 | >5%持续10分钟 | 5xx和4xx分开统计 |
场景示例：一个站某天上午LCP从1.8秒涨到3.5秒，持续20分钟后自动恢复。查日志发现是数据库慢查询——一个插件定时任务跑了全表扫描。这种问题如果不告警，用户在这20分钟里提交询盘会超时，直接丢单。性能监控的价值就是把这种瞬时劣化捕捉到。Core Web Vitals怎么优化见Core Web Vitals阈值与优化优先级。
三、错误率与日志：5xx和4xx分开看
错误率监控要分两类：5xx是服务器错误，必须告警；4xx是客户端错误，大部分不用管。把两类混在一起统计，要么告警太多，要么真问题被淹没。5xx率超过1%持续5分钟发黄色，超过5%持续10分钟发红色。4xx只监控404突增——404多了说明有外链失效或改版漏配301。
错误追踪用Sentry这类工具，它能自动收集前端JS错误和后端异常，按错误分组。独立站不需要追每个错误，但要盯TOP 3错误的出现频率。某个错误突然从每周1次变成每小时10次，说明发版引入了bug。日志分析怎么做，见AI爬虫日志分析。
| 错误类型 | 正常基线 | 黄色阈值 | 红色阈值 | 处理方式 |
|---|---|---|---|---|
| 5xx服务器错误 | <0.5% | >1%持续5分钟 | >5%持续10分钟 | 查后端日志，回滚或扩容 |
| 404页面不存在 | <1% | 突增3倍持续1小时 | 突增10倍 | 查外链和301映射 |
| 前端JS错误 | <10次/天 | >50次/天 | >200次/天 | Sentry分组排查 |
| 询盘表单提交失败 | <1% | >3%持续10分钟 | >10% | 查SMTP和CRM同步 |
| 数据库连接失败 | 0次 | 单次 | 连续3次 | 立即查MySQL状态 |
场景示例：一个站发了新版本后，Sentry里一个JS错误从每天3次跳到每天200次。查代码发现是某个广告位的脚本在Safari上抛异常，影响了表单提交。这种bug不告警的话，Safari用户的询盘直接丢了。Sentry的错误频率监控能在发版后24小时内发现这类回归。
四、证书与备份监控：最容易被忘的两件事
证书过期是独立站最常见的”低级事故”。90%的证书过期不是技术问题，是忘了续。监控要设两层：剩余30天发邮件提醒，剩余15天发企业微信告警。不要等到只剩3天才提醒——那时候域名注册商邮箱可能也进垃圾箱了，或者DNS解析出问题来不及修。工具用UptimeRobot的证书监控或者自定义脚本每天探测。
备份任务本身也要被监控。备份脚本跑失败了，你不知道，真出事时才发现最近一次备份是两周前。三个告警规则：备份任务退出码非0就告警；备份文件大小比前一天突降30%告警（可能数据库连不上）；最新备份年龄超过24小时告警。备份策略详见网站备份与恢复演练。
| 监控项 | 检查频率 | 黄色阈值 | 红色阈值 | 通知方式 |
|---|---|---|---|---|
| SSL证书剩余天数 | 每日 | 剩余30天 | 剩余15天 | 邮件→企业微信 |
| 备份任务退出码 | 每次完成 | 非0 | — | 企业微信立即 |
| 备份文件大小 | 每日 | 比前日降30% | 比前日降70% | 企业微信 |
| 备份文件年龄 | 每日 | >24小时 | >48小时 | 企业微信 |
| 磁盘使用率 | 每小时 | >80% | >90% | 企业微信 |
| CPU/内存 | 每5分钟 | >80%持续10分钟 | >95%持续10分钟 | 企业微信 |
反直觉提醒：告警渠道不要用一个。邮件容易进垃圾箱，企业微信可能在休假没人看，短信电话是最后一道。重要告警（站点挂了、证书快过期）必须走短信电话，一般告警走企业微信群。同时设升级机制：红色告警15分钟没人处理，自动升级给技术负责人。日常巡检清单见官网维护期每月六件事。
监控体系搭完后，每月复盘一次告警：过去一个月发了多少条黄色、多少条红色、有多少条是误报。误报率超过30%的阈值要收紧或调整。监控的目标不是覆盖所有可能性，而是在真出事时能第一时间叫醒人——这要求你主动砍掉那些天天误报的规则。
FAQ 常见问题
独立站监控用什么工具，免费方案够吗？
告警太多团队不当回事怎么办？
可用性监控探测间隔多久合适？
SSL证书监控怎么设阈值？
性能监控盯哪个指标，PageSpeed分数要不要盯？
备份任务怎么监控失败？
写在最后
监控体系最常见的失败不是没监控，而是监控太多没人看。刚搭完监控时什么都想盯，CPU、内存、磁盘、网络、每个URL、每个错误，一周后告警多到团队麻木，真出事的红色告警淹没在黄色噪音里。监控的价值在于”关键时刻叫醒人”，不在覆盖广度。
落地三步：第一，按四个维度（可用性、性能、错误、证书）各设黄红两级阈值，黄色只发群不叫醒，红色才短信电话；第二，用免费工具组合跑起来，UptimeRobot加Sentry加证书脚本，月成本0元；第三，每月复盘一次告警，把误报率超过30%的规则砍掉。监控是个活系统，不是搭完就完事的——它需要你持续修剪。
一句可以记住的话：监控的目标不是覆盖所有可能性，而是真出事时能第一时间叫醒人——告警多到团队静音了，比没监控更危险。