4. 生产级Prometheus配置与调优
当OpenShift集群从测试环境走向生产，Prometheus面临的核心矛盾会迅速从“能不能采到指标”转变为“能不能长期稳定地采到、存下、查得动”。一个中等规模的生产集群（约200个节点、上万Pod、数千Service）每天产生的活跃时间序列可达数百万条，原始样本量在数十亿级别。如果沿用默认配置，通常在数天到数周内就会出现内存持续上涨、查询超时、甚至Prometheus OOM被重启的连锁反应。本节围绕保留策略、资源配额、远程写入、分片与联邦五个关键维度，说明如何把Prometheus从“能跑”调到“生产级稳定”。
保留策略：先算清楚容量，再决定保留多久
Prometheus本地存储的保留由两个参数共同决定：--storage.tsdb.retention.time（默认15天）和--storage.tsdb.retention.size（默认0，即不限制）。生产环境建议两者同时设置，以先到者为准，避免磁盘被写满。容量估算的粗略公式是：
磁盘占用 ≈ 活跃时间序列数 × 每样本字节数 × 采样频率 × 保留时长
其中每样本字节数经验值约 1.5～2 字节（含索引与压缩后）举例说明（以下为教学示例假设值，非实测结果）：某集群活跃序列约 300 万条，采样间隔 30 秒，按每样本 1.7 字节估算，单日样本量约为 300万 × 2880 × 1.7 ≈ 14.7 GB。若保留 15 天，本地磁盘需求约 220 GB，再预留 30% 余量，建议为 Prometheus 的 PVC 配置 300 GB。若业务要求保留 90 天，本地存储成本会迅速失控，此时应缩短本地保留（如 15 天）并配合远程写入做长期存储，而不是盲目扩大 PVC。
prometheus_tsdb_storage_blocks_bytes 和节点磁盘使用率设置告警，在达到 80% 前介入，而不是等到写满后被动清理。资源配额：给Prometheus一个明确的上限
Prometheus是内存敏感型应用，其内存占用与活跃时间序列数近似线性相关。经验上每 100 万活跃序列约需 1.5～2 GB 内存用于索引和查询缓存。生产环境应通过 resources.requests/limits 明确约束，避免它挤占同节点其他工作负载，也避免被其他负载挤占。
resources:
requests:
cpu: "2"
memory: "8Gi"
limits:
cpu: "4"
memory: "16Gi"同时要关注 --query.max-concurrency（默认20）和 --query.max-samples（默认5000万）。前者限制并发查询数，防止大查询拖垮实例；后者限制单次查询扫描的样本量，避免一个“全量聚合”查询把内存打满。对于多租户或共享查询场景，可适当下调这两个值，把资源留给采集与规则计算。
远程写入：把长期存储与本地查询解耦
远程写入（remote write）是生产级Prometheus的标准配置。它把本地采集的数据异步推送到远端存储（如 Thanos、Cortex、VictoriaMetrics 或云厂商托管服务），本地只保留短期数据用于快速查询和告警。关键调优参数包括：
queue_config.max_shards：每个远程端点的最大分片数，默认200，高吞吐场景可上调。queue_config.capacity：每个分片的缓冲样本数，默认2500，过小会导致丢样本。queue_config.max_samples_per_send：单次发送样本数，默认2000，影响网络效率。queue_config.batch_send_deadline：批量发送截止时间，默认5秒。
判断远程写入是否健康，核心看两个指标：prometheus_remote_storage_samples_failed_total（失败样本数）和 prometheus_remote_storage_queue_highest_sent_timestamp_seconds（发送延迟）。如果失败率持续上升或发送延迟不断增大，说明远端写入能力不足或网络受限，应先扩容远端，再考虑调整分片。
分片与联邦：应对超大规模集群
当单个Prometheus实例无法承载全部采集目标时，有两种主流思路：分片（sharding）和联邦（federation）。
分片是把采集目标按一定维度（如命名空间、节点、业务域）拆分到多个Prometheus实例，每个实例只负责一部分目标，从而降低单实例的序列数和内存压力。OpenShift中可通过多个Prometheus实例配合不同的 ServiceMonitor 选择器实现。分片的关键是保证目标不重叠、不遗漏，并统一远端存储，查询时由上层（如 Thanos Query）做全局聚合。
联邦则是让一个“上级”Prometheus从多个“下级”Prometheus拉取聚合后的指标（通常是 job:xxx:rate5m 这类记录规则结果），而不是原始样本。联邦适合跨集群、跨区域的全局视图，但要注意：联邦只拉取指定 match[] 的指标，且拉取间隔通常较长（如 60 秒），不适合高频告警。
调优后的验证与判断依据
完成上述配置后，不能只看“服务是否启动”，而要用指标验证效果。建议重点观察以下几项：
| 观察项 | 指标 | 健康判断 |
|---|---|---|
| 采集延迟 | prometheus_target_scrape_pool_sync_total | 持续增长，无长时间停滞 |
| 内存压力 | process_resident_memory_bytes | 稳定在 limits 的 70% 以下 |
| 远程写入失败 | prometheus_remote_storage_samples_failed_total | 增长速率接近 0 |
| TSDB 压缩 | prometheus_tsdb_compactions_failed_total | 无持续失败 |
| 查询并发 | prometheus_engine_queries_concurrent_max | 未长期打满 |
如果发现内存持续逼近 limits，优先检查是否存在高基数指标（如带 Pod UID、请求 ID 的标签），通过 relabel 丢弃或聚合；如果远程写入失败率上升，先确认远端存储的写入配额和网络带宽，再调整 max_shards 与 capacity。调优是一个“观察—调整—再观察”的循环，任何参数变更后都应至少观察一个完整的采集周期（建议 30 分钟以上）再判断是否生效。