可观测性：Prometheus 与 Grafana 在 EasyQuant 中的用法
很多量化系统在“能跑起来”之后，会遇到一个现实问题：
你不知道它是否在稳定运行，也不知道它为什么突然不工作。
在交付视角里，可观测性不是锦上添花，而是系统从 demo 走向日常运行的门槛。
结论先行：EasyQuant 的可观测性重点不在“监控 CPU/内存”，而在“监控业务链路是否可交付”：数据新鲜度、策略评估节奏、阻塞原因、拒单原因、回测与执行的关键行为统计。
一、你应该监控什么：从“资源”转向“链路”
资源监控（CPU/内存/磁盘）很重要，但它解决不了量化团队最常问的三句话：
- 为什么今天没成交？
- 为什么策略看起来在跑，但没有评估？
- 为什么回测突然变慢/结果变了？
因此，平台级监控建议按链路组织：
- 数据链路：tick/bars 是否持续更新？是否滞后？是否缺口？
- 策略链路：是否在评估？评估频率是否异常？是否被去重跳过？
- 执行链路：下单、成交、拒单的分布与原因
- 回测链路：回测任务吞吐、耗时、失败原因、数据读取量
- 诊断与解释：Blocking Reasons Top、趋势、突变
二、Prometheus 在 EasyQuant 里怎么用（最小闭环）
最小闭环的目标：让你能在 5 分钟内确认系统是否“可交付运行”。
推荐的验证顺序：
- 后端健康检查：
/actuator/health必须UP - Prometheus 抓取：
/actuator/prometheus可访问并有指标 - Grafana（可选）：能看到基础面板与核心业务指标
在 Docker Compose 环境下，关键是让 Prometheus 能稳定发现后端服务（service name/port/metrics_path 正确）。
三、建议的关键指标（按你最常排障的问题来）
下面是“工程最有用”的指标建议（不追求铺天盖地，而追求能解决问题）：
1）数据新鲜度（Data Freshness）
要能回答：
- 最新 tick/bars 的时间戳是多少？
- 滞后了多久？
- 某个 code 是否长期无更新？
告警建议
- bars 滞后超过阈值（例如 10 分钟）触发告警
- tick 长期无数据且系统仍在交易时段触发告警
2）评估与去重（Evaluation / Dedup）
要能回答：
- 策略是否在评估？每分钟评估次数是否合理？
- DUP_EVAL_SKIPPED 是否异常升高（表明调度重复或 bars ts 未更新）？
告警建议
- 策略 enabled，但评估次数持续为 0
- 去重跳过次数突增
3）Blocking Reasons（可解释性指标化）
把 03 的可解释体系变成可观测对象：
- NO_SYMBOLS / NO_BARS / SIGNAL_NONE / ENGINE_ERROR 等原因码的计数与趋势
- Top 原因的突变（例如 NO_BARS 突然成为 Top1）
告警建议
- ENGINE_ERROR 突增（可能是 DSL/指标升级引入问题）
- NO_BARS 持续为 Top（数据链路故障）
4）执行拒绝（Risk/Broker Rejections）
要能回答：
- 风控拒绝与通道拒绝的比例是多少？
- 哪类拒绝是系统性问题（比如参数校验/额度过小/数据质量）？
告警建议
- RISK_REJECTED 占比持续升高（可能是风控口径不匹配或策略变得过激）
- BROKER_REJECTED 突增（可能是通道校验规则变化或价格异常）
5）回测吞吐与失败率（Backtest Throughput）
要能回答：
- 回测任务平均耗时、P95 耗时是否恶化？
- 失败原因分布（数据不足？引擎错误？）
告警建议
- 回测失败率超过阈值
- P95 耗时突增（可能是数据查询/索引/容量问题）
四、Grafana 面板怎么设计：按“问题”组织，而不是按“模块”堆图
推荐三张核心面板即可覆盖 80% 排障：
- 系统交付健康面板（大盘）
- 数据新鲜度、评估次数、阻塞原因 Top、拒单 Top、回测任务状态
- 数据链路面板
- tick/bars 摄入速率、滞后、缺口、按 marketId/code 维度切片
- 策略交付面板
- 各策略评估频率、阻塞原因趋势、订单与拒绝分布
这三张面板的目标是：
让你不进日志就能把问题收敛到“数据/策略/执行/引擎”之一。
五、一个验收：从“没成交”到“10 分钟定位原因”
你可以用一个实际场景验收可观测性是否到位：
场景：今天某策略没有成交。
验收路径：
- 大盘看数据新鲜度是否异常（bars/tick 是否滞后）
- 看策略评估次数是否为 0 或异常低
- 看 Blocking Reasons Top 是否显示 NO_SYMBOLS/NO_BARS/ENGINE_ERROR
- 若有下单意图，看拒单原因 Top（RISK_REJECTED/BROKER_REJECTED）
如果这条路径能在 10 分钟内收敛原因，而不是“先去翻日志”，说明系统具备交付级可观测性。
结语：可观测性是“交付能力”的外化
当你能把阻塞原因、拒单原因、数据新鲜度这些“交付关键变量”指标化，
系统才可能长期稳定运行，团队才可能持续迭代而不是持续救火。
下一篇（12）我们会讲 Mock 与对外交付：如何在没有外部行情订阅的情况下，也能稳定跑通闭环（演示数据、最小数据集、回归策略）。