4. 内存资源优化：减少内存使用的策略

Prometheus 的内存占用主要来自时序数据的存储与索引。本章聚焦三个核心杠杆：chunk 大小、内存块保留时间和Label 基数。通过调整这些参数，可以在不显著牺牲查询性能的前提下，将内存消耗降低 30%~60%。

4.1 降低 Chunk 大小

Chunk 是 Prometheus 存储引擎中压缩时序数据的基本单位。默认每个 chunk 最多存储 120 个样本（约 2 分钟，15s 间隔）。较大的 chunk 压缩率更高，但会占用更多内存；较小的 chunk 释放内存更快，但会增加索引开销。

# 启动参数示例：激进内存优化配置
--storage.tsdb.max-chunks-per-series=15000
--storage.tsdb.chunk-range=1h
--storage.tsdb.chunk-interval=2m

4.2 调整内存块保留时间

Prometheus 将最近的数据保存在内存中，定期写入磁盘。通过 storage.tsdb.retention.time 控制数据在内存中的保留时长。缩短该时间可以显著降低内存峰值，但会减少近期数据的查询可用性。

# 内存优化配置示例
--storage.tsdb.retention.time=3d
--storage.tsdb.retention.size=50GB

4.3 优化 Label 基数

Label 基数是影响 Prometheus 内存使用的最大隐性因素。每个唯一的 label 组合都会在内存中创建一条时序。高基数 label（如 user_id、request_id、pod）会导致内存爆炸。

4.3.1 基数评估方法

• PromQL 查询：count by (__name__) ({__name__=~".+"}) 查看每个指标的总时序数
• TSDB 状态页面：/tsdb-status 提供 label 对基数排名
• Promtool 分析：promtool tsdb analyze 输出高基数 label 列表

4.3.2 基数控制策略

# relabel_config 示例：删除高基数 label
scrape_configs:
  - job_name: 'kubernetes-pods'
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: '.*'
        action: keep
      - source_labels: [container_id]
        regex: '.+'
        action: drop       # 删除 container_id label

4.4 内存优化综合策略图

下图展示了三种优化策略的协同关系与实施优先级。建议按照“先降基数 → 再调 chunk → 最后缩保留”的顺序逐步推进。

4.5 内存优化前后对比

以下表格汇总了典型场景下三种策略的优化效果。实际收益取决于集群规模、指标基数和工作负载特征。

4.6 监控优化效果

优化后应持续监控以下指标，确保内存确实下降且系统稳定：

• process_resident_memory_bytes — Prometheus 进程实际内存
• prometheus_tsdb_memory_bytes — TSDB 内存使用细分
• prometheus_tsdb_head_chunks — 内存中 chunk 数量
• prometheus_tsdb_head_series — 内存中时序数
• prometheus_engine_query_duration_seconds — 查询延迟变化

# 快速检查内存优化效果的 PromQL
# 内存使用率
rate(process_resident_memory_bytes[5m]) / on(instance) node_memory_MemTotal_bytes

# 时序数变化
prometheus_tsdb_head_series

# chunk 数量
prometheus_tsdb_head_chunks