• prometheus远程写调优参数说明


    ##prometheus.yaml配置文件中远程写配置
    - url: http://prometheus-kafka-adapter-v2:8090/receive
      remote_timeout: 30s
      queue_config:
        capacity: 1000
        max_shards: 1000
        min_shards: 1
        max_samples_per_send: 100
        batch_send_deadline: 5s
        max_retries: 3
        min_backoff: 30ms
        max_backoff: 100ms

    远程写特点

    每个远程写目的地都启动一个队列,该队列从write-ahead log (WAL)中读取数据,将样本写到一个由(分片)shard拥有的内存队列中,然后分片将请求发送到配置的端点。数据流程如下:

          |-->  queue (shard_1)   --> remote endpoint
    WAL --|-->  queue (shard_...) --> remote endpoint
          |-->  queue (shard_n)   --> remote endpoint

    当一个分片备份并填满它的队列时,Prometheus将阻止从WAL中读取任何分片。如果失败了,则进行重试,其间不会丢失数据,除非远程端点保持关闭状态超过2小时。2小时后,WAL将被压缩,未发送的数据将丢失。

    在远程写过程中,Prometheus将根据输入采样速率、未发送的采样数量和发送每个采样数据所需的时间,不断计算出最优的分片数量。

    内存使用

    使用远程写操作会增加Prometheus的内存占用。大多数用户报告内存使用量增加了25%,但是这个数字取决于数据的结构。对于WAL中的每个时间序列,远程写缓存一个key为时间序列ID,value为标签值的map,导致大量的时间序列变动,从而显著地增加内存使用量。

    除了时间序列缓存之外,每个分片及其队列还会增加内存使用量。分片内存与 number of shards * (capacity + max_samples_per_send)成比例。在进行调优时,可以考虑减少max_shards,同时增加capacitymax_samples_per_send,以避免内存耗尽。使用capacitymax_samples_per_send的默认值,可以将分片内存的使用量限制在每个分片少于100 kB。

    参数

    capacity

    capacity控制在阻止从WAL读取之前,每个分片中有多少个采样在内存中排队。一旦WAL被阻塞,就不能将采样附加到任何分片上,停止所有吞吐量。

    在大多数情况下,容量应该足够大,以避免阻塞其他分片,但是太大的容量会导致过多的内存消耗和在重新分片期间清除队列的时间更长。建议将容量设置为max_samples_per_send的3-10倍。

    max_shards

    max_shards配置Prometheus将为每个远程写队列使用的最大分片数量,即并行度。Prometheus将尽量不使用过多的分片,但如果队列落后于远程写组件,将增加分片的数量到最大分片数量,以增加吞吐量。除非远程写入非常慢的端点,否则不太可能将max_shards超出默认值。但是,如果有压跨远程端点的可能性,则需要减少最大分片数量,或者在备份数据时减少内存使用。

    min_shards

    min_shards配置Prometheus使用的分片的最小数量,是远程写入启动时使用的分片的数量。如果远程写迟滞,Prometheus将自动增加分片的数量,这样大多数用户就不必调整这个参数。然而,增加最小分片可以让Prometheus在开始计算所需分片数量时避免迟滞。

    max_samples_per_send

    每次发送的最大采样数量可以根据使用的后端进行调整。许多系统在不显著增加延迟的情况下发送更多的批处理采样而工作得非常好。如果试图在每个请求中发送大量采样,其他后端将会出现问题。足够小的默认值,适用于大多数系统。

    batch_send_deadline

    批量发送截止时间设置发送单个分片之间的最大时间隔。即使队列中的分片没有到达max_samples_per_send,也会发送一个请求。低容量系统,对延迟敏感的系统可以增加batch_send_deadline,以提高请求效率。

    min_backoff

    min_backoff控制在重试失败请求之前等待的最短时间。当远程端点重新上线时,增加backoff spreads out请求。对于达到max_backoff的每个失败请求,backoff间隔增加一倍。

    max_backoff

    max_backoff控制重试失败请求之前等待的最长时间。

    官方配置文件格式

    # 要发送样本的端点的URL.
    url: <string>
    
    # 对远程写端点的请求超时。
    [ remote_timeout: <duration> | default = 30s ]
    
    # 远程写入重新标记配置列表。
    write_relabel_configs:
      [ - <relabel_config> ... ]
    
    # 使用配置的用户名和密码在每个远程写请求上设置`Authorization`标头.password和password_file是互斥的。
    basic_auth:
      [ username: <string> ]
      [ password: <string> ]
      [ password_file: <string> ]
    
    # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_token_file`互斥。
    [ bearer_token: <string> ]
    
    # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_token`互斥。
    [ bearer_token_file: /path/to/bearer/token/file ]
    
    # 配置远程写入请求的TLS设置。
    tls_config:
      [ <tls_config> ]
    
    # 可选的代理URL。
    [ proxy_url: <string> ]
    
    # 配置用于写入远程存储的队列。
    queue_config:
      # 在我们开始删除之前每个分片缓冲的样本数。
      [ capacity: <int> | default = 10000 ]
      # 最大分片数,即并发数。
      [ max_shards: <int> | default = 1000 ]
      # 最小分片数,即并发数。
      [ min_shards: <int> | default = 1 ]
      # 每次发送的最大样本数。
      [ max_samples_per_send: <int> | default = 100]
      # 样本在缓冲区中等待的最长时间。
      [ batch_send_deadline: <duration> | default = 5s ]
      # 在可恢复错误上重试批处理的最大次数。
      [ max_retries: <int> | default = 3 ]
      # 初始重试延迟。 每次重试都会加倍。
      [ min_backoff: <duration> | default = 30ms ]
      # 最大重试延迟。
      [ max_backoff: <duration> | default = 100ms ]
    参考文献:https://prometheus.io/docs/practices/remote_write/
  • 相关阅读:
    第一章Python 数据模型
    Numpy 之 where理解
    探析熟悉而又困惑的参数:argc && argv
    python读书笔记
    经典进程的同步问题之——读者写者
    经典进程的同步问题之——哲学家进餐
    冰多多团队博客目录
    团队事后分析
    冰多多团队Gamma阶段发布说明
    gamma测试报告
  • 原文地址:https://www.cnblogs.com/gavin11/p/12668294.html
Copyright © 2020-2023  润新知