两种存储模型的差异
InfluxDB 与 Prometheus 都是时序数据库，但数据进入的路径完全不同：InfluxDB 由应用主动推送（line protocol），标签加字段模型里标签建立索引、字段存值；Prometheus 由服务端定时拉取，数据组织为指标名加标签集形成的序列，本地 TSDB 按时间分块并配 WAL，长期存储通常靠远程写扩展。选型时先看采集链路和生态，再看存储参数。
方案对照
| 维度 | InfluxDB | Prometheus |
|---|---|---|
| 写入方向 | 应用推送（HTTP API / 客户端库） | 服务端拉取（scrape），批处理任务走 Pushgateway |
| 数据模型 | 数据库/保留策略/measurement/tag/field | 指标名 + 标签集 = 序列，值为浮点样本 |
| 本地存储 | TSM 引擎，按保留策略与分片组管理 | 按时间分块（常见 2 小时块）+ WAL，按时间或体积保留 |
| 查询语言 | InfluxQL 与 Flux | PromQL，面向速率与聚合告警 |
| 长期存储 | 桶与保留策略，横向扩展靠集群方案 | remote_write 到远端长期存储，或联邦聚合 |
| 上手成本 | 写入模型直观，应用侧集成简单 | 采集配置与 PromQL 有学习曲线，告警生态成熟 |
基本信息
| 标签基数 | 两边都要严格控制：标签取值组合数决定索引与序列数量 |
|---|---|
| 采集断点 | Prometheus 拉取模式天然可观测采集是否失败；推送模式需要应用自己保证重试 |
| 时间精度 | InfluxDB 默认纳秒，Prometheus 样本为毫秒级时间戳 |
| 典型搭档 | InfluxDB 常用于设备与业务指标；Prometheus 常用于云原生监控与告警 |
两种写入方式对照
两种写入方式对照
InfluxDB 推送（line protocol）：
cpu,host=web-1,region=cn usage=0.73,idle=0.27 1719792000000000000
Prometheus 拉取（scrape 配置）：
scrape_configs:
- job_name: node
static_configs:
- targets: ["web-1:9100"]
# 拉取模式下的抓取状态可直接观测
# up{job="node"} == 0 表示目标抓取失败选型口诀：已有 Prometheus 生态就用远程写扩存，别重复造采集；需要应用直接写入、按业务维度灵活管理保留期时，InfluxDB 的模型更贴合。
不要把 Prometheus 本地 TSDB 当长期明细库：它的保留策略面向指标而非全量历史，扩容量之前先确定远程存储方案，否则历史数据会按保留期被删除。