InfluxDB vs Prometheus：各自适合什么场景？
Prometheus 以拉模型为主，擅长 K8s/微服务指标与告警；InfluxDB 适合 IoT 与业务时序写入，查询语言、历史数据范围和保留能力需按版本与产品核对。本文从数据模型、采集方式、查询语言、生态四维度对比并给出选型建议。
一句话选型：监控云原生基础设施与服务指标优先评估 Prometheus；IoT/传感器与业务时序数据可评估 InfluxDB。若需要 SQL 或长期历史分析，先核对具体 InfluxDB 产品的查询语言、保留与查询窗口，不能跨版本一概而论。
核心差异对比
| 维度 | Prometheus | InfluxDB |
|---|---|---|
| 采集模型 | 拉（Pull）为主 | 推（Push）为主 |
| 数据模型 | 指标名 + 标签集 | measurement + tag + field |
| 查询语言 | PromQL（代数式） | 依版本：1.x InfluxQL，2.x Flux，3.x SQL/InfluxQL（非统一 Flux/SQL） |
| 强项 | 告警、服务监控、K8s 生态 | 业务时序分析；吞吐、历史写入和保留须按版本/产品评估 |
| 事件支持 | 以指标为主，不是通用日志或文档数据库 | 可写入带字段的时间戳数据，不等于具备完整日志检索与留存流程 |
| 生态 | Grafana/Alertmanager/云原生全家桶 | Telegraf/Grafana/IoT 平台 |
典型适用场景
选 Prometheus：微服务与 K8s 监控、SLO 告警、与 Grafana 生态深度绑定、需要服务发现自动抓取。
选 InfluxDB：设备传感器每秒高频上报、金融行情、需要补录历史数据（允许的时间范围、保留策略和查询能力需按产品版本核对）、对数据做复杂分析计算。
常见问题（FAQ）
Q：两者能共存吗？ 常见组合：Prometheus 管监控告警，InfluxDB 存长期/业务时序；能否作 Prometheus 远端存储取决于 InfluxDB 产品/版本支持的 remote_write/read 接口，不能跨1/2/3版本类推。
Q：Prometheus 能推模式吗？ Pushgateway 适用于特定服务级批处理指标，不是通用采集代理；Prometheus 仍抓取网关，需清理过期系列。OTLP/remote-write 接收需对应版本和显式配置。
Q：性能谁更强？ 不能无实测地断言同量级 InfluxDB 写入更快；应按版本、基数、查询、保留和持久性要求对比。Prometheus 的抓取/告警生态与业务时序分析定位也不同。
