融合监控告警体系能力报告
报告日期: 2026-09-14
体系版本: v1.0
状态: D2测试验证中
一、体系架构
1.1 核心组件
┌─────────────────────────────────────────────────────────────────┐
│ 融合监控告警体系 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ alert_channel │ │ dead_mans │ │
│ │ _health.py │◄─────│ _switch.py │ │
│ │ (通道健康监控) │ │ (看门狗) │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ └──────────┬──────────────┘ │
│ ▼ │
│ ┌────────────────────────────┐ │
│ │ alert_utils.py │ │
│ │ - send_tg() (TG告警) │ │
│ │ - record_alert() (写表) │ │
│ │ - check_silence() (静默) │ │
│ └──────────────┬─────────────┘ │
│ ▼ │
│ ┌────────────────────────────┐ │
│ │ alert_state.db │ │
│ │ - alerts表 (告警记录) │ │
│ │ - task_runs表 (运行记录) │ │
│ │ - channel_health表 (心跳) │ │
│ │ - silence_state表 (静默) │ │
│ │ - audit_log表 (审计日志) │ │
│ └────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌──────────────┴──────────────┐ │
│ │ run_with_alert.py │ │
│ │ (包装脚本，添加告警能力) │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
1.2 数据流
任务运行 → run_with_alert.py → 成功/失败 → TG告警 + 写库
↓
alert_utils.py
↓
alert_state.db
心跳机制:
alert_channel_health.py → 每15分钟 → channel_health表
↓
dead_mans_switch.py → 每小时检查
↓
超时30分钟 → TG告警 + 本地文件
二、预期能力
2.1 监控能力
| 能力 | 说明 | 覆盖范围 |
|---|---|---|
| 任务状态监控 | 检测任务失败、超时、异常 | 5个agent-mode任务 + 所有script-mode任务 |
| 心跳监控 | 监控监控组件自身健康 | alert_channel_health心跳 |
| 看门狗机制 | 心跳停止30分钟触发告警 | dead_mans_switch独立运行 |
| 多级告警 | P0/P1/P2/P3分级处理 | 按任务重要性分级 |
| 静默管理 | 防止告警风暴 | P0不静默，P1静默5分钟 |
2.2 告警能力
| 能力 | 说明 | 触达方式 |
|---|---|---|
| TG实时告警 | Telegram Bot推送 | 即时消息 |
| 邮件备份 | SMTP邮件发送 | 异步备份（可选） |
| 本地文件 | 写入alert.txt | 持久化记录 |
| 数据库记录 | alerts表存储 | 可查询追溯 |
| 恢复通知 | 任务恢复时通知 | 完整闭环 |
2.3 数据能力
| 能力 | 说明 | 表名 |
|---|---|---|
| 告警记录 | 所有告警事件 | alerts |
| 运行记录 | 任务执行历史 | task_runs |
| 心跳记录 | 监控组件健康 | channel_health |
| 静默状态 | 防风暴计数 | silence_state |
| 审计日志 | 系统操作追踪 | audit_log |
2.4 运维能力
| 能力 | 说明 | 价值 |
|---|---|---|
| 热替换测试 | B3影子cron模式 | 不中断生产测试新功能 |
| 双备份回滚 | jobs.json + alert_state.db | 快速恢复 |
| 时间戳标记 | 测试告警区分 | 避免误判 |
| 标准化接口 | alert_utils统一调用 | 降低集成成本 |
三、如何使用新体系
3.1 为任务添加告警能力
方式A：使用run_with_alert包装（推荐）
# 原cron命令
python hb_morning_eval.py
# 改为包装模式
python run_with_alert.py eval_morning hb_morning_eval.py
配置步骤:
1. 在jobs.json中找到目标任务的command字段
2. 修改为：python run_with_alert.py <task_id> <script_path>
3. 在TASK_LEVELS中配置优先级（P0/P1/P2）
示例:
{
"name": "盘前评估",
"command": "python run_with_alert.py eval_morning C:/.../hb_morning_eval.py",
"schedule": {"expr": "0 6 * * 1-5"}
}
方式B：保持原样（已有监控覆盖）
已监控的5个agent-mode任务（通过alert_channel_health轮询）:
- position_688306 (P0, 持仓监控)
- ops_system_health (P1, 系统自检)
- ops_backup_daily (P1, 备份检查)
- risk_sentiment_radar (P1, 风险雷达)
- eval_pias_daily (P1, PIAS评估)
3.2 查看告警记录
# 查看所有告警
sqlite3 D:/Hermes/data/state/alert_state.db "SELECT * FROM alerts ORDER BY created_at DESC LIMIT 20;"
# 查看任务运行历史
sqlite3 D:/Hermes/data/state/alert_state.db "SELECT * FROM task_runs WHERE task_id='eval_morning' ORDER BY start_time DESC LIMIT 10;"
# 查看心跳状态
sqlite3 D:/Hermes/data/state/alert_state.db "SELECT * FROM channel_health ORDER BY check_time DESC LIMIT 5;"
# 查看看门狗告警文件
cat D:/Hermes/data/state/dead_mans_switch_alert.txt
3.3 配置任务优先级
编辑 run_with_alert.py 中的 TASK_LEVELS:
TASK_LEVELS = {
# P0（立即告警，不静默）
"ops_heartbeat_watchdog": "P0",
"eval_morning": "P0",
"data_risk_radar_morning": "P0",
"report_pre_market": "P0",
# P1（连续2次失败告警，静默5分钟）
"quality_ic_monitor": "P1",
"eval_war_room": "P1",
"risk_capital_watchdog": "P1",
# 其他任务默认P2
}
3.4 手动触发监控
# 手动运行通道健康检查
hermes cron run 7e8ae2aeca81 --run-now
# 手动运行看门狗检查
hermes cron run <dead_mans_switch_cron_id> --run-now
# 手动运行包装任务
python run_with_alert.py eval_morning hb_morning_eval.py
3.5 回滚操作
# 回滚jobs.json
cp C:/Users/Admin/AppData/Local/hermes/cron/jobs.json.bak_20260913 \
C:/Users/Admin/AppData/Local/hermes/cron/jobs.json
# 回滚alert_state.db
cp D:/Hermes/data/state/alert_state.db.bak_D2_20260915 \
D:/Hermes/data/state/alert_state.db
# 恢复暂停的cron
hermes cron resume 7e8ae2aeca81 --run-now
hermes cron resume a7e2b8dceefe --run-now
四、使用场景示例
场景1：任务失败告警
原脚本: hb_morning_eval.py
问题: 脚本执行失败，用户不知道
使用新体系后:
1. run_with_alert.py包装执行
2. 检测到exit_code非0
3. 发送TG告警: "🔴 [P0] eval_morning 失败"
4. 写入alerts表
5. 写入audit_log
6. 用户立即收到通知
场景2：心跳停止告警
原状态: alert_channel_health卡死，无告警
使用新体系后:
1. alert_channel_health停止写心跳
2. dead_mans_switch每小时检查
3. 检测到心跳超时30分钟
4. 发送TG告警: "🔴 [看门狗] 心跳超时"
5. 写入本地文件: dead_mans_switch_alert.txt
6. 发送邮件（如配置SMTP）
场景3：防告警风暴
问题: 任务持续失败，每分钟告警一次
使用新体系后:
1. P0任务：每次失败都告警（重要任务）
2. P1任务：第一次失败静默，第二次失败告警
3. 告警后静默5分钟（P1）
4. 避免手机持续震动
场景4：热替换测试
需求: 测试新的告警逻辑，不影响生产
使用新体系后:
1. 创建影子cron任务
2. 指向测试脚本
3. 与原cron并行运行
4. 比对输出结果
5. 确认无误后切换
6. 删除影子任务
五、D2验证目标
| 测试项 | 验证内容 | 通过标准 |
|---|---|---|
| Dead-Man测试 | 心跳停止30分钟触发告警 | dead_mans_switch_alert.txt有记录 + TG收到告警 |
| 告警路径测试 | 任务超时触发告警 | alerts表有记录 + TG收到告警 |
| 超时路径测试 | timeout_threshold_s生效 | 正确识别超时任务 |
| 通道健康测试 | 心跳记录正常 | channel_health表持续更新 |
| B3集成测试 | run_with_alert包装功能 | 6项指标全部通过 |
| 回归验证 | 系统恢复正常 | 所有cron active，无残留测试数据 |
六、后续演进方向
6.1 短期（1-2周）
□ 扩展监控任务列表（目前只覆盖5个agent-mode任务）
□ 配置SMTP邮件备份（目前未配置）
□ 优化静默期策略（根据实际告警频率调整）
□ 添加告警聚合功能（同类告警合并）
6.2 中期（1个月）
□ 集成到war_room看板（实时监控面板）
□ 添加告警统计报表（周/月报）
□ 支持多Telegram群分发
□ 添加告警升级机制（P1→P0自动升级）
6.3 长期（3个月）
□ AI辅助告警分析（根因定位）
□ 预测性维护（基于历史数据预测故障）
□ 自动化修复（常见故障自动恢复）
□ 多渠道告警（SMS/钉钉/企业微信）
七、总结
7.1 核心价值
1. 全覆盖监控: 从任务级到组件级，双层保障
2. 实时可达: TG即时推送，关键时刻不错过
3. 可追溯: 完整审计日志，问题定位有据可依
4. 易集成: 统一接口，新任务快速接入
5. 可测试: 影子cron模式，安全验证新功能
7.2 使用门槛
✓ 已有D1观察数据（90次运行验证稳定性）
✓ 双重备份机制（降低风险）
✓ 明确的时间表（可控执行）
✓ 完善的回滚方案（可逆操作）
7.3 下一步
D2测试通过 → 扩展监控范围 → 配置邮件备份 → 集成war_room看板
报告路径: D:/Hermes/reports/融合监控告警体系能力报告.md
问题反馈: 请在TG频道"上书房行走"反馈使用体验