一、监控体系总览：为什么需要监控？
说实话，我做了这么多年量化系统，最怕的不是策略亏钱，而是系统出问题了你还不知道。
有一次，我负责的一个高频策略跑得好好的，突然某天收益曲线开始下滑。我排查了半天，发现是交易所的行情推送延迟了200毫秒。你想想看，200毫秒对高频交易意味着什么？订单已经成交了，行情还没到。嗯，这就是典型的「系统在跑，但已经坏了」的情况。
所以，监控不是锦上添花，而是保命用的。
为什么需要监控？
量化交易系统本质上是一个「黑盒」——策略代码在跑，数据在流，但你看不到内部发生了什么。监控就是给这个黑盒装上玻璃窗。
我个人习惯把监控的目的归纳为三点：
- 发现问题：系统挂了、数据断了、延迟高了，第一时间知道
- 定位问题：出问题了，是网络、数据库、还是策略代码？
- 预防问题：通过趋势分析，在问题发生前就预警
说白了，监控就是让你从「事后救火」变成「事前预防」。
核心观点：没有监控的系统，就像闭着眼睛开车。你可能开得很稳，但一旦出事，就是大事。
监控的三大支柱：指标、日志、告警
我经常跟团队说，监控体系就三根柱子：指标（Metrics）、日志（Logs）、告警（Alerts）。缺一根，这房子就盖不稳。
1. 指标（Metrics）—— 系统的「体温计」
指标是量化的、可聚合的数据。比如：
- CPU使用率、内存占用、磁盘IO
- 订单处理延迟、成交率、撤单率
- 策略收益率、夏普比率、最大回撤
指标的特点是「轻量、高频、可聚合」。你可以用Prometheus采集，用Grafana画图。我习惯把指标分为三类：
| 指标类型 | 举例 | 采集频率 |
|---|---|---|
| 基础设施指标 | CPU、内存、网络 | 10秒一次 |
| 应用指标 | 订单延迟、队列长度 | 1秒一次 |
| 业务指标 | 盈亏、持仓、风险敞口 | 实时 |
我的经验：指标不是越多越好。我曾经在一个项目里采集了200多个指标，结果真正有用的不到20个。建议先抓核心，再逐步补充。
2. 日志（Logs）—— 系统的「黑匣子」
指标告诉你「系统出问题了」，日志告诉你「为什么出问题」。
日志是离散的、带时间戳的事件记录。比如：
- 「2024-01-15 10:23:45.678 ERROR 订单发送失败：连接超时」
- 「2024-01-15 10:23:45.679 WARN 重试第1次...」
我建议日志要遵循「结构化」原则。什么意思？就是每条日志都包含：时间戳、级别、模块、请求ID、具体信息。这样方便用ELK（Elasticsearch, Logstash, Kibana）做全文检索。
避坑指南：我曾经见过一个团队，日志里全是「error occurred」这种废话。你想想看，出错了你倒是说清楚哪里出错啊！日志一定要有上下文，比如订单ID、策略名称、错误码。
3. 告警（Alerts）—— 系统的「闹钟」
指标和日志是数据，告警是行动。告警就是在指标或日志达到阈值时，通知你。
告警设计有几个原则：
- 不要过度告警：一天发100条告警，最后你会无视所有告警
- 分级告警：P0（系统崩溃）→ 电话通知；P1（功能异常）→ 钉钉/微信；P2（性能下降）→ 邮件
- 告警要有处理建议：别只告诉「出事了」，要告诉「怎么办」
举个例子，我设计的告警规则：
# 订单延迟告警
- 规则：订单处理延迟 > 500ms，持续30秒
- 级别：P1
- 通知：钉钉群 @值班人员
- 建议：检查网络延迟、交易所API状态、本地队列堆积情况监控系统的分层架构
监控不是一锤子买卖，它需要分层。我习惯把监控分为三层：基础设施层、应用层、业务层。
下面这张图是我自己画的，你看一眼就明白了：
基础设施层
这是最底层，也是最容易监控的。说白了就是看服务器有没有宕机、网络有没有断。
常用的工具有：
- Prometheus + Node Exporter：采集CPU、内存、磁盘、网络
- Grafana：可视化展示
- Ping / TCP 探活：检测服务是否存活
我建议基础设施层的告警阈值要宽松一些。比如CPU偶尔飙到90%不用告警，持续5分钟以上才告警。否则你会被「假告警」烦死。
应用层
这一层关注的是「你的代码跑得怎么样」。比如：
- 订单从生成到发送，花了多少毫秒？
- 行情数据从接收到处理，延迟了多少？
- 数据库查询有没有慢查询？
应用层的监控需要你在代码里埋点。我习惯用Micrometer或者OpenTelemetry来做。举个例子：
// 订单处理延迟监控
Timer.Sample sample = Timer.start(registry);
try {
orderService.process(order);
} finally {
sample.stop(Timer.builder("order.process.delay")
.tag("exchange", order.getExchange())
.tag("symbol", order.getSymbol())
.register(registry));
}我的习惯：应用层的指标一定要带上标签（tag），比如交易所、品种、策略ID。这样出问题时可以快速定位到具体哪个环节。
业务层
这是最上层，也是最容易被忽视的。业务层监控的是「策略赚不赚钱」、「风险有没有失控」。
比如：
- 策略当日盈亏是否超过阈值？
- 最大回撤是否接近风控线？
- 持仓集中度是否过高？
业务层的告警往往是最严重的。因为基础设施挂了可以重启，应用层慢了可以优化，但业务层出问题，那就是真金白银的损失。
我曾经踩过的坑：有一次业务层告警没配置好，策略在回撤期持续亏损，但告警阈值设得太高，直到亏了5%才触发。从那以后，我坚持业务层告警要「宁可错杀一千，不可放过一个」——阈值设得低一点，哪怕多几个误报，也比漏报强。
小结
监控体系说白了就三件事：
- 指标：量化系统状态
- 日志：记录系统行为
- 告警：通知系统异常
再加上三层架构：基础设施层保稳定，应用层保性能，业务层保收益。这三层缺一不可。
嗯，这一章就讲到这里。记住一句话：监控不是成本，是投资。你花在监控上的每一分钟，都会在系统出问题时加倍还给你。