Prometheus的设计前提
Prometheus自2012年开源以来成为云原生监控的事实标准，其设计前提决定了它的能力边界。数据模型基于标签（Label）组合标识时间序列：一个指标名加上一组键值对标签构成一条时间线。抓取（Pull）模型的Exporter机制、PromQL查询语言、以及本地TSDB存储引擎，构成了一套自洽的监控体系。
这一体系是面向”实例级监控”设计的。典型场景是监控数百至数千个服务实例的数十个核心指标（CPU、内存、请求延迟、QPS、错误率），标签基数（不同标签组合的数量）相对可控。当标签基数超出设计前提时，系统会面临一系列约束。
高基数标签的内存放大
Prometheus的倒排索引为每个标签值维护一条时间线，每条活跃时间线常驻内存，内存占用与时间线数量近似线性。当标签值包含高基数维度——用户ID、请求追踪ID、容器实例ID、文件路径——时间线数量呈爆炸式增长。
简化估算：一个指标若带有一个基数为10万的动态标签值，即生成10万条时间线，每条时间线约占用数KB内存，合计数百MB。若有数十个此类指标，内存占用很快触及单机上限，进程因OOM被杀死。工业场景中设备ID、测点ID天然是高基数的，测点规模动辄数万至数十万，这一矛盾尤为突出。
官方建议是避免使用高基数标签，把高基数维度放到日志系统或外部存储。但工业场景的设备标识无法移除，因为查询必须按设备维度进行。移除设备标签意味着查询能力丧失，保留则意味着内存失控。
实际内存占用还受索引结构与样本缓冲影响——时间线数量乘以每条时间线约1-2KB的基础开销，再叠加倒排索引，当时间线达到百万级时，单机内存需求可达数GB至数十GB，很容易突破单实例的内存上限。
标签维度 | 典型基数 | 内存影响 | 适配场景 |
服务名/方法名 | 十至百 | 低 | 应用监控 |
实例IP | 百至千 | 中 | 服务实例监控 |
容器实例ID | 千至万 | 高 | 编排环境 |
设备ID/测点ID | 万至十万 | 极高 | 工业测点 |
追踪ID/会话ID | 百万级 | 爆炸 | 不可用于指标 |
本地存储的生命周期约束
本地TSDB的保留期是另一个约束。默认保留期为15天，可通过--storage.tsdb.retention.time调整，但受限于本地磁盘容量。长期保留需要配置更大的本地磁盘，而单机磁盘容量存在上限。
更本质的问题是存储引擎运行在单节点，缺乏分布式扩展能力。数据量增长只能通过垂直扩展（更大内存、更快磁盘）应对，无法水平扩展。相比之下，分布式架构的时序数据库通过分片与副本机制，可以支撑PB级数据规模。
查询性能同样受生命周期影响。对近期数据（内存中的Head Block）查询快，对历史数据（磁盘上的持久Block）需要加载索引，长跨度查询的响应时间随数据量增长而恶化。工业场景中”查询某设备过去三年的运行趋势”这类需求，在本地存储上基本无法满足。
远程存储接口与适配器
为突破本地存储限制，Prometheus设计了Remote Write与Remote Read接口。采集侧通过Remote Write将数据实时推送到远程存储，查询侧通过Remote Read从远程存储读取历史数据。这一设计将采集与存储解耦，存储能力由后端实现决定。
远程存储后端的技术路线主要有三类。基于对象存储的日志型存储写入吞吐高、成本低，但查询能力受限于内存计算，高基数聚合查询性能不佳。通用时序数据库具备完整的标签索引、列式存储、聚合查询能力，适配监控指标与工业测点的双重场景。自研分布式存储灵活性最高，运维成本也最高。
Remote Write适配器是接入的关键。Prometheus按固定格式将样本（指标+标签+时间戳+值）序列化后批量推送，后端需实现对应的接收接口。适配器的写入性能、批量策略、背压处理直接决定了采集链路能否稳定支撑高基数场景。写入协议通常基于Protobuf配合Snappy压缩，单次批量约数百至数千样本，批量过小则网络往返开销占比高，批量过大则单次反序列化延迟上升。
PromQL生态与适用边界
PromQL是Prometheus生态的核心资产。告警规则、Grafana面板、ServiceMonitor配置都基于PromQL表达。放弃Prometheus采集而改用其他存储，意味着放弃这一生态资产，迁移成本不可忽略。
现实的技术路径是保留Prometheus作为采集与告警层，通过Remote Write接入具备长期存储能力的后端。查询侧通过Remote Read返回PromQL兼容的结果，Grafana面板无需改动。这一”采集用Prometheus、存储用专用库”的分层架构，既保留了生态资产，又突破了存储约束。
适用边界需要明确。Prometheus适合秒级采集、指标数量可控、保留期短、以告警为核心的监控场景。工业测点场景适合分钟级采集、高基数、长期保留、以历史分析为核心的场景。两者的交集在于”实时告警”这一共同需求，实现方式是Prometheus负责告警规则评估，时序数据库负责历史数据与聚合查询。
结语
Prometheus与工业测点监控的服务对象不同，前者面向服务可用性，后者面向设备运行状态，二者的数据特征差异决定了存储选型不能一刀切。从工程演进方向看，”Prometheus采集+专用存储”的分层架构正在成为工业场景的折中方案，它承认了单一系统难以同时满足低延迟告警与长期高基数存储的现实。TDengine实现的Remote Write接口与PromQL兼容层，为这类场景提供了一条落地路径——采集生态不变、存储能力扩展，这是比推倒重来更务实的架构迁移策略。
