2. 服务器与网络基础设施监控：CPU、内存、磁盘、网络带宽监控；常用监控工具介绍（Prometheus、Grafana、Zabbix）
量化交易系统跑起来，说白了就是跟硬件较劲。你策略再牛，服务器一挂，全白搭。我见过太多团队，代码写得花里胡哨，结果半夜磁盘满了，交易直接停摆。所以这一章，咱们聊聊最基础的——服务器和网络怎么盯。
2.1 四大核心指标：CPU、内存、磁盘、网络
这四个指标，是监控的底线。任何一个出问题，系统都可能崩。我个人的习惯是，先盯死这四样，再谈别的。
2.1.1 CPU 监控
CPU 是大脑。量化交易里，CPU 高通常不是好事。尤其是回测或者实盘计算因子的时候，CPU 飙到 90% 以上，你得小心了。
- 关键指标：用户态使用率（user）、系统态使用率（system）、iowait（等待 I/O 的时间）。
- 我踩过的坑：有一次我发现 CPU 不高，但系统响应巨慢。查了半天，发现是 iowait 飙到了 40%。说白了，磁盘读写太慢，CPU 在空等。后来加了块 SSD，问题解决。
- 建议阈值：用户态长期超过 80% 要报警；iowait 超过 20% 就得查磁盘了。
2.1.2 内存监控
内存不够，系统会开始用交换分区（swap）。一旦用了 swap，性能就崩了。量化系统里，内存泄漏是常见病。
- 关键指标：已用内存、可用内存、swap 使用量。
- 避坑指南：我曾经遇到过一个策略，跑了两周后内存占用从 2G 涨到了 16G。嗯，代码里有个全局列表没清空。所以内存监控一定要看趋势，不能只看当前值。
- 建议阈值：可用内存低于总内存的 10% 报警；swap 使用量大于 0 就要警惕。
2.1.3 磁盘监控
磁盘满是最低级但最致命的错误。行情数据、日志文件，分分钟撑爆你。
- 关键指标：磁盘使用率、inode 使用率、读写延迟。
- 个人经验：我习惯把日志和行情数据分盘存储。日志盘满了，至少行情还能写。另外，inode 用完比磁盘满更隐蔽——文件太多，小文件占满 inode，df 看还有空间，但写不进文件。
- 建议阈值：磁盘使用率超过 80% 预警，超过 90% 立即处理。
2.1.4 网络带宽监控
量化交易对网络延迟极其敏感。带宽跑满，意味着你的订单可能比别人晚到几毫秒。
- 关键指标：入站流量、出站流量、丢包率、TCP 重传率。
- 我遇到过的事：有一次交易所行情推送突然变慢，我查了半天，发现是同一台服务器上有人在跑数据同步，把带宽吃满了。从那以后，我坚持交易服务器和业务服务器物理隔离。
- 建议阈值：带宽使用率超过 70% 预警；丢包率超过 0.1% 立即排查。
核心原则：监控不是看数字，是看趋势。CPU 突然从 20% 跳到 80%，比一直 80% 更可怕。
2.2 常用监控工具介绍
工具不在多，在于顺手。我这些年用过不少，最后稳定下来的就三个：Prometheus、Grafana、Zabbix。各有各的脾气。
2.2.1 Prometheus：时间序列数据库
Prometheus 是云原生时代的监控标配。它拉取数据（pull）的模式，很适合量化交易这种需要高频采样的场景。
- 优点：数据模型灵活，支持多维标签；查询语言 PromQL 很强大。
- 缺点：不适合长期存储（默认只保留 15 天）；配置稍复杂。
- 我的用法：用 Prometheus 采集 CPU、内存、磁盘等系统指标，配合 node_exporter 使用。PromQL 写个查询，比如
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)，就能拿到 CPU 使用率。
# 一个简单的 Prometheus 告警规则示例
groups:
- name: server_alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "CPU usage over 80% on {{ $labels.instance }}"2.2.2 Grafana：可视化面板
Grafana 是 Prometheus 的最佳搭档。它把枯燥的数据变成图表，一眼就能看出问题。
- 优点：图表美观，支持多种数据源；告警功能也不错。
- 缺点：本身不采集数据，需要配合其他工具。
- 个人建议：把 CPU、内存、磁盘、网络四个指标放在同一个 Dashboard 上。我习惯用折线图展示趋势，用仪表盘展示当前值。这样既能看历史，又能盯实时。
小技巧：Grafana 的告警可以发到钉钉或企业微信。我设置了一个规则：CPU 超过 80% 持续 5 分钟，就给我发消息。这样半夜出问题也能及时知道。
2.2.3 Zabbix：传统监控之王
Zabbix 是老牌监控工具，适合传统 IT 环境。它采用 agent 模式，主动上报数据。
- 优点：部署简单，自带告警和报表；支持 SNMP，可以监控网络设备。
- 缺点：界面比较老，扩展性不如 Prometheus。
- 我什么时候用 Zabbix：如果团队里都是传统运维出身，Zabbix 上手更快。我早期用过 Zabbix 监控交换机端口流量，配置起来确实方便。
| 工具 | 适用场景 | 数据采集方式 | 存储方式 | 学习成本 |
|---|---|---|---|---|
| Prometheus | 云原生、容器化、高频采样 | 拉取（Pull） | 时间序列数据库 | 中 |
| Grafana | 可视化、告警展示 | 不采集，只展示 | 依赖数据源 | 低 |
| Zabbix | 传统 IT、网络设备监控 | 推送（Push） | 关系型数据库 | 低 |
2.3 知识体系结构图
下面这张图，帮你理清服务器监控的核心逻辑。说白了，就是「采集 → 存储 → 展示 → 告警」四个环节。
注意：不要试图用一个工具解决所有问题。Prometheus 适合指标监控，Zabbix 适合设备监控。混着用，效果更好。
好了，这一章的内容就这些。记住，监控不是摆设，是救命用的。下一章咱们聊聊更细的——网络延迟和丢包怎么追根溯源。
公众号:蓝海资料掘金营，微信deep3321