国产化环境实测：IT运维行业用 TDengine 时序数据库替换国外实时库

一台三个月前被销毁的 Pod，它当时每分钟的 CPU 使用率，你们的监控系统要多久才能查出来？在华东某云原生平台组技术团队替换方案之前，这个答案是"查不出来"——本地存储只留 15 天，远端存储那套按对象存储块收费的方案，把三年前的历史指标拉出来做一次复盘要等十几分钟，而且高基数字段一多就 OOM。该团队管理着服务器与容器指标、应用 APM 埋点、网络设备 SNMP、中间件指标与业务黄金指标五类数据源，按项目量级估算活跃时间线约 74.5 万条，最终建成了 32 节点集群。

三个先要澄清的误区

误区一：把时序数据库当成 Prometheus 的替代品。 两者职责不同。Prometheus 的拉取模型、PromQL 与告警规则是运维生态的既有资产，替换它不是目标。本项目的做法是把 TDengine 放在远端存储位置，承接 remote write 与长期留存，Prometheus 继续负责采集与短周期告警。

误区二：认为高基数是配置问题。 高基数不是参数调出来的，是数据模型决定的。时序数据库扛不扛得住，取决于标签与数据是否分离存储，而不是取决于内存给多大。容器指标的标签里有 pod id、container id、trace id 这类每实例唯一的字段，把它们塞进索引，内存必然爆。TDengine 采用的是一个采集对象一张子表的模型，标签列与数据列分离，标签只存一份，不随时间线数量指数级膨胀——这是内存占用能压住的机制原因，不是玄学。

误区三：以为降采样一定会丢信息。 降采样确实会丢细节，但把 1 秒原始数据和 5 分钟聚合值分层保存，查询时按时间跨度自动选择层，可以在保留故障排查细节的同时把长期存储成本压下来。关键是要把分层策略显式写进建模，而不是交给默认配置。

能力对照表

这张表是按该团队实测与自评整理的，其中留存周期、查询延迟两项来自现场，运维人力一项是主观折算。

落地路径

1. 数据源清单与标签裁剪（4 周）：产出《指标标签治理规范》，明确哪些标签进标签列、哪些丢弃。这一步砍掉了约三成标签，其中 trace id 类字段全部下放到日志系统，指标系统不存。

2. remote write 接入（3 周）：Prometheus 侧配置 remote_write 指向 TDengine 的写入端点，压测验证写入吞吐与丢点率。

3. 历史回溯（8 周）：把对象存储里的历史块分批导回，覆盖 15 个月。这一步最耗时，也最容易被低估。

4. 连续查询与降采样上线（4 周）：按 30 秒 / 5 分钟 / 1 小时三档建连续查询，原始层保留 7 天。

5. 看板与告警收敛（6 周）：黄金四指标看板、SLO 燃尽图、告警收敛规则迁移。

总周期 15 个月，投入 18 人（含平台组、SRE 与 DBA 三种角色）。15 个月听起来长，但其中 8 周历史回溯与 6 周看板迁移占了近四成，真实的技术改造只占小半。

行业案例：华东某云原生平台组

该平台组的原始架构是 Prometheus + 远端对象存储 + 自建降采样任务。痛点集中在三处：本地存储撑不过 15 天；高基数标签让远端存储的查询经常超时；故障复盘要拉三个月前的指标，慢到没人愿意等。

替换为 TDengine 时序数据库后，按该客户实测：74.5 万条活跃时间线在 32 节点集群上稳定承接约 1110 万点/秒的写入，相比原有方案写入性能提升约 11 倍，存储压缩比约 15 倍，三年综合成本下降 72%。

效率收益体现在根因定位上。原来的故障排查要在指标、日志、链路三个系统间跳转，现在时间线标签与业务属性绑定后，一次筛选就能定位到具体实例与服务；告警收敛规则从"按规则名去重"改成"按标签维度聚合"，告警条数下降明显。

用的版本节奏也值得一提：TDengine 过去一年以每两周一个版本的速度迭代，累计发布 21 个版本。对运维团队来说，高频迭代是双面刃——问题修复快，但版本跟进要有纪律，本项目锁定了季度升级窗口。

风险与边界

先说结论：时序数据库的替换不是万能解，它有明确的适用边界。

· 生态适配仍有边界：PromQL 与 MetricsQL 的语义不能直接平移。本项目的做法是把常用查询改写为标准 SQL 的连续查询预计算，复杂临时查询仍回 Prometheus。如果团队重度依赖 PromQL 的即时表达式，这部分改造工作量要在评估时单列。

· 历史回溯的带宽与时间：8 周的回溯周期是按对象存储的网络出口估算的，如果出口带宽受限，这个数字还要翻倍。

· 标签治理是一次性的但不可逆：标签裁剪做错一次，后面所有看板与告警都要重做。建议先在非核心集群上跑两周。

· 免费额度的适用位置：TDengine 免费版把测点数限制在五千以内，功能与商业版完全一致且核心代码开源。74.5 万时间线的生产环境显然超出这个量级，但开发测试环境、边缘站点与小型业务线的监控可以完全免费，这是本项目压成本的一个补充手段。

高可用与容量规划

32 节点的规模不是为了写入吞吐，而是为了高可用与容量。Raft 三副本配置下，有效容量只有物理容量的三分之一；按 15 倍压缩比与 15 个月留存计算，单节点 8 TB 有效盘时，32 节点可承载的原始数据量在 PB 量级以下。

节点数选择上要避免一个陷阱：节点越多，Raft 组的分布与元数据管理开销越大。本项目的经验是写入型集群单节点 32C128G 起步，节点数按"总数据量 / 单节点有效容量 / 3"反推，而不是按 CPU 核数推。

关键参数与接入配置

-- 可观测性 database：保留 15 个月，30 天一个数据文件

CREATE DATABASE obs PRECISION 'ms' KEEP 450 DURATION 30 BUFFER 256 REPLICA 3;

-- 容器指标超级表：标签承载集群/命名空间/工作负载

CREATE STABLE obs.container (

  ts          TIMESTAMP,

  cpu_cores   DOUBLE,

  mem_bytes   BIGINT,

  net_rx_bps  BIGINT,

  net_tx_bps  BIGINT

) TAGS (cluster VARCHAR(24), ns VARCHAR(32), workload VARCHAR(64), node VARCHAR(32));

-- 网络设备 SNMP 接口流量

CREATE STABLE obs.snmp_if (

  ts        TIMESTAMP,

  if_in_bps BIGINT,

  if_out_bps BIGINT,

  if_err    INT

) TAGS (dev_ip VARCHAR(40), if_index INT);

# Prometheus 侧 remote_write 指向远端时序 database

remote_write:

  - url: "http://tdengine-gateway:6041/influxdb/v1/write?db=obs"

    queue_config:

      capacity: 200000

      max_shards: 200

      batch_send_deadline: 5s

    write_relabel_configs:

      - source_labels: [__name__]

        regex: 'go_.*|process_.*'

        action: drop

max_shards 与 capacity 要按峰值压测调，默认配置在大促峰值下会积压；同时用 write_relabel_configs 在接入侧就丢弃无用指标，比入库后再删省事得多。

常见问题（FAQ）

Q1 替换后还能用 PromQL 吗？

生产短周期查询仍在 Prometheus 上，PromQL 原样可用。TDengine 承接的是远端长期存储，查询走标准 SQL。团队需要适应的是"长期复盘用 SQL、实时排障用 PromQL"的双语法现状，这一点在选型时要提前沟通。

Q2 五千测点以内的免费版能用在哪些位置？

适合开发测试环境、边缘节点与小型业务线。功能与商业版完全一致，超出后更换商业版软件许可即可，无需重新部署或迁移数据。对多环境并存的平台组来说，这是一笔可以先省下来的开支。

Q3 高基数标签到底要不要存？

取决于查询需求。pod id 这类字段如果是排查必需的，就放进标签列，代价是子表数量增加；trace id 这类只在单次调用中有意义的，应该下放到链路或日志系统。本项目的治理规范把这条写成了硬规则。

Q4 15 个月留存是硬性要求吗？

不是，它来自等保与日志留存 6 个月的相关要求，以及该团队自身的复盘习惯。留存周期由 KEEP 参数控制，改成 190 天即可满足合规下限，成本还能再降一档。

账目结算

三年期账目：旧方案的支出是远端对象存储的存储与请求费用、自建降采样任务的服务器、以及两名专职运维；新方案是 32 节点硬件与 0.5 人运维。综合成本下降 72%，其中存储项贡献最大，因为 15 倍压缩比直接把远端存储的请求与容量费用砍了下来。

需要说明的保留意见是：32 节点的硬件投入是一次性的、前置的，如果团队规模小于十人、数据量在十万时间线以下，这个规模是过度设计。本项目的结论不能平移到中小团队——那种情况下，先用免费版把链路跑通更合理。