时序选型看什么
时序方案的选择围绕三件事：数据怎么进、用什么语言查、长期数据放哪。Prometheus 拉取采集加 PromQL，天生与告警体系配套，本地存储面向指标保留而非海量明细；InfluxDB 推送写入，标签订索引、字段存值，自带保留策略与降采样任务；ClickHouse 用 SQL 处理高基数明细与聚合；TimescaleDB 在 Postgres 内做时序扩展，适合已有 Postgres 栈。
方案对照
| 方案 | 强项 | 边界 |
|---|---|---|
| Prometheus | 指标采集、PromQL、告警生态成熟 | 本地 TSDB 不面向长期海量明细，需要远程存储 |
| InfluxDB | 开箱即用的写入、保留策略与降采样任务 | 查询语言版本演进较大，迁移要核对语法 |
| ClickHouse | SQL、高基数明细、压缩与聚合性能 | 不自带采集与告警，需要自建管道 |
| TimescaleDB | Postgres 生态、完整 SQL、连续聚合 | 大规模写入要按超表设计分片与块 |
基本信息
| 采集方式 | 拉取（Prometheus）与推送（InfluxDB、ClickHouse 自建管道） |
|---|---|
| 查询语言 | PromQL / InfluxQL、Flux / SQL |
| 基数风险 | 标签组合数量决定索引与序列规模，无界维度是共同杀手 |
| 长期存储 | 分层保留：高精度短期、降采样长期 |
| 典型粒度 | 秒级原始精度留存数天到数周，分钟级聚合留存数月至数年 |
典型使用场景
- 云原生监控与告警：指标采集、抓取状态与告警规则用 Prometheus 体系最顺
- 设备与业务指标上报：应用侧直接推送、按业务维度管理保留期时 InfluxDB 更贴合
- 高基数明细分析：单指标带大量维度时用 ClickHouse 按 SQL 分析
- 已有 Postgres 团队：想在单一数据库里做时序与关系混合分析时选 TimescaleDB
- 混合架构：Prometheus 负责采集告警、远程写把长期数据交给专用存储
降采样思路（InfluxDB 任务示例）
降采样思路（InfluxDB 任务示例）
option task = { name: "downsample_1h", every: 1h }
from(bucket: "metrics")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
|> to(bucket: "metrics_1h", org: "ops")
// 查询侧按需求选桶：近期看原始精度，历史趋势读降采样结果分层保留是控制长期成本的关键：原始精度覆盖典型排障窗口（数天到数周），降采样数据长期保留；降采样窗口与保留周期要跟着查询需求走，而不是照搬模板。
把 Prometheus 当长期明细库使用是常见误区：本地存储按指标保留策略管理数据，扩容前先确定远程存储，否则历史数据会按保留期被清理。