在容器服务（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 采集规模不超过 1k sps 时，可使用以下配置作为初始值，以降低内存占用和发送并发。使用默认值（即 capacity: 10000、max_samples_per_send: 2000）时，每个分片的内存占用通常小于 2 MB，总内存峰值约等于：max_shards \* 单个分片内存。参考配置： ```YAML # 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 采集规模为 5k–20k sps 时，可先使用接近默认值的配置，并观察分片数和样本积压情况。观察结果可用于判断发送并发是否接近上限，或远端接收能力是否不足。参考配置： ```YAML # 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 采集规模达到 50k sps 以上时，建议提高队列容量、最小分片数和单次发送样本数，并确认远端能够承受对应并发。参考配置： ```YAML # 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 发出的所有时间序列附加固定标签，例如集群名称、地域、环境等。多个集群、地域或环境的数据写入同一远端时，可通过这些标签区分指标来源。 ```YAML global: external_labels: cluster: 'xxxxx' prometheus: 'prometheus-agent' ``` * 使用 `write_relabel_configs` 过滤指标 `write_relabel_configs` 是 `remote_write` 下的配置，可以在数据发送前，基于标签对时序数据进行过滤、重塑和修改。该配置可用于保留关键指标或丢弃低价值指标，控制进入远端存储的数据范围。 ```YAML write_relabel_configs: # 只保留 up 和 app_开头的指标 - source_labels: [__name__] regex: 'up|app_.*' action: keep # 丢弃所有来自 debug 命名空间的指标 - source_labels: [kubernetes_namespace] regex: 'debug' action: drop ``` * 修改或重命名标签可使用 `labelmap` 或 `replace` 统一标签名称，或修复不规范的标签值，减少不一致标签进入远端存储。 ```YAML 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 持续增长时）：** 1. 检查 `prometheus_remote_storage_shards` 是否已达到 `max_shards`。 2. 查看 `sent_batch_duration` 是否过高，判断是网络延迟还是远端处理慢。 3. 查看 Agent 日志，检查是否有大量 `HTTP 429`、`HTTP 5xx` 错误码，或 `context deadline exceeded` 超时。 4. 如果是后端问题，按降压策略调整 `queue_config`。 **排查内存升高：** 1. 确认是否由分片数过多引起，特别是在数据积压时，`shards` 会自动扩容至 `max_shards`。 2. 检查 `prometheus_tsdb_head_series`，确认是否由高基数 Target 导致。 3. 降低 `max_shards`，可以快速控制内存增长。 **排查证书或鉴权问题：** 1. 查看 Agent 日志，通常会有明确的 `certificate signed by unknown authority` 或 `authorization failed `等 TLS / Auth 错误。 2. 检查 `tls_config` 和 `authorization`（例如 `bearer_token_file`）配置是否正确。 3. 检查证书是否存在且权限正常。

托管 Prometheus