4. 指标存储选型

选存储，说白了就是选你家监控系统的「粮仓」。粮仓建不好，后面告警、排查全得抓瞎。

我这些年见过太多团队，上来就拍脑袋选 Prometheus，结果业务一扩张，查询慢得像蜗牛；也有人迷信 InfluxDB 的写入性能，结果数据丢了都不知道。今天咱们就把这几个主流方案掰开揉碎，看看它们到底适合什么场景。

4.1 三大存储引擎的核心差异

先看一张总览图，把三者的定位搞清楚。

4.2 Prometheus：拉模式的代表

Prometheus 是我用得最多的方案。它的核心思路是「服务端主动去拉」，而不是等数据送上门。

为什么拉模式好？

• 健康检查天然自带：如果某个目标挂了，Prometheus 拉不到数据，立刻就能发现。推模式下，服务挂了只是不发数据，你很难区分是没数据还是真挂了。
• 配置即服务发现：配合 Consul、K8s 的自动发现，新服务上线自动加入监控，下线自动移除。
• 查询语言强大：PromQL 写聚合、预测、异常检测非常顺手。

Prometheus 的短板也很明显：

• 不支持集群，高可用要靠 Thanos 或 VictoriaMetrics 扩展。
• 长期存储能力弱，默认只保留 15 天。
• 拉模式对网络有要求，目标必须能被 Prometheus 访问到。

4.3 InfluxDB：推模式的王者

InfluxDB 走的是「客户端主动推」的路线。你想想看，IoT 设备、传感器、短生命周期的容器任务，Prometheus 根本来不及拉，数据就没了。这时候推模式就派上用场了。

InfluxDB 的亮点：

• 写入性能极强：单机每秒能处理几十万条数据点。
• 数据压缩率高：同样的数据量，磁盘占用比 Prometheus 少 30%-50%。
• Flux 查询语言：虽然学习曲线陡，但处理复杂的时间序列计算很灵活。

InfluxDB 的不足：

• 集群版是商业产品，开源版只能单机。
• 推模式容易丢数据——客户端挂了或者网络闪断，数据就没了。
• 查询语法变化大，1.x 到 2.x 的迁移成本不低。

4.4 Elasticsearch：日志与指标的混合体

Elasticsearch 本来不是为时序数据设计的，但它的 ELK 生态太强了。很多团队把指标也塞进 ES，图的就是「日志和指标在一个地方查」。

什么时候该用 ES？

• 你需要同时查日志和指标，比如「查过去 5 分钟所有 5xx 错误的请求，并看对应的 CPU 使用率」。
• 你的指标带有大量文本标签，需要全文检索。
• 你已经有了 ELK 集群，不想再维护一套新系统。

ES 的时序痛点：

• 写入放大严重，每个文档都要建索引。
• 存储成本高，同样的数据量，磁盘占用是 InfluxDB 的 3-5 倍。
• 查询延迟不稳定，高并发下容易抖动。

4.5 选型对比表

4.6 我的选型建议

说实话，没有银弹。我一般按这个思路来：

1. 先看数据源：如果是 K8s 或微服务，无脑 Prometheus。如果是 IoT 设备，InfluxDB 更合适。
2. 再看查询需求：需要全文检索？上 ES。只需要聚合和告警？Prometheus 就够了。
3. 最后看团队能力：团队熟悉 SQL？InfluxDB 的 Flux 有 SQL 影子。团队熟悉 PromQL？那就别折腾了。