Prometheus指标基数上限及自定义指标摄入限制咨询

Prometheus里的“高基数”没有绝对固定的阈值，它和服务器硬件配置、存储方案、查询频率等强相关，但行业内有通用的参考范围和判断标准：

1. 通用参考阈值 #

• 单指标基数（单个指标下的活跃时间序列数）：建议控制在1000以内，超过这个数值就需要警惕。如果单指标基数达到5000以上，大概率会引发性能问题，比如内存占用飙升、查询超时、写入延迟。
• 全局活跃时间序列总数：普通硬件（如8核16G内存的服务器）下，建议不超过100万条。高配硬件（16核32G以上）可放宽到200-300万，超过500万几乎必然出现严重性能瓶颈。

2. 如何判断是否“过高” #

除了看数值，更关键的是观察Prometheus的运行状态：

• 查看prometheus_tsdb_head_series指标：它记录当前内存中的活跃序列数，若持续超过硬件对应的参考值，就属于基数过高。
• 监控写入延迟：如果prometheus_tsdb_wal_fsync_duration_seconds的p95值超过100ms，说明写入压力过大，大概率是基数问题导致。
• 检查查询性能：常用的聚合查询（如sum()、avg()）若出现超时，或查询耗时超过1s，也要考虑基数是否超标。

3. 为什么没有绝对数值 #

Prometheus的性能受多因素影响：

• 硬件配置：内存越大，能承载的活跃序列数越多——因为Prometheus会把活跃序列的元数据存在内存中。
• 采样频率：采样间隔越短（比如10s一次），相同基数下的写入压力越大。
• 查询复杂度：大量高基数的聚合查询，即使序列总数不算特别多，也会拖垮性能。
• 存储后端：使用远程存储（如Thanos、Cortex）比本地TSDB能承载更多序列，但也并非无限。

4. 实际场景示例 #

比如你提到的container_image_size指标：如果K8s集群有1000个不同容器实例，每个实例带唯一的name或container标签，该指标基数为1000，属于安全范围；但如果集群有10000个实例，指标基数达到10000，就需要优化——比如去掉不必要的标签、合并多标签，或改用更粗粒度的聚合上报。

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