SentinelBot：基于 Prometheus 的智能监控告警机器人

写在前面

最近和 AI 一起折腾了个融合性监控工具,属实是解决了我运维工作中的一个大痛点。想着可能也有人遇到类似问题,就写篇文章分享一下。

为什么要做这个?

说实话,管理几十上百台服务器真的挺头疼的。以前用的监控方案有这么几个问题:

告警到处飞:邮件、短信、企业微信…收到消息的时候经常已经晚了
信息太乱:一封告警邮件里一大堆文字,关键信息得自己找
不够实时:邮件延迟高,手机上看也不方便
还得登录系统:收到告警后,还要打开电脑登录各种后台才能看详情

凌晨两点被告警吵醒,然后还要爬起来开电脑,这谁顶得住啊?

所以就想着能不能做个更顺手的工具,在手机上直接就能看到服务器状态,点几下就能定位问题。

技术选型

Prometheus + Alertmanager

这个组合算是监控领域的标配了:

PromQL 很灵活:想查什么指标都能写出来
标签系统好用:可以按项目、角色、环境等各种维度分组
生态丰富:Node Exporter、CloudWatch Exporter 这些采集器都现成的

Alertmanager 负责告警管理:

可以根据告警级别设置不同的推送策略
支持告警聚合,避免被刷屏
Webhook 可以对接任何第三方系统

为什么选 Telegram Bot?

这个可能有人会问,为啥不用企业微信或者钉钉?

说实话,Telegram 有几个独特优势:

推送真的快:App 在后台也能秒收到消息
Bot API 很强大:支持内联按钮、Markdown 格式,交互体验好
全平台同步:手机、电脑、网页端随时切换
个人就能用:不需要企业认证,注册个 Bot 就行
适合海外服务器:我的服务器在香港和新加坡,用 Telegram 刚好

核心功能

1. 监控面板

这不只是个被动接收告警的工具,平时也能主动查询:

服务器监控

CPU 使用率:5 分钟平均值,还有趋势箭头 (↗️ 上升 / ↘️ 下降 / ➡️ 平稳)
内存占用:用的是 MemAvailable,比 MemFree 准确
磁盘空间:支持多分区,自动找出最紧张的那个
系统负载:Load1 指标,快速判断压力

数据库监控

通过 CloudWatch Exporter 采集 RDS 指标:

CPU 利用率
连接数
剩余存储空间
可用内存

项目分组

所有资源按项目分组,可以:

逐个浏览:点进去看每台服务器的详细状态
一屏汇总:整个项目的资源使用情况一目了然
异常筛选:一键只看有问题的节点

2. 智能告警

当 Prometheus 触发告警时,Alertmanager 会调用 Bot 的 Webhook:

消息优化

结构化展示:项目、服务器、告警类型、严重程度,一眼就能看清
时间本地化:自动把 UTC 时间转成北京时间
快捷按钮:
- 🔍 查看节点详情
- 📊 查看项目汇总
- 🏠 返回主菜单

分级推送

不同级别的告警,推送策略也不一样:

routes:
  # 宕机告警:立即发送
  - match:
      alertname: "InstanceDown"
    group_wait: 0s
    repeat_interval: 15m
  
  # Critical 告警:30 分钟重复一次
  - match:
      severity: "critical"
    repeat_interval: 30m
  
  # Warning 告警:2 小时重复一次
  - match:
      severity: "warning"
    repeat_interval: 2h

防刷屏

如果同时触发超过 10 条告警,会自动折叠,只显示前 10 条,避免消息刷屏。

3. MFA 验证码

顺便还加了个 TOTP 验证码生成功能:

实时倒计时:进度条显示剩余时间
一键刷新:不用重新发命令
权限控制:只有管理员能用

技术实现

整体架构

┌─────────────────┐
│  被监控服务器    │
│  (Node Exporter)│
└────────┬────────┘
         │
         │ :9100
         ▼
┌─────────────────┐      ┌──────────────┐
│   Prometheus    │─────▶│ Alertmanager │
│   :9090         │      │ :9093        │
└─────────────────┘      └──────┬───────┘
         │                      │
         │                      │ Webhook
         │                      ▼
         │              ┌────────────────┐
         │              │  SentinelBot   │
         │              │  (Flask:5000)  │
         │              │  (Telegram)    │
         │              └────────────────┘
         │                      │
         ▼                      │
┌─────────────────┐            │
│ CloudWatch      │            │
│ Exporter        │            │
│ (RDS Metrics)   │            │
└─────────────────┘            │
                               ▼
                        ┌──────────────┐
                        │ Telegram API │
                        └──────────────┘

核心组件

Prometheus 配置

监控三类目标:

scrape_configs:
  # 服务器节点
  - job_name: 'nodes'
    static_configs:
      - targets: ['10.0.1.100:9100']
        labels:
          project: 'ProjectA'
          role: 'web'
          alias: 'web-server-01'
  
  # AWS RDS
  - job_name: 'aws-rds'
    static_configs:
      - targets: ['cloudwatch-exporter:9106']

通过 labels 打标签,方便后续分组和路由。

告警规则

定义了一套完整的告警规则:

告警类型	阈值	持续时间	级别
实例宕机	up == 0	10s	critical
CPU 使用率高	> 80%	5m	warning
CPU 使用率严重	> 90%	5m	critical
内存使用率高	> 85%	5m	warning
内存即将耗尽	> 95%	5m	critical
磁盘空间不足	> 85%	10m	warning
根分区即将写满	> 90%	5m	critical

Bot 核心逻辑

Flask Webhook 接收告警:

@app.route('/webhook', methods=['POST'])
def webhook():
    data = request.json
    if data and 'alerts' in data:
        process_alerts(data)
    return "OK", 200

Telegram Bot 交互处理:

def handle_callback(update: Update, context: CallbackContext):
    query = update.callback_query
    data = query.data
    
    if data.startswith("node:"):
        instance = data.split(":", 1)[1]
        handle_node(query, instance)
    elif data.startswith("project:"):
        project = data.split(":", 1)[1]
        handle_project(query, project)

通过 callback_data 实现无状态交互,点击按钮时自动携带上下文。

部署方式

用 Docker Compose 一键部署:

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/rules:/etc/prometheus/rules
    ports:
      - "9090:9090"
  
  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"
  
  sentinel-bot:
    build: ../mfa
    env_file:
      - ../.env
    ports:
      - "5000:5000"

配合一个简单的管理脚本:

./manage.sh start   # 启动所有服务
./manage.sh stop    # 停止所有服务
./manage.sh logs    # 查看日志
./manage.sh status  # 查看状态

实际使用体验

几个明显的优势

1. 真的很快

从告警触发到手机收到通知,基本在 2-5 秒内,比邮件(分钟级)和短信(十几秒)快太多了。

2. 信息密度高

一条告警消息包含:

项目名称
服务器信息
告警类型和级别
触发时间(本地化)
详细说明
快捷操作按钮

不用打开多个系统,一屏就能看全。

3. 交互式排查

收到告警后,直接在 Telegram 里:

点 “查看节点详情” → 看 CPU/内存/磁盘实时状态
点 “查看项目汇总” → 了解整个项目健康状况
点 “仅异常” → 快速定位所有问题节点

“告警 → 查看 → 定位” 一气呵成,效率高了不少。

4. 多项目管理方便

我同时管理好几个项目,Bot 通过 project 标签自动分组:

告警消息自动标注项目
浏览资源时按项目分类
支持快速切换

5. 成本低

Prometheus/Alertmanager: 开源免费
Telegram Bot: 完全免费
资源占用: 1 核 1G 内存就够了

真实案例

案例 1: 磁盘空间告警

某天凌晨 2 点,手机震了一下:

🔥 系统告警 (项目A)

🖥 服务器: web-server-01
🏷 角色: web
📊 告警类型: 磁盘空间不足
📌 状态: ❌ Firing (warning)
⏰ 时间: 2026-01-05 02:34:12 CST

📍 说明:
根分区磁盘使用率超过 85%

点 “🔍 查看节点详情”,发现:

根分区 /: 89.2% (53.5G / 60.0G)
数据分区 /data: 45.3% (90.2G / 200.0G)

立马 SSH 登录,清理了一下日志,磁盘降到 72%,5 分钟后收到恢复通知。

整个过程不到 10 分钟,而且没开电脑。

案例 2: 数据库 CPU 飙升

某次业务高峰,数据库 CPU 突破 80%:

🔥 系统告警 (项目B)

🖥 服务器: db-primary
📊 告警类型: RDS CPU 使用率高
📌 状态: ❌ Firing (warning)

数据库 CPU 使用率已达到 83.2%

点 “查看项目汇总”,发现:

数据库连接数: 287 (正常范围)
API 服务器 CPU: 92% ↗️

判断是 API 服务器负载高导致查询增多,立即扩容了 API 实例,问题解决。

还有哪些不足

当前限制

静态配置:服务器列表写在配置文件里,新增节点要重启 Prometheus
单点故障:监控栈本身没做高可用
历史数据有限:Prometheus 默认只保留 15 天

后续优化方向

服务发现:接入 Consul/Kubernetes,实现动态服务发现
长期存储:对接 Thanos/VictoriaMetrics,持久化历史数据
AI 辅助:接入 LLM,做告警根因分析和修复建议
多租户:不同项目配置独立的 Telegram 群组

总结

这个工具是我和 AI 一起折腾出来的,解决了几个核心痛点:

✅ 告警秒到,不会错过关键事件
✅ 信息结构化,快速理解问题
✅ 交互式排查,不用登录多个系统
✅ 多项目统一管理,降低心智负担

如果你也在管理服务器,被传统告警方式折磨,可以试试这套方案。

项目已开源,欢迎 Star!

🔗 GitHub 仓库: https://github.com/7Ese/SentinelBot

技术栈: Python · Prometheus · Alertmanager · Telegram Bot API · Flask · Docker

关键词: DevOps · 监控告警 · 运维自动化 · Telegram Bot · Prometheus