宕机告警的核心不是把故障消息发出去，而是让对的人在准确的时间用最顺手的渠道看到能直接定位问题的信息。 触发逻辑分级、通知渠道分响度、确认升级兜底，三者缺一不可。
先看触发,触发不准，后续的一切都是噪音。
宕机告警的触发逻辑：先搞懂什么才算真宕机
很多团队把告警做成“探测失败就通知”，结果是半夜两点收到一条消息，登录服务器一看，只是网络抖动了一下，行业共识认为，告警触发必须建立在“持续异常”的基础上，而不是单次失败。
探活层次分开看，三层探测还原故障真相
单靠 ping 判断宕机太粗，服务器活着不代表业务能用，业务能用不代表接口响应正常，真正可用的探活方式，建议做三层：
- 网络层探活：ICMP ping，判断主机是否可达，丢包率多少，延迟是否异常。
- 端口与协议层探活：TCP 连接检查特定端口，80、443、3306，确定端口是否在监听。
- 业务层探活：发一个真实的 HTTP 请求，检查返回状态码、响应耗时，甚至校验响应正文里是否包含预期关键字。
不少宕机事故其实是从业务层先崩的,端口正常，但应用线程池已经打满，首页返回 502，从网络层看一切正常，三层探测的好处是，你能一眼分辨故障发生在哪一层，通知内容也跟着变精准，比如消息里直接写“portal 首页连续三次 HTTP 502，平均响应 8.2 秒”，值班的人不需要再登服务器验证一遍。
阈值确认：连续三次失败，才算一次告警
触发条件设定为单次失败立刻告警,误报概率极大，合理的默认策略是：
- 连续 3 次探测失败，每次探测间隔 30 秒。
- 或者 5 分钟窗口内，失败次数占总探测次数的比例超过 80%。
这两个条件都满足,说明故障已经持续了至少一分半钟，大概率不是偶发抖动，用这种方式，把“疑似异常”和“确认故障”剥离开，平台整体不健康的时候，告警会泛滥，这时候要在触发逻辑里做聚合，规则设定为：同一服务的多个实例在 5 分钟内同时触发相同告警，只发送一条汇总消息，附带具体实例清单。
分级触发：给告警标上 P0、P1、P2
触发逻辑分不好,通知渠道就没法分，按影响范围定级，建议参考这套标准：
| 级别 | 典型场景 | 触发条件 | 目标对象 |
|---|---|---|---|
| P0 | 全站不可用、核心数据损坏、安全事件 | 连续 3 次失败确认，且影响用户请求 | 全体值班群 + 技术负责人 |
| P1 | 核心接口 5xx 比例升高、数据库连接池打满、SSL 证书过期 | 业务层探测失败，持续 2 分钟 | 值班工程师 + 直属主管 |
| P2 | 磁盘使用率超过 85%、慢查询增多、备份任务失败 | 单次指标超阈值 | 对应服务负责人 |
| P3 | 日常巡检类指标异常 | 单次触发 | 汇总到日报，不单独打扰 |
P0 和 P1 的触发，必须走电话 + 短信 + IM 群三条路同时发。 P2 级别只看 IM 和邮件就够了，把 P3 触发的告警塞进日报里，而不是深夜里发一条让人失眠的消息。
告警通知渠道怎么选：短信、电话、IM 群机器人
通知渠道的选型不只是“用哪个 App 收消息”的问题，而是“这个渠道能不能在对应级别的故障里把人叫醒”，业内专家指出，通知渠道的带宽不取决于发送速度，而取决于人回应的速度。
渠道分配逻辑：等级决定响度，而不是信息量决定响度
先把常见通知渠道的能力边界划清：
- 短信：到达率高，但容易被手机系统收纳进“推广信息”，适合 P1 及以上级别，减少使用频率，保证真正重要时能引起注意。
- 电话语音告警：最高打扰强度，能打断会议、叫醒睡觉的人，P0 故障必备，P1 在升级阶段使用。
- IM 群机器人（钉钉、企业微信、飞书）：大部分人最常用的渠道，消息里可以携带告警详情、日志链接、操作按钮，处理效率最高。
- 邮件：延迟不可控，适合 P2 以下级别和周报汇总。
- Webhook：对接自研工单系统或自动化运维平台，适合所有级别的告警流转，不直接触达个人。
渠道之间的配合逻辑,不是“全渠道轰炸”，而是“主渠道 + 升级渠道”，P1 告警触发时，先给值班工程师发 IM 群消息和短信，5 分钟没人确认，自动升级为电话告警，呼叫人。
确认与升级机制：把“人不在”变成自动处理
收到告警第一时间点确认,是告警体系的“闭环动作”，没有确认机制，你永远不知道告警到底是没看到、看到了没处理，还是处理完了忘了说。
推荐的确认与升级路径：
- 告警触发,IM 群 + 短信发出，附带“一键确认”链接。
- 5 分钟内无人确认，自动升级，拨打第一联系人电话。
- 电话接通并确认后,升级流程终止，开始计时故障处理时长。
- 15 分钟内仍无人确认，直接升级至技术负责人，同时拉起紧急响应群。
这套机制靠人来盯不现实,需要依赖监控平台的原生能力或自研脚本，Zabbix 里有确认动作设置，Prometheus 生态中可以通过 Alertmanager 配合 webhook 自行实现，后面细说。
成本与效果如何权衡
不少人纠结短信通知平台价格,其实没必要，按条计费，短信价格并不高，即使每天触发几百条消息，费用也在可控范围内，电话告警多按分钟或按次计费，相对贵一些，但只用于 P0 和升级场景，用量小，真正的成本大头是误报带来的人力消耗：一次半夜误报，让人白跑一趟机房，损失远超通讯费。
Zabbix 与 Prometheus 的告警配置实操
理论说完了,落到工具上，国内运维环境最常见的两套开源方案，配置思路略有差异，但都值得动手验证一遍。
服务器宕机告警怎么设置：Zabbix 三步落地
Zabbix 的触发逻辑极其灵活，配置路径也直观：
- 创建触发器：进入 Data collection → Hosts，选择目标主机，点击 Triggers → Create trigger，表达式写为
nodata(/host/key, 180)=1，意思是该监控项连续 180 秒无数据，则判定主机宕机。 - 配置动作：点击 Alerts → Actions → Trigger actions → Create action，触发条件设为“触发器严重性 = Disaster”且“主机组包含 线上核心”，操作步骤里添加“发送消息”给指定用户组，消息内容里引用
{ITEM.LASTVALUE}宏，这样通知里会直接附带最后采集到的指标值。 - 开启升级：在同一动作的 escalation 页签中，设定步骤间隔为 300 秒，步骤 1 发送 IM 和短信，步骤 2 开始拨打语音电话。
验证方法很直接：临时关闭被监控机器的 Zabbix agent，等服务端连续 3 个周期收不到数据，看告警是否按预设路径走完整条链路。
Prometheus + Alertmanager：用路由规则控制通知风暴
Prometheus 的触发条件写在 prometheus.yml 里的 rules 文件中，典型的宕机规则如下：
- alert: InstanceDown
expr: up == 0
for: 2m
labels:
severity: page
annotations:
summary: "{{ $labels.instance }} 已下线超过 2 分钟"for: 2m 持续 2 分钟才触发”的关键字段，Alertmanager 的 route 配置按标签分流：
route:
group_by: ['alertname', 'job']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: page
receiver: phone-sms
- match:
severity: warning
receiver: im-webhookrepeat_interval: 4h 决定同一条告警多久重新发送一次，这个值不建议设太短，否则故障持续期间，每几分钟收到一条重复消息，容易让人把群里新出现的告警也漏掉。
常见误区：告警数量多不等于防线稳固
告警体系搭建完毕后,几个问题需要定期检查。
- 告警阈值设得过于敏感，磁盘使用率 60% 就报警，一天能积几十条，建议把 P2 阈值改为 85%，P1 改为 95%，并区分数据盘和系统盘。
- 通知渠道平均用力，所有告警都用电话，时间长了值班人员会变得麻木，真正 P0 时反而接不到电话，详情进 IM，紧急才响铃。
- 忽略恢复通知，故障恢复后，应自动向同一渠道发送恢复消息，没有恢复消息，值班人员只能自己反复确认，浪费大量精力。
网站宕机怎么办：Q&A
Q：网站宕机怎么办？先看告警还是先看监控？
先看告警里的上下文,如果告警消息里已经写明了故障 IP、故障指标、持续时间，直接按消息指引登录对应主机排查，没有告警信息就盲目打开监控大盘，等于大海捞针，更稳妥的做法是，先认领告警，再通过告警自带的链接跳转到监控图表，确认故障范围是单台机器还是整个集群，确认范围后，按“先恢复后定位”的原则处理：重启服务或切流到备用节点，恢复业务后再分析根因。
Q：短信通知平台价格高不高？小团队怎么做成本控制？
短信价格本身很低,运营商通道按条计费，单价在几分钱量级，即使每月触发几千条也在预算范围内，高成本源于高频次，控制办法有两个：一是严格分级，P0/P1 才发短信，P2 只发 IM；二是优化确认机制，有人点确认后，重复短信立即停止，相比短信，电话告警的成本要高不少，但只用于升级场景，整体负担有限，真正的成本大头是误报导致的人力消耗。
Q：告警触发延迟设多长才合适？
延迟时间与业务容忍度强相关,线上核心交易系统，用户请求每多失败一秒都是损失，延迟建议控制在 30 秒到 1 分钟，内部管理系统，延迟 3 分钟完全可接受，定时任务类业务，比如每天的报表生成，延迟 10 分钟都来得及处理，关键在于先用“持续失败次数”筛掉抖动，再考虑延迟长短，优先保证告警不误报，再谈及时性。
告警体系的价值不在于把每个异常都捕捉到,而在于每一次通知都有明确含义，触发逻辑分级，通道响度分级，确认机制闭环，这套骨架搭好了，任何一层的故障都能在最短时间内找到对的人，当告警变成稀缺消息时，它的份量自然就回来了。