Prometheus中非关联高基数标签是否会引发基数爆炸及计算疑问

是否会引发基数爆炸及内存问题？ #

会。当前场景下，实际生成的时间序列总数是99（无user_id的端点） + 10000（带不同user_id的/users/端点）= 10099个。如果是静态规模，对一般配置的Prometheus压力不大，但如果user_id数量持续增长（比如突破10万、100万），会快速消耗内存和存储资源——Prometheus需要为每个唯一标签组合维护独立的时间序列，每个序列都要占用内存存储元数据（标签信息）和实时样本数据，基数过大时会直接导致内存占用飙升、查询变慢，甚至服务宕机。

添加更多高基数标签会怎样？ #

风险会呈乘法级放大。如果给/users/这类端点再添加其他高基数标签（比如session_id、device_id这类取值可能达十万/百万级的标签），该端点的时间序列数会变成各高基数标签取值的乘积。比如新增一个有1000种取值的标签，/users/的序列数会变为10000*1000=1000万，加上其他99个序列，总基数直接突破千万，这会严重超出Prometheus的承载能力，引发严重性能问题甚至服务崩溃。

基数爆炸是基于潜在还是实际标签组合数？ #

Prometheus的基数计算完全基于实际上报的标签组合数，也就是你提到的99*1 + 1*10000这个数值。它不会为“理论上可能存在但从未上报”的标签组合（比如其他99个端点带上user_id的情况）分配资源。但要警惕代码逻辑漏洞：如果意外导致其他端点也带上高基数标签，潜在组合就会变成实际组合，瞬间引发基数爆炸。

内容的提问来源于stack exchange，提问作者Rach Sharp