为什么需要一套可靠的监控告警架构
公司刚上线的新系统，凌晨两点突然数据库连接数暴增，服务器负载飙到90%以上。等运维赶到时，服务已经中断了近半小时。事后查日志才发现是一次小规模DDoS攻击，但因为没有实时告警，错过了最佳响应时间。
这种情况在中小型团队并不少见。系统越来越复杂，微服务、容器、云资源交织在一起，靠人工盯仪表盘根本不现实。真正能救命的，是一套设计合理的监控告警架构。
监控不是越多越好
见过最夸张的案例，一个业务接口被设置了12条告警规则：响应时间、错误率、调用量、CPU、内存、磁盘、网络IO……连GC次数都单独拉了一条。结果每天收到几百条通知，99%是误报。时间一长，所有人对告警麻木了，真出事反而没人理。
好的监控要懂得取舍。比如登录接口，核心关注点就三个：可用性（是否500）、延迟（是否超500ms）、异常登录尝试（连续失败超过10次）。其他指标可以进报表，但没必要设成一级告警。
分层设计：从基础设施到业务逻辑
把监控分成三层比较合理：
第一层：基础资源，服务器、网络、存储这些。用Prometheus+Node Exporter就能搞定大部分Linux机器的采集。
第二层：中间件与服务，比如MySQL慢查询、Redis连接池耗尽、Kafka堆积。这部分需要针对组件做专项监控。
第三层：业务指标，注册转化率下降、支付成功率异常、订单量突降。这类告警往往价值最高，但最容易被忽略。
告警怎么发才有人看
微信机器人往群里狂刷消息，半小时弹出二十多条“CPU过高”，最后只能选择静音。关键是要分级和收敛。
紧急级别走电话呼叫，比如核心服务完全不可用；高优先级推企业微信/钉钉，比如数据库主从断开；低级别统一汇总成日报邮件。同一个故障源产生的多个告警，应该合并成一条，而不是刷屏。
一个实用的告警配置示例
以监控Nginx入口流量为例，判断是否遭遇CC攻击：
ALERT nginx_request_rate_high
IF rate(nginx_http_requests_total[5m]) > 1000
FOR 2m
LABELS { severity = "critical" }
ANNOTATIONS {
summary = "Nginx请求速率异常升高",
description = "过去5分钟平均每秒请求数超过1000，持续2分钟，可能存在CC攻击"
}这里设置了两个缓冲：一是必须持续超标2分钟才触发，避免毛刺；二是通过rate函数计算速率，比直接看计数更准确。
别忘了设置监控自身的健康检查
曾经有团队遭遇过这样的尴尬：机房断电导致所有服务器离线，按理说应该收到一堆主机失联告警。结果因为监控系统也部署在同一机房，跟着一起挂了，整整三小时没人发现。
现在他们的做法是在公有云上单独部署一套轻量级探测器，定时ping内部核心服务。即使本地Zabbix瘫痪，外部还能发现问题，并通过短信通知负责人。
让告警可追踪、可复盘
每次告警触发后，自动在Jira创建事件单，关联当时的日志、链路追踪ID和监控截图。下次再出现类似问题，搜一下历史记录，可能解决方案早就有了。
有家电商公司甚至把过去半年所有告警按类型统计做成看板。发现“磁盘空间不足”类告警每月平均发生4.7次，于是干脆把扩容流程自动化，现在这类告警直接触发脚本清理临时文件，人工介入次数下降了八成。