网站挂了，网站用户第一个知道，监控你最后一个知道——这种事发生过一次就够了。情况去判监控系统到底该盯哪些地方？网站我把自己踩过的坑和日常盯盘的经验拆开说说。

最基础的监控，HTTP状态码。情况去判200是网站正常，301/302看跳转逻辑对不对，监控403可能是情况去判权限配错了，404别急着报警——有些爬虫天天扫你后台，网站404量突然飙升反而是监控被扫描的信号。真正要命的情况去判是5xx。我见过一个案例：某电商大促前压测，网站502间歇性出现，监控运维以为是情况去判后端超时，查了两天才发现是Nginx的upstream连接池设小了。状态码监控不能只看“有没有5xx”，得看5xx的分布——是集中在某个接口，还是全站随机出现？这决定了你是改代码还是改架构。

响应时间比状态码更早暴露问题。一个接口从200ms涨到800ms，可能还没报错，但用户已经在骂了。我习惯给每个核心接口设三档阈值：正常、警告、严重。比如登录接口，300ms以内算正常，800ms发告警，2秒以上直接打电话。别小看这个梯度，半夜被叫醒和早上到公司再处理，体验天差地别。另外响应时间要看P95和P99，平均值会骗人——100个请求里99个飞快、1个卡死10秒，平均值照样好看，但那个卡死的用户可能正好是下单的。

内容正确性是最容易被忽略的。状态码200、响应时间50ms，但返回的JSON里字段全空了——这种故障监控工具默认不报。我经历过一次：某API返回的user_id变成了null，前端直接白屏。后来加了一条规则：对关键接口的响应体做字段校验，比如必须包含order_id且不为空字符串。还有更隐蔽的，页面标题变了、页脚版权年份没更新、某个div的class名被改导致样式崩了。这些用“内容指纹”来盯——定期抓取页面，跟基线做diff，差异超过阈值就告警。

证书和域名过期是定时炸弹。SSL证书到期前30天、7天、1天各提醒一次，别信“我记得续”。我见过一个公司因为域名忘了续费，被竞争对手抢注，整个品牌流量一夜归零。还有DNS解析——监控节点分布在不同运营商，有的地方解析到旧IP，有的地方正常。这种“局部故障”最折磨人，用户投诉你还找不到原因。用多地ping和dig对比，解析结果不一致就报警。

服务器资源得看趋势，不是看单点。CPU 90%不一定有事，但连续10分钟从30%涨到90%，大概率有慢查询或者死循环。内存要看swap使用率，一旦开始用swap，性能断崖式下跌。磁盘空间更直接——低于20%发警告，低于10%打电话。我吃过亏：日志文件把磁盘写满，MySQL直接拒绝写入，整个站点503。后来加了日志轮转和磁盘监控，再没出过这事。

最后说个反直觉的：监控“成功”比监控“失败”更重要。支付回调成功率从99.9%掉到99.5%，看起来只差0.4%，但乘以日订单量就是几百笔异常。登录成功率、搜索无结果率、购物车加购失败率——这些业务指标比技术指标更接近钱。我现在的习惯是，技术告警和业务告警分两个群，业务告警优先级永远更高。

监控不是装个Zabbix就完事。你得知道自己的命门在哪：是支付接口不能挂，还是商品详情页不能慢，还是后台管理不能登不上。把这些场景翻译成具体的监控项，阈值调到你半夜愿意起床的那个点。剩下的，交给告警收敛和值班表。