文档中心

托管 Prometheus

Prometheus 数据采集与接入

开源 Prometheus 的 Agent 模式性能优化最佳实践

在容器服务（VKE）或自建 Kubernetes 集群中，可根据集群规模、数据写入链路及运维复杂度选择合适的监控指标采集方式。本文介绍使用开源 Prometheus 的 Agent 模式采集监控指标并写入 VMP 时，如何从优化参数配置、写入前标识和过滤指标数据、降压与缓冲三个方面提升该模式的性能。

优化参数配置

可参考本节内容优化 Prometheus Agent 的 remote_write 配置。参数及说明如下：

参数	作用与说明	调整思路
capacity	每个分片的内存队列容量。默认值：10000。	建议设置为 max_samples_per_send 的 3～10 倍。设置过低容易导致队列阻塞，设置过高则会增加内存消耗。
min_shards	启动时使用的最小分片数。默认值：1。	对于流量稳定的场景，可适当调高此值以避免启动初期的性能爬坡和潜在的数据积压。
max_shards	允许的最大分片数。默认值：1000。	关键的吞吐量控制参数。远端接收能力较强时，可保持默认值或适当调高；远端限流或性能不足时，应降低此值以减少并发压力。
max_samples_per_send	单次发送请求包含的最大样本数。默认值：2000。	与远端存储的 API 兼容性有关。增大此值可减少请求数，提高发送效率，但可能增加单次请求的延迟和内存占用。
batch_send_deadline	队列未满时的最长等待时间。默认值：5s。	对于数据量较小的环境，可以适当增大此值以将更多样本聚合至单次请求中，提高网络传输效率。
min_backoff	重试前的最小等待时间。默认值：30ms。	远端服务恢复期间，适当增大此值会分散重试请求，避免“惊群效应”。
max_backoff	重试前的最大等待时间。默认值：5s。	最长重试间隔。网络抖动频繁时可适当增大此值，为远端服务预留更长的恢复时间。
remote_timeout	发送请求的超时时间，位于 remote_write 的顶层。默认值：30s。	建议设置为大于网络延迟和远端处理时间的合理值。远端响应较慢时，应适当调高。

按采集规模选择初始配置

根据每秒样本数（即 sps）选择对应的 queue_config 初始配置。该配置用于使发送并发、队列容量和批次大小与当前采集规模匹配，后续可根据运行状态继续调整。

小型规模：≤ 1k sps
中型规模：5k–20k sps
大型规模：≥ 50k sps
采集规模不超过 1k sps 时，可使用以下配置作为初始值，以降低内存占用和发送并发。使用默认值（即 capacity: 10000、max_samples_per_send: 2000）时，每个分片的内存占用通常小于 2 MB，总内存峰值约等于：max_shards * 单个分片内存。
参考配置：

# queue_config for small scale
capacity: 5000
min_shards: 1
max_shards: 10
max_samples_per_send: 1000
batch_send_deadline: 10s
min_backoff: 100ms
max_backoff: 10s

调整思路：
降低 capacity 和 max_shards，节省内存。
增大 batch_send_deadline，聚合更多样本，提升发送效率。
采集规模为 5k–20k sps 时，可先使用接近默认值的配置，并观察分片数和样本积压情况。观察结果可用于判断发送并发是否接近上限，或远端接收能力是否不足。
参考配置：

# queue_config for medium scale (close to default)
capacity: 10000
min_shards: 1
max_shards: 100 # 可根据后端能力适当降低
max_samples_per_send: 2000
batch_send_deadline: 5s
min_backoff: 30ms
max_backoff: 5s

调整思路：
重点监控 prometheus_remote_storage_shards 指标。
如果分片数持续接近 max_shards 且 samples_pending 仍在增加，考虑是远端限流或性能不足，应降低 max_shards 以减少并发压力。
采集规模达到 50k sps 以上时，建议提高队列容量、最小分片数和单次发送样本数，并确认远端能够承受对应并发。
参考配置：

# queue_config for large scale
capacity: 20000
min_shards: 5
max_shards: 500 # 需确保远端能承受此并发
max_samples_per_send: 2500
batch_send_deadline: 2s
min_backoff: 30ms
max_backoff: 2s

调整思路：
增大 capacity 和 max_samples_per_send，匹配高吞吐。
提高 min_shards，以快速启动。
降低 batch_send_deadline 和 max_backoff，以加快数据发送和异常恢复速度。

写入前标识和过滤指标数据

使用 external_labels 标识数据来源

在 global 配置块下使用 external_labels，可以为从该 Agent 发出的所有时间序列附加固定标签，例如集群名称、地域、环境等。多个集群、地域或环境的数据写入同一远端时，可通过这些标签区分指标来源。

global:
external_labels:
cluster: 'xxxxx'
prometheus: 'prometheus-agent'

使用 write_relabel_configs 过滤指标

write_relabel_configs 是 remote_write 下的配置，可以在数据发送前，基于标签对时序数据进行过滤、重塑和修改。该配置可用于保留关键指标或丢弃低价值指标，控制进入远端存储的数据范围。

write_relabel_configs:
# 只保留 up 和 app_开头的指标
- source_labels: [__name__]
regex: 'up|app_.*'
action: keep
# 丢弃所有来自 debug 命名空间的指标
- source_labels: [kubernetes_namespace]
regex: 'debug'
action: drop

修改或重命名标签

可使用 labelmap 或 replace 统一标签名称，或修复不规范的标签值，减少不一致标签进入远端存储。

write_relabel_configs:
# 将所有以 __meta_kubernetes_pod_label_ 开头的标签，替换为 pod_ 开头
- regex: __meta_kubernetes_pod_label_(.+)
replacement: 'pod_$1'
action: labelmap

移除高基数标签

建议尽量避免使用具有无限或极大可能取值的标签，例如 id、uuid、email、session。此类标签会增加时序数量，可能增加远端存储成本和查询复杂度。您可以在 write_relabel_configs 中使用 action: labeldrop 或 action: drop 规则移除高基数标签。

降压与缓冲

处理远端限流或过载

当远端出现 HTTP 429 限流或 HTTP 5xx 过载时，推荐调整以下参数：

降低 max_shards：减少并发请求数，降低远端写入压力。

提高 batch_send_deadline：延长本地等待时间，聚合更多样本后再发送，降低请求频率。

增大 min_backoff / max_backoff：延长重试间隔，为远端恢复预留更多时间。

预防远端持续不可用时的数据丢失

Prometheus Agent 将待发送数据缓存在 WAL 中，该缓冲区通常对应约 2 小时的数据量。若远端存储持续不可用超过 2 小时，最旧的数据将被丢弃，造成永久丢失，为避免数据丢失，建议提前采取以下措施：

HA 部署：至少部署两个 Agent 实例（副本），抓取相同的 Targets。

持久化卷：确保 Agent 使用 PV，防止 Pod 意外重启造成 WAL 丢失。

多路写入：配置多个 remote_write 入口，将数据同时写入两个或多个独立的远端存储系统，实现更高级别的数据冗余。

常见故障与定位

完成 remote_write 配置后，建议您通过 prometheus_remote_storage_* 指标观察写入状态，以判断是否存在样本积压、发送失败、分片数接近上限、发送延迟升高或重试增加等问题。下表涵盖关键 prometheus_remote_storage_* 指标及含义，帮助您快速定位写入链路的异常现象。

指标	含义	典型告警阈值示例
prometheus_remote_storage_samples_pending	待发送到远端的样本总数。这是衡量积压的核心指标。	> 100000，且持续 5 分钟以上。阈值应根据实际采集规模适当调整。
rate(prometheus_remote_storage_failed_samples_total[5m])	过去 5 分钟内发送失败的样本速率。	> 0，且持续 5 分钟以上。出现任何持续性发送失败时，均需立即排查原因。
prometheus_remote_storage_shards	当前活跃的分片数。	>= max_shards * 0.9，且持续 15 分钟以上。表明并发数已接近上限，存在数据积压风险。
histogram_quantile(0.99, rate(prometheus_remote_storage_sent_batch_duration_seconds_bucket[5m]))	P99 的批次发送延迟。	> remote_timeout * 0.8。表明单次批次发送耗时已接近超时阈值，可能导致大量重试。
rate(prometheus_remote_storage_retried_samples_total[5m])	重试样本的速率。	> rate(prometheus_remote_storage_succeeded_samples_total[5m]) * 0.1。表明重试频率过高。
time() - prometheus_remote_storage_queue_highest_sent_timestamp_seconds	当前写入指标延迟。	> 4*scrape_interval。表明写入的数据与当前时间数据的差距过大，已发生多轮数据积压。

排查队列积压（pending samples 持续增长时）：

检查 prometheus_remote_storage_shards 是否已达到 max_shards。

查看 sent_batch_duration 是否过高，判断是网络延迟还是远端处理慢。

查看 Agent 日志，检查是否有大量 HTTP 429、HTTP 5xx 错误码，或 context deadline exceeded 超时。

如果是后端问题，按降压策略调整 queue_config。

排查内存升高：

确认是否由分片数过多引起，特别是在数据积压时，shards 会自动扩容至 max_shards。

检查 prometheus_tsdb_head_series，确认是否由高基数 Target 导致。

降低 max_shards，可以快速控制内存增长。

排查证书或鉴权问题：

查看 Agent 日志，通常会有明确的 certificate signed by unknown authority 或 authorization failed 等 TLS / Auth 错误。

检查 tls_config 和 authorization（例如 bearer_token_file）配置是否正确。

检查证书是否存在且权限正常。

最近更新时间：2026.07.20 10:16:54

这个页面对您有帮助吗？

有用

无用