Files

T

2569718930@qq.com e79bc2d291 清理废弃代码并同步全部文档：删除钱包异动监控模块，移除已废弃功能的文档引用

- 删除 polymarket_wallet_activity_watcher.py（914行）及 runtime_coordinator 调度
- 移除 LGBM / Polymarket 价格层 / Groq / prewarm 等 v1.7.0 已废弃功能的文档引用
- 清理 6 个死文档链接，更新文档索引和版本日期
- 移除 POLYMARKET_WALLET_ACTIVITY_* / PREWARM_* 等废弃环境变量

Directive: 文档与代码同步清理，无功能变更
Tested: pytest tests/test_bot_runtime_coordinator.py pass
Confidence: high

2026-05-23 21:42:46 +08:00

4.7 KiB

Raw Blame History

外部监控与告警说明

最后更新：2026-04-18

1. 目标

在现有轻量可观测性基础上，把 PolyWeather 补成最小可用的外部监控链路：

Prometheus 抓取 /metrics
Alertmanager 根据规则聚合告警
Relay 把告警推到运营频道
Grafana 展示趋势面板
巡检脚本补健康检查

2. 组件

本仓库现在内置 4 个监控组件：

polyweather_prometheus
polyweather_alertmanager
polyweather_alert_relay
polyweather_grafana

对应配置目录：

3. 启动

docker compose --profile monitoring up -d polyweather_prometheus polyweather_alertmanager polyweather_alert_relay polyweather_grafana

默认端口：

Prometheus: 9090
Alertmanager: 9093
Grafana: 3001
Alert relay: 9099

4. 环境变量

在 .env.example 里新增了这些配置：

POLYWEATHER_PROMETHEUS_PORT=9090
POLYWEATHER_ALERTMANAGER_PORT=9093
POLYWEATHER_ALERT_RELAY_PORT=9099
POLYWEATHER_GRAFANA_PORT=3001
POLYWEATHER_GRAFANA_ADMIN_USER=admin
POLYWEATHER_GRAFANA_ADMIN_PASSWORD=polyweather
POLYWEATHER_MONITORING_ALERT_CHAT_IDS=

说明：

POLYWEATHER_MONITORING_ALERT_CHAT_IDS 为空时，relay 会自动回退到：
- TELEGRAM_CHAT_IDS
- TELEGRAM_CHAT_ID
告警发送仍复用现有 TELEGRAM_BOT_TOKEN

5. 当前告警规则

当前默认规则：

PolyWeatherWebDown
PolyWeatherHttp5xxBurst
PolyWeatherHighSourceErrorRate
PolyWeatherOpenMeteoCooldownLoop
PolyWeatherSlowHttpAverage

规则文件：

monitoring/prometheus/alerts.yml

6. 当前 Grafana 面板

预置了一个最小仪表板：

PolyWeather Overview

包含这些图：

HTTP Requests by Status
HTTP Latency
Source Requests by Outcome
Source Error Rate (15m)

7. 巡检脚本

手动巡检：

python scripts/check_ops_health.py --base-url http://127.0.0.1:8000

这个脚本会检查：

/healthz
/api/system/status
/metrics

任何一项失败都会非零退出，适合挂到 crontab 或 systemd timer。

8. 当前内置运行态观测

除了 Prometheus / Grafana 这套外部监控，当前后端还内置了更贴业务的只读运行态：

/api/system/status
/ops

目前已覆盖：

缓存桶条目数：
- api_cache
- metar
- taf
- nmc
- settlement
- open_meteo forecast / ensemble / multi-model
summary 分析缓存命中率：
- total_requests
- cache_hits / cache_misses
- hit_rate / miss_rate
前端数据完整性状态：
- 城市详情是否仍处于 detail_depth != full
- 多日预报是否只返回当天单卡
- 日内分析 full detail / market scan 是否仍在同步
- 右侧详情面板是否正在用同步占位卡提示用户

这意味着：

外部监控负责“服务活没活、错误有没有暴增”
/ops 和 /api/system/status 负责“预热有没有真的跑、缓存有没有真的被打热”
前端同步状态负责“用户现在看到的是完整分析，还是仍在补齐中的中间态”

9. 前端中间态巡检

近期重点避免两类误判：

打开今日日内分析时，先看到上一轮城市 / 日期的旧内容，几秒后才刷新成正确结果。
右侧详情面板只到达当天单张多日卡，用户误以为未来预报缺失。

当前前端已做这些保护：

today/future 弹窗模式显式分离，今天按钮不会再偶发进入未来日期分析布局。
今日日内分析同步期间显示刷新锁，旧内容降权、禁止交互。
详情面板发现稀疏 detail 或单日 forecast 时显示补齐提示和同步占位卡。

手动验收建议：

cd frontend
npm run build

然后在桌面和移动宽度分别检查：

切换城市后立即打开“今日日内分析”，旧城市数据不应可交互。
多日预报未补齐时，应看到同步提示，而不是只有一张“今天”卡。
full detail 到达后，占位卡自动消失。

10. 备注

这套监控现在已经具备：

外部抓取
告警规则
Telegram 推送
趋势面板
巡检脚本

但它仍是“最小可用版”，还没有覆盖：

节点级 CPU / 内存 / 磁盘
数据库体积趋势
更细粒度支付指标
按城市/来源拆分的业务 SLA
按城市拆分的前端补齐耗时与 stale-detail 告警

4.7 KiB Raw Blame History