3、数据采集层：采集器选型与性能平衡
数据采集层，是整个监控体系的「眼睛」。
眼睛要是瞎了，后面再牛逼的告警引擎、再炫酷的看板，全是摆设。我见过太多团队，花大价钱搭了套监控系统，结果采集器没选对，数据要么丢了、要么把交易服务器搞崩了——嗯，这种坑，我踩过不止一次。
3.1 三大主流采集器对比
目前量化圈子里，用得最多的就是这三兄弟：Telegraf、Prometheus Node Exporter、StatsD。它们各有各的脾气，选型时得看你的场景。
| 采集器 | 定位 | 数据模型 | 适用场景 | 资源开销 |
|---|---|---|---|---|
| Telegraf | 全能型采集器 | 行协议（Line Protocol） | 系统指标 + 中间件 + 自定义插件 | 中等 |
| Node Exporter | Linux 系统指标专用 | Prometheus 指标格式 | 纯服务器监控 | 极低 |
| StatsD | 应用层指标聚合 | UDP 推送 + 聚合 | 业务埋点、高频计数器 | 极低（客户端） |
我的建议：别只选一个。我习惯用 Telegraf 做主力采集，Node Exporter 做系统级兜底，StatsD 只负责业务埋点。三管齐下，各司其职。
3.2 Telegraf：全能但需要调教
Telegraf 是 InfluxData 家的产品，插件生态非常丰富。CPU、内存、磁盘、网络、Docker、Kafka、Redis……基本上你能想到的，它都有现成的 input 插件。
我个人最喜欢它的地方是：配置统一。所有采集器都用 TOML 格式配置，一个 telegraf.conf 搞定所有。
# 一个典型的 Telegraf 配置片段
[[inputs.cpu]]
percpu = true
totalcpu = true
collect_cpu_time = false
interval = "10s"
[[inputs.disk]]
ignore_fs = ["tmpfs", "devtmpfs", "overlay"]
[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "quant_monitor"
但要注意，Telegraf 的插件开多了，CPU 开销会直线上升。我在项目中遇到过一个问题：开了 20 多个 input 插件，每 5 秒采集一次，结果 Telegraf 自己就吃了 15% 的 CPU。对于量化交易服务器来说，这不可接受。
避坑指南：我曾经把 Telegraf 的采集间隔设成 1 秒，结果把交易网关的磁盘 IO 打满了。后来改成 10 秒，配合缓存批量写入，才稳住。量化系统里，采集频率不是越快越好。
3.3 Node Exporter：轻量但专一
Node Exporter 是 Prometheus 生态里的「老兵」。它只做一件事——采集 Linux 系统指标，而且做得非常极致。
它的优势在于：资源开销极低。我实测过，默认配置下 Node Exporter 只占用 20-30MB 内存，CPU 使用率常年低于 1%。对于量化交易这种对性能敏感的场景，它几乎是零成本的系统监控方案。
但缺点也很明显：它只输出 Prometheus 格式的数据。如果你的监控栈不是 Prometheus 生态，就得额外搭一个 adapter 做格式转换。
# 查看 Node Exporter 暴露的指标
curl http://localhost:9100/metrics | head -20
# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78
node_cpu_seconds_total{cpu="0",mode="system"} 2345.67
小技巧：我习惯把 Node Exporter 和 Telegraf 同时部署。Node Exporter 负责基础系统指标，Telegraf 负责业务相关的中间件指标。这样即使 Telegraf 挂了，系统层面的监控也不会断。
3.4 StatsD：高频场景的利器
StatsD 的设计哲学和前面两个完全不同。它采用 UDP 推送 + 服务端聚合 的模式，客户端只管发，不管收。这意味着它对业务代码的侵入性极低，性能开销几乎可以忽略。
量化交易里，什么场景适合用 StatsD？
- 订单延迟统计：每笔订单从生成到成交的耗时
- 行情 tick 计数：每秒收到的行情条数
- 策略信号频率：策略发出买卖信号的次数
- 错误率统计：撤单失败、连接断开等异常事件
说白了，凡是需要「计数」和「计时」的高频场景，StatsD 都是最优解。
# Python 中使用 StatsD 客户端
import statsd
c = statsd.StatsClient('localhost', 8125)
# 计数器：记录订单提交次数
c.incr('order.submitted', 1)
# 计时器：记录订单处理耗时
with c.timer('order.process_time'):
process_order(order_id)
# 仪表盘：记录当前持仓数量
c.gauge('position.btc', 1.5)
注意：StatsD 默认使用 UDP 协议，数据可能丢失。对于量化交易来说，丢几个计数问题不大，但如果你需要精确的计费或审计数据，建议改用 TCP 模式或配合可靠队列使用。
3.5 采集频率与性能开销的平衡
这是整个数据采集层最核心的问题。我见过有人把采集间隔设成 100 毫秒，结果服务器 CPU 被打到 80%；也见过有人设成 5 分钟，结果告警延迟到黄花菜都凉了。
怎么平衡？我总结了一个经验公式：
采集频率 = 指标变化速度 × 容忍延迟 × 系统负载系数
举个例子：
- CPU 使用率：变化较慢，10 秒采集一次足够
- 内存使用量：变化更慢，30 秒一次都行
- 订单延迟：变化极快，需要 1 秒甚至毫秒级
- 网络丢包率：变化中等，5 秒一次比较合理
| 指标类型 | 推荐采集间隔 | 性能开销 | 说明 |
|---|---|---|---|
| CPU / 内存 / 磁盘 | 10-30 秒 | 极低 | 系统级指标，变化缓慢 |
| 网络 IO / 连接数 | 5-10 秒 | 低 | 需要一定实时性 |
| 订单延迟 / 成交率 | 1 秒或事件驱动 | 中等 | 建议用 StatsD 推送 |
| 行情 tick 频率 | 毫秒级 | 高 | 必须用专用采集器 |
血的教训：我曾经把行情 tick 的采集频率设成 10 毫秒，用 Telegraf 的 HTTP 插件去拉取。结果 Telegraf 进程的 CPU 直接飙到 60%，导致交易网关的响应时间从 50 微秒变成了 2 毫秒。后来改用 StatsD 的 UDP 推送，CPU 降到 0.5%，问题解决。
3.6 本章知识体系
下面这张图，是我自己总结的采集器选型决策流程。你照着走，基本不会出错。
这张图的核心逻辑很简单：先看你要采集什么。系统指标用 Node Exporter，业务埋点用 StatsD，其他杂七杂八的都用 Telegraf。如果预算和运维能力允许，三个一起上，互相兜底。
最后说一句：采集器选型没有银弹。我见过用 Telegraf 跑得飞起的团队，也见过只用 Node Exporter 就够用的场景。关键是你得清楚自己的量化系统对性能有多敏感，对数据完整性有多高的要求。想清楚这两点，选型就不难了。
公众号:蓝海数据掘金营，微信deep3321