服务器告警通知配置：Telegram/Discord/飞书通道打通与分级自愈实战

结论先行：告警配置的核心不在于“发了多少通知”，在于“分级抑制与零漏报”。独立开发者应遵循 P0（业务瘫痪/磁盘超 90% 即刻推送 Telegram 高优私聊）、P1（资源吃紧超 80%/网络抖动推送 Discord 频道或飞书群）、P2（常规巡检日报汇总）三级策略。对于 1-2GB 内存的小型出海 VPS，推荐使用纯原生 Bash 且依赖 Crontab 驱动的开源工具 ittinker-scripts/vps-health-monitor，无需常驻守护进程，避免传统监控 Agent 拖垮主机。

---

告警流转与分级架构

面对出海业务，用户分布在全球各个时区，站长无法做到 24 小时紧盯屏幕。一套合格的告警体系，必须在服务异常的第一时间唤醒维护者，同时在系统常规抖动时保持安静。

---

告警分级策略：摆脱告警疲劳

很多开发者搭完监控后的第一件事，就是把所有阈值设得很低（比如 CPU 达到 70% 立即发消息），结果手机每隔两小时响一次。两周后，由于提示音过于频繁，整套通知被直接静音，真正的系统宕机反而被彻底无视。这就是典型的“告警疲劳（Alert Fatigue）”。

告警必须严格分级：

级别	定义与触发条件	目标通道	响应要求
P0 (Critical)	业务全线瘫痪、数据库离线、根目录磁盘剩余低于 10%	Telegram Bot 私聊（开启特别提醒）、手机直呼	立即停下手中事物，15 分钟内介入处理
P1 (Warning)	内存使用率超 85%、CPU 持续 5 分钟超 85%、HTTP 偶发 502	Discord 运维频道、飞书群机器人	当天工作时间内排查根因
P2 (Info)	Fail2ban 成功拦截异常 IP、SSL 证书自动续期成功、每日巡检	聚合通知频道、每日系统报告邮件	无需即时响应，每周统一回顾

---

三大常用告警通道打通实战

1. Telegram Bot 通道配置（海外首选）

Telegram 拥有极高稳定性的海外基础设施与原生 Bot API，适合接收 P0 级别的即时通知。

步骤一：创建 Telegram Bot

1. 在 Telegram 搜索并打开 @BotFather。
2. 发送 /newbot，依次输入 Bot 的显示名称与用户名（必须以 bot 结尾，例如 myvps_alert_bot）。
3. 保存系统返回的 HTTP API Token（格式如 7123456789:AAFlKj9_ExampleTokenString）。

步骤二：获取个人或群组 Chat ID

1. 在 Telegram 搜索并启动 @userinfobot，直接获取你本人的纯数字 Id（例如 123456789）。
2. 如需将通知发送到群组，请将创建好的 Bot 拉入群组，并向群组发送一条任意消息。访问以下链接获取群组 ID（群组 ID 通常以负号开头，例如 -1001234567890）：

   curl -s "https://api.telegram.org/bot7123456789:AAFlKj9_ExampleTokenString/getUpdates" | jq .

步骤三：命令行实测推送

运行以下命令验证通道连通性：

TG_BOT_TOKEN="7123456789:AAFlKj9_ExampleTokenString"
TG_CHAT_ID="123456789"

curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
  -d chat_id="${TG_CHAT_ID}" \
  -d parse_mode="Markdown" \
  -d text="🚨 *[P0测试] VPS告警测试*
主机：\`sg-prod-node-01\`
状态：Telegram 通道接入正常。"

---

2. Discord Webhook 接入

Discord 非常适合将系统产生的日志与预警汇聚到特定频道，方便多人协作与历史回溯。

步骤一：获取 Webhook 链接

1. 打开 Discord 服务器，在需要接收通知的文字频道旁点击齿轮设置图标（编辑频道）。
2. 进入「整合 (Integrations)」→「Webhooks」→「创建 Webhook」。
3. 命名为 Server-Monitor 并复制 Webhook URL（格式如 https://discord.com/api/webhooks/123456789012345678/abcdefg...）。

步骤二：命令行实测推送

DISCORD_WEBHOOK="https://discord.com/api/webhooks/123456789012345678/abcdefg_EXAMPLE_TOKEN"

curl -s -H "Content-Type: application/json" -X POST \
  -d '{
    "username": "VPS Sentinel",
    "avatar_url": "https://assets.ittinker.com/images/alert-avatar.png",
    "content": "⚠️ **[P1预警] 服务器内存使用率达到 88%**\n主机: `us-west-api-01`\n请留意后端进程消耗。"
  }' "$DISCORD_WEBHOOK"

---

3. 飞书自定义机器人接入

飞书适合团队沟通及境内外协同环境。

步骤一：创建飞书群机器人

1. 打开飞书目标群组，进入群设置 →「群机器人」→「添加机器人」→「自定义机器人」。
2. 输入机器人名称，复制 Webhook 地址（格式如 https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）。

步骤二：推送结构化富文本

FEISHU_WEBHOOK="https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

curl -s -H "Content-Type: application/json" -X POST \
  -d '{
    "msg_type": "post",
    "content": {
      "post": {
        "zh_cn": {
          "title": "🚨 服务器健康状态预警",
          "content": [
            [{"tag": "text", "text": "节点：sg-worker-01\n"}],
            [{"tag": "text", "text": "指标：磁盘根分区已使用 91%\n"}],
            [{"tag": "a", "text": "点击查看仪表盘", "href": "https://status.yourdomain.com"}]
          ]
        }
      }
    }
  }' "$FEISHU_WEBHOOK"

---

极简实战：开源脚本 vps-health-monitor

在 1 核 1GB 或 2GB 内存的 VPS 上，部署 Prometheus、Alertmanager 外加 Grafana 会直接吃掉 400MB-800MB 内存，反而成为服务器不稳定的元凶。

针对轻量级运维场景，推荐采用开源项目 ittinker-scripts/vps-health-monitor。该脚本由纯原生 Bash 编写，无第三方运行库依赖，借助系统自带的 Crontab 周期性触发，检查完毕立即退出，内存常驻占用为 0。

1. 部署与配置

执行以下命令直接拉取并赋予执行权限：

# 下载脚本到系统本地目录
sudo curl -fsSL https://raw.githubusercontent.com/ittinker/ittinker-scripts/main/vps-health-monitor/monitor.sh \
  -o /usr/local/bin/vps-health-monitor

sudo chmod +x /usr/local/bin/vps-health-monitor

2. 创建环境配置文件

将敏感 Token 放在单独的文件中，并设置严格的文件访问权限：

sudo mkdir -p /etc/vps-monitor
sudo tee /etc/vps-monitor/config.env > /dev/null << 'EOF'
# 告警阈值设定
ALERT_CPU=85
ALERT_MEM=85
ALERT_DISK=90

# 渠道配置（按需启用，留空则不触发对应渠道）
TG_BOT_TOKEN="7123456789:AAFlKj9_ExampleTokenString"
TG_CHAT_ID="123456789"
DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/123456789012345678/abcdefg_EXAMPLE_TOKEN"
FEISHU_WEBHOOK_URL=""
EOF

# 仅允许 root 读取密钥配置
sudo chmod 600 /etc/vps-monitor/config.env

3. 单次运行验证

在终端中载入环境配置并手动测试：

# 载入配置并运行
set -a
source /etc/vps-monitor/config.env
set +a

/usr/local/bin/vps-health-monitor

输出正常指标报告：

=== VPS Health Inspection [2026-11-11 12:05:00] ===
Host: tokyo-app-node (139.162.45.89)
CPU: 12% | Mem: 48% | Disk: 34% | Fail2ban Banned: 16
Status: All system metrics are within safe thresholds. [OK]

4. 配置 Crontab 巡检计划

通过 Crontab 设置每 10 分钟自动检查一次。只要指标低于阈值，脚本保持静默；一旦指标超标，即刻按配置渠道推送报警：

(crontab -l 2>/dev/null; echo "*/10 * * * * . /etc/vps-monitor/config.env; /usr/local/bin/vps-health-monitor > /dev/null 2>&1") | crontab -

---

告警防抖与自动化自愈设计

1. 避免偶发毛刺引发“假报警”

偶尔一个短时间的大文件解压或编译任务可能让 CPU 短暂冲上 95%，但 30 秒后恢复正常。若直接告警会打乱工作节奏。

• 在检测脚本中加入判断逻辑：发现高负载时，脚本等待 30 秒进行二次复验；只有二次复验依然超标才发送通知。
• 业务探活工具（如 Uptime Kuma）应配置至少“重试 2 次”机制，单次探针丢包不触发告警。

2. 联动自愈脚本

告警发出只是第一步，面对明确的物理性指标危机，结合脚本自动降级可以为开发者争取宝贵的睡眠时间。

例如，当磁盘剩余容量低于 10% 时，自动清理未使用的 Docker 镜像与悬空缓存：

#!/usr/bin/env bash
# /usr/local/bin/auto-disk-heal.sh
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$DISK_USAGE" -ge 92 ]; then
  # 自动清理已停止的容器、未使用的网络及悬空镜像
  docker system prune -af --volumes > /dev/null 2>&1
  # 清理系统旧日志
  journalctl --vacuum-size=200M > /dev/null 2>&1
fi

将其置于巡检脚本中一同触发，自愈后在告警内容后附带标明 [已自动执行 Docker Prune 与日志裁剪]。

---

生产部署排障与常见问题清单

异常现象	核心根因	解决排查手段
Telegram 推送返回 HTTP 400	Markdown 解析语法错误或 Chat ID 包含未转义字符	检查发送内容中是否存在下划线 _、星号 * 等特殊符号，或临时改用 parse_mode="HTML" 发送
Telegram 发送超时挂死	国内服务器无法直连 api.telegram.org 域名	换用海外 VPS 部署监控，或在 curl 命令中加入 --proxy socks5://127.0.0.1:1080
Crontab 未按时产生报警	Crontab 执行环境缺少 PATH 变量导致找不到命令	在脚本开头显式声明 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Discord 返回 400 Bad Request	JSON 格式错误或缺少 Content-Type: application/json 请求头	使用 jq 构造 payload，严禁在手动拼接的单双引号中夹杂换行符
通知每隔 10 分钟狂轰滥炸	脚本未记录上一次告警状态，触发连续推送	脚本触发报警后可在 /tmp/vps_alert.lock 写入时间戳，设定 2 小时冷却期内不重复推送相同级别的通知

---

落地检查清单

• [ ] 申请独立的 Telegram Bot，记录 Bot Token，并通过专属 Chat ID 实测发送成功
• [ ] 划分 P0/P1/P2 告警级别，避免所有警报统一走强提醒通道
• [ ] 下载部署 vps-health-monitor 脚本并把凭据存入权限为 600 的独立配置文件
• [ ] 将监控脚本配置进系统 Crontab（推荐 5-10 分钟周期）
• [ ] 在服务器上模拟一次高负载测试（如 stress --cpu 2 --timeout 60s），确认收到预警消息且指标无误
• [ ] 为磁盘等关键瓶颈挂载自动化自愈与日志清理后备逻辑