IDC业务告警体系：宿主机宕机、IP失效、带宽跑满
IDC业务告警体系的核心目标，是在宿主机宕机、IP失效、带宽跑满、磁盘告警这四类事件发生时第一时间通知运维人员，避免业务长时间不可用。
本文不依赖商业监控产品，用脚本加定时任务就能搭起一套基础告警体系，适合刚接手服务器、又没有统一监控平台的零基础运维。
读完你会得到一套可直接改用的检测脚本、阈值参考和效果验证方法。
动手前需要准备什么
搭建这套告警体系只需要三样东西：
- 被监控的服务器：至少一台跑业务的Linux服务器，本文脚本在CentOS 7+ / Ubuntu 20.04+ 下验证可用。
- 通知渠道：企业微信群机器人、钉钉群机器人或邮件任意一个。企业微信群机器人最简单，只要有webhook地址就能用
curl发送告警。 - 定时任务环境：服务器自带
cron即可，不需要额外安装。
如果后续监控的机器变多，可以再迁移到Zabbix或Prometheus，但先跑通这套脚本能帮你理解告警逻辑。
四类告警的检测逻辑和触发条件
不同类型的事件要采用不同的检测方式，不能一概而论。
- 宿主机宕机：通过
ping -c 3判断主机是否响应。如果连续多次丢包，再结合SSH端口（如22）是否开放来确认不是简单网络抖动。注意，宕机不仅指断电，也可能是内核崩溃或硬件故障。 - IP失效：IP失效和宕机不一样，主机可能还活着，但IP无法路由。需要从外部拨测，对目标IP执行
ping并检查网关连通性。更可靠的方式是通过第三方探测节点或另一台不同机房的机器来测。 - 带宽跑满：查看网卡实时流量，用
/proc/net/dev或iftop。给出口带宽设置阈值，比如持续5分钟超过设定带宽的80%就告警。需要注意区分入方向和出方向，有些IDC会分别计费。 - 磁盘告警：用
df -h看使用率，比如超过85%触发；同时用df -i检查inode使用率，因为inode满也会导致无法写文件，即使磁盘还有空间。
一个开箱即用的Shell告警脚本
下面是一个简化版监控脚本，把四类检测合并在一起。
保存为/usr/local/bin/idc_alert.sh，并赋予执行权限。
#!/bin/bash
# IDC业务告警脚本：宿主机宕机、IP失效、带宽跑满、磁盘告警
WEBHOOK_URL="这里填企业微信或钉钉机器人地址"
HOST_IP="你的业务IP"
THRESHOLD_DISK=85
THRESHOLD_BANDWIDTH=80 # 单位百分比，需要按实际带宽换算
send_alert() {
local message=$1
curl -s -X POST "$WEBHOOK_URL" \
-H 'Content-Type: application/json' \
-d "{\"msgtype\": \"text\", \"text\": {\"content\": \"$message\"}}" >/dev/null 2>&1
}
# 1. 宿主机宕机检测：ping 3次全部失败才告警
if ! ping -c 3 -W 2 "$HOST_IP" >/dev/null 2>&1; then
send_alert "[宿主机宕机] $HOST_IP 连续ping失败，请立即检查"
fi
# 2. 磁盘使用率检测
disk_usage=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$disk_usage" -gt "$THRESHOLD_DISK" ]; then
send_alert "[磁盘告警] 根分区使用率 ${disk_usage}%，已超过 ${THRESHOLD_DISK}%"
fi
# 3. inode使用率检测（容易忽略）
inode_usage=$(df -i / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$inode_usage" -gt "$THRESHOLD_DISK" ]; then
send_alert "[磁盘inode告警] inode使用率 ${inode_usage}%，可能无法创建新文件"
fi
# 4. 带宽跑满检测（按实际网卡名调整）
# 先取当前总流量，等待5秒再取一次，计算差值得到速率
rx_before=$(cat /sys/class/net/eth0/statistics/rx_bytes)
tx_before=$(cat /sys/class/net/eth0/statistics/tx_bytes)
sleep 5
rx_after=$(cat /sys/class/net/eth0/statistics/rx_bytes)
tx_after=$(cat /sys/class/net/eth0/statistics/tx_bytes)
# 假设带宽为100Mbps，换算成字节每秒约12.5MB/s，这里给出百分比计算方式
rx_rate=$(( (rx_after - rx_before) / 5 / 1250000 * 100 ))
tx_rate=$(( (tx_after - tx_before) / 5 / 1250000 * 100 ))
if [ "$rx_rate" -gt "$THRESHOLD_BANDWIDTH" ] || [ "$tx_rate" -gt "$THRESHOLD_BANDWIDTH" ]; then
send_alert "[带宽告警] 入向 ${rx_rate}%，出向 ${tx_rate}%，已超过 ${THRESHOLD_BANDWIDTH}%"
fi
# 5. IP失效检测：从外部拨测才能确认，这里演示本机ping网关
GATEWAY="你的网关IP"
if ! ping -c 2 -W 2 "$GATEWAY" >/dev/null 2>&1; then
send_alert "[IP失效] 本机无法ping通网关 ${GATEWAY}，IP可能已失效"
fi然后添加cron任务，每5分钟执行一次：
*/5 * * * * /bin/bash /usr/local/bin/idc_alert.sh注意：脚本中带宽阈值按100Mbps算的，如果你的实际带宽不是100M，需要把1250000替换成对应值。
IP失效检测最好放在另一台正常网络的主机上运行，否则断网时脚本自己也发不出告警。
用监控工具替代脚本的迁移思路
脚本适合单机起步，但机器多了建议换用Zabbix或云监控。
在Zabbix里分别创建这四个监控项：ICMP Ping监控宿主机存活、端口监控判断IP是否可服务、流量监控用于带宽告警、磁盘监控项覆盖使用率和inode。
云厂商的监控产品（比如腾讯云、阿里云）也都有类似告警模板，可以在控制台配置告警策略，直接选择指标和阈值，再绑定通知渠道。
迁移时保持触发条件一致即可。
避坑指南和效果验证
这几个地方最容易踩坑，提前检查能省很多事：
- 阈值不要设太保守：磁盘85%告警很正常，但带宽80%如果是持续峰值可能频繁误报，建议结合业务历史数据调整，并加入“持续N分钟”条件。
- 告警去重：脚本每5分钟跑一次，同一故障会重复发消息。建议在脚本里加个临时标记文件，比如
/tmp/host_down，已告警则跳过，恢复后删除标记。 - 宿主宕机和IP失效要分开：主机宕机时ping不通，但IP失效时也可能ping不通，需要额外检查ARP或从外部探针测试。本文的网关ping方式只能做粗略判断。
- 验证不能省：修改脚本后，手动把阈值调低或临时停掉服务，确认能收到告警再恢复。例如执行
dd if=/dev/zero of=/tmp/test bs=1M count=1024临时占用磁盘，触发告警后删除文件。
如果你正在处理IDC业务告警体系的搭建，建议先把脚本跑通一次，确认每类事件都能正常触发通知，再逐步调整阈值和告警频率。
遇到异常时优先回看避坑部分，多数误报都是阈值或去重逻辑没处理好。
只要监控项覆盖宿主机宕机、IP失效、带宽跑满、磁盘告警这四类，你就能在业务受影响前获得足够响应时间。
