Remote write 调优
Prometheus 实现了合理的默认值来处理 remote write,但许多用户有不同的需求并希望优化其远程设置。
本页面描述了通过 remote write 配置可用的调优参数。
Remote write特性
每个 remote write 目的端点都会启动一个队列,该队列从写入 WAL(write-ahead log,预览写入写入日志)读取,将样本写入由分片拥有的一个内存中的队列中,然后向配置的端点发送请求。数据流如下:
当一个分片备份并填满其队列时,Prometheus 将阻塞从 WAL 到任何其他分片的读取。除非远程端点长时间保持离线,否则数据不会丢失。如果远程端点持续离线超过2小时,则会压缩 WAL 并丢弃未发送的数据。
在操作过程中,Prometheus 将连续计算使用最优数量的分片,根据传入的样本速率、尚未发送的样本数以及发送每个样本所需的时间。
资源使用
使用 remote write 增加了 Prometheus 的内存占用。大多数用户报告内存占用增加约25%,但这个数字取决于数据的规模。对于 WAL 中的每个序列,remote write 代码缓存了一个序列 ID 到标签值的映射,导致大量序列变化会显著增加内存占用。
除了序列缓存外,每个分片及其队列也增加了内存占用。分片内存与分片数量 * (容量 + 每次发送的最大样本数)
成正比。在调优时,请考虑减少最大分片数
同时增加容量
和每次发送的最大样本数
,以避免意外耗尽内存。默认值容量: 10000
和每次发送的最大样本数: 2000
将约束分片内存使用量少于每分片2MB。
Remote write 也会增加 CPU 和网络使用率。然而,我们也很难预测具体会增加多少。如果你的 Prometheus 服务器在通过 remote write 发送样本时滞后(prometheus_remote_storage_samples_pending
),通常检查 CPU 和网络占用率是一个好的做法。
参数
所有相关参数都可以在 remote write 配置的queue_config
部分找到。
capacity
容量控制每个分片在内存中排队的样本数量,在达到限制前阻止从 WAL 读取。一旦 WAL 被阻塞,就不能向任何分片添加样本,所有数据吞吐都将停止。
因此,应将容量设置得足够高,以避免在大多数情况下阻塞其他分片,但过多的容量可能导致多余的内存消耗和重新划分期间队列清空时间的延长。建议将容量设置为<font style="color:rgb(51, 51, 51);background-color:rgb(249, 242, 244);">max_samples_per_send</font>
的3-10倍。
max_shards
最大分片配置了 Prometheus 为每个 remote write 队列使用的最大分片数或并行量。Prometheus 尝试避免使用太多分片,但如果队列滞后,remote write 组件将增加分片数量至最大分片数以提高吞吐量。除非 remote write 到非常慢的端点,否则不太可能需要增加 max_shards
。然而,如果有可能压垮远程端点,或者为了减少内存使用而数据备份时,可能需要减少最大分片数。
min_shards
最小分片数配置了 Prometheus 使用的最小分片数,并且是 remote write 开始时使用的分片数。如果 remote write 滞后,Prometheus 将自动扩展分片数量,以便大多数用户不必自行调整此参数。但是,增加最小分片数可以在计算所需分片数时避免 remote write 启动时滞后。
max_samples_per_send
最大每次发送的样本数,可以根据使用的后端性能进行调整。许多系统即使发送更多样本数据同样不会显著增加延迟,依然能够运行得很好。其他后端如果尝试在每次请求中发送大量样本,则有可能会出现问题。默认值足够适用于大多数系统。
batch_send_deadline
批发送截止时间设置了单个分片之间发送的最长截止时间。即使队列尚未达到max_samples_per_send
,也会发送数据。我们可以增加批发送的截止时间来提高低流量系统的请求效率,尤其是当系统对延迟不敏感时。
min_backoff
最小重试间隔控制在失败请求重试前等待的最短时间。当远程端点重新上线时,增加重试等待时间可以分散请求。每次请求失败请求后,重试间隔翻倍,直到达到max_backoff
。
max_backoff
最大重试间隔控制在失败请求重试前等待的最大时间。
该文档基于 Prometheus 官方文档翻译而成。