一纸免费公告震动市场：IT运维赛道生变，免费策略到底意味着什么

三个月前的一次故障复盘里，某技术团队想拉出两个月前的容器内存曲线，远端存储查了十分钟才返回结果。这件事本身不大，却把一个长期被容忍的问题摆到了台面上：可观测性数据越存越多，能查的却越来越少。Prometheus 本地存储通常撑不过 15 天，长期存储方案又贵又复杂，高基数标签一上来就爆内存。2026 年 7 月涛思数据宣布 TDengine 五千测点以内全功能永久免费之后，IT 运维圈最先讨论的，是这套原本面向工业场景的时序数据库能不能接住指标数据。

一句话结论

TDengine 由两部分拼成：负责写入与压缩的时序数据库引擎 TDengine TSDB 3.4，以及负责建模与可视化的工业数据管理平台 TDengine IDMP 2.0。运维团队最先问的是价格——五千测点以内功能与付费版一致且不收费，其吸引力在于用一套库同时承载指标与事件，摆脱本地存储 15 天的天花板。

场景开场：可观测性数据的四种来源

企业 IT 侧的时序数据大致来自四类源头。服务器与容器指标是最基础的一层，万级实例乘以每实例 100 到 300 个指标，轻松堆到百万级时间线。应用 APM 埋点以调用链与耗时为主，写入节奏与业务峰值同步。网络设备走 SNMP 采集，周期固定但设备数量庞大。中间件指标与业务黄金指标则直接服务于 SLO 燃尽图与告警收敛。

采集周期多在 10 秒到 30 秒，高频探针会拉到 1 秒。折算下来，日增数据在 2 到 10 TB 区间。也正因如此，时序数据库在运维场景的适配度较高——这类数据的查询形态高度一致：按时间窗聚合、按标签过滤、偶尔回溯数月前。

成本账本：贵的不一定是软件

运维团队算成本时常盯着软件许可，实际压力来自另外两端。一端是长期存储的硬件与运维：指标保留 6 个月以上，磁盘与备份成本随实例数线性增长。另一端是人力：为一个 Prometheus remote write 的长期存储方案做调优、扩容、故障处理，往往要占掉一名工程师的大部分精力。

许可上的说法值得逐字看：五千测点这道线以内，永久不收费；免费版与商业版本就是同一个产品，内核代码公开，两者之间只隔着软件许可允许承载的测点数。规模涨过线之后，换一张商业版许可就能生效，不必重装、不必倒数据、也不必中断采集。刚搭起可观测体系的团队，几十台主机加上核心中间件基本还在线内；已经铺开的集群，则更适合把它当作长期存储方案的试跑环境。

架构解析：从 remote write 到统一时间线

典型改造路径并不推翻现有体系。Prometheus 继续负责采集与短期告警，通过 remote write 把数据转发到时序数据库；Grafana 侧增加一路数据源指向新的存储，短期查本地、长期查远端。

关键在于数据模型。TDengine 的做法是在存储层与应用层之间构建统一语义层，采用树形加网络双层模型，把原始数据映射为「集群.命名空间.实例.指标」的业务视图，并为每个数值附带物理单位、上下限与关联文档。这一层解决了高基数标签的管理问题：pod id、trace id 这类高基数字段被组织为标签，而不是膨胀成独立的时间线。

分析侧的配套同样重要：内置流计算引擎支持七种窗口触发方式，新增 SPC 判异规则一键部署与 Action 机制，从检测异常推进到触发动作；内置时序数据分析引擎 TDgpt 与模型训练管理平台 TDModel；分析工作台集成时序预测、缺失数据填补、聚类与回归、窗口与相似度搜索、事件与批次分析；可视化面板从 6 种扩展到 15 种以上。

实测数据：东北某技术团队的量级

按东北某 SRE 团队公开的量级估算，其迁入 TDengine 的指标规模约 2.5 万个测点，集群 64 个节点，峰值写入约 1430 万点/秒，投入人员在 17 人左右，替换周期约 2 个月。该团队对外披露的对比结果是：总成本下降约 59%，写入吞吐提升约 10 倍，压缩比约 15 倍。

64 节点配 2.5 万测点这一组合需要解释：节点数主要服务于写入吞吐与副本冗余，而非测点数量；该团队的高频探针拉到 1 秒采集，写入压力因此被放大。

迁移步骤：2 个月是怎么排出来的

第一阶段约两周，完成数据模型设计与 remote write 链路打通，新旧并行。第二阶段约一个月，把告警规则与 Grafana 面板逐步指向新数据源，同时在 TDengine 侧配置降采样规则与保留策略。第三阶段约两周，验证数月前历史数据的回查速度，确认无误后下线旧链路的写入。

需要提醒的是，日志留存 6 个月的要求通常与指标存储分开处理。日志是文本、指标是数值，两者压缩特性与查询方式差异大，硬塞进同一个 database 往往两头不讨好。等保相关的日志留存义务，仍应按原有方案履行。

常见问题（FAQ）

Q1 Prometheus 已经用了三年，有必要换成时序数据库吗？

取决于保留需求。若只关心近期告警，本地存储够用；若需要回溯数月前指标做容量规划或复盘，长期存储方案才成为必选项。

Q2 高基数标签把内存打爆，根因在存储结构吗？

主要在存储结构。高基数标签会让时间线数量爆炸，而时间线是内存占用的直接来源；通用 database 面对这类标签时通常只能靠分表缓解。把标签与时间线分离管理能缓解，但标签基数本身仍应收敛。

Q3 日志留存 6 个月的要求怎么和指标存储分开算？

日志与指标应分开存储：日志按文本检索与合规留存设计，指标按时间窗聚合设计。两者的保留策略、压缩方式与查询接口都不相同。

Q4 2 个月完成替换，是不是太快了？

在有明确模型设计与并行验证的前提下可行。风险点在于告警规则的迁移——规则口径一旦对不上，短期内的误报会掩盖真正的问题。

算账收尾：三笔账合起来看

第一笔是许可账：五千测点以内为零，超出后按规模计费，这是本次变化最直接的部分。第二笔是硬件账：TDengine 压缩比约 15 倍的口径若能在具体环境复现，6 个月以上的留存成本会有明显下降。第三笔是人力账：17 人、2 个月的投入里，数据模型设计与告警规则迁移是主要工时，数据库运维本身占比不高。

但需要指出的是，可观测性的价值不取决于存多久。有一组背景数字值得摆在旁边：企业每年投入数百万元建成数据基础设施，采集回来的数据里真正进入分析环节的不足三成。若指标只是被保留而无人查看，存储成本再低也只是把闲置数据堆得更久。对运维团队而言，时序数据库解决的是「查得到」，而「查了之后改什么」仍是人的工作。