【Prometheus】Prometheus联邦的一次优化记录[续]

前言

之前有整理过一次Prometheus联邦集群的优化记录，针对无用指标进行一个摈弃，从一定程度上环节查询节点的数据拉取压力，但是当指标量足够大，或者采集端点足够多了以后，这个方法就有点拙荆见肘了；于是对指标进行分组变成了下一步的优化方法，在此记录一下。

有关非必要指标的屏蔽参考之前的文章【Prometheus】Prometheus联邦的一次优化记录

正文

服务器规划

先说明一下当前环境三台Prometheus节点的规划，IP经过处理：

服务器IP	服务器类型	CPU	内存
10.0.0.69	采集Prometheus	64	256
10.0.0.70	采集Prometheus	64	256
10.0.0.71	汇聚Prometheus	64	256

其中采集Prometheus的职能为从具体的采集端点拉取数据，如node_exporter；汇聚Prometheus负责从各个采集Prometheus节点周期的汇聚采集到的指标；

分析过程

在上次优化之后，监控的采集端点又不断的增加，在前几天，有一台采集Prometheus又开始频繁出现由于响应时间过久而导致指标摄取出现断点的情况：

在对应的服务器进行排查，主机的资源使用并不高，Prometheus的进程也没有占用太多资源，排除采集Prometheus的资源瓶颈导致的指标采集异常，这台节点已经从主机采集到了必要的指标，那么怀疑依旧是查询Prometheus节点在进行指标汇聚时出现超时导致的；

上次优化修改后的配置如下：

  - job_name: 'federate'
    honor_labels: true
    metrics_path: '/federate'
    params:
        'match[]':
          - '{__name__=~"node_.*|up.*"}'
    static_configs:
      - targets:
        - '10.0.0.69:9090'
        - '10.0.0.70:9090'
        labels:
          cluster: XXXX系统
    tls_config:
        insecure_skip_verify: true

当前已经筛选了所需的指标，因此从减少总的指标采集量这个方向是没有什么办法了，可以考虑对大批量传输的指标进行拆分的方式来进行汇聚，即原本会分别汇聚两个采集Prometheus节点的全量监控指标（当然本例中只会摄取node_开头的和up开头的指标）

分组摄取

由于采集的主机监控指标都存在instance标签，可以通过网段来进行分组拉取指标的操作，这样每一个拉取动作将不会拉取巨量指标，而是分解成了一个个较小的拉取动作，具体操作如下：

# 第一组
  - job_name: 'federate_0'
    honor_labels: true
    metrics_path: '/federate'
    params:
        'match[]':
          # 负责拉取10.0.4开头的IP的服务器指标
          - '{__name__=~"node_.*|up.*",instance=~"10.0.4.*9100"}'
    static_configs:
      - targets:
        - '10.0.0.69:9090'
        - '10.0.0.70:9090'
        labels:
          cluster: XXXX系统
    tls_config:
        insecure_skip_verify: true
# 第二组
  - job_name: 'federate_1'
    honor_labels: true
    metrics_path: '/federate'
    params:
        'match[]':
          # 负责拉取10.0.6开头的IP的服务器指标
          - '{__name__=~"node_.*|up.*",instance=~"10.0.6.*9100"}'
    static_configs:
      - targets:
        - '10.0.0.69:9090'
        - '10.0.0.70:9090'
        labels:
          cluster: XXXX系统
    tls_config:
        insecure_skip_verify: true
  # 第三组
  - job_name: 'federate_2'
    honor_labels: true
    metrics_path: '/federate'
    params:
        'match[]':
          # 负责拉取10.0.7/8开头的IP的服务器指标
          - '{__name__=~"node_.*|up.*",instance=~"10.0.7.*9100|10.0.8.*9100"}'
    static_configs:
      - targets:
        - '10.0.0.69:9090'
        - '10.0.0.70:9090'
        labels:
          cluster: XXXX系统
    tls_config:
        insecure_skip_verify: true
  # 第四组
  - job_name: 'federate_3'
    honor_labels: true
    metrics_path: '/federate'
    params:
        'match[]':
          # 负责拉取10.30开头的IP的服务器指标
          - '{__name__=~"node_.*|up.*",instance=~"10.30.*9100"}'
    static_configs:
      - targets:
        - '10.0.0.69:9090'
        - '10.0.0.70:9090'
        labels:
          cluster: XXXX系统
    tls_config:
        insecure_skip_verify: true

然后保存配置，并重载Prometheus服务；再观察指标摄取情况，不再出现采集断点：

再看摄取时间，这次产生非常大的优化效果：

小结

在Prometheus进行指标采集时，无论是联邦还是单节点的方式，都要尽可能的使其在每个指标摄取端点减少数据的摄入，这样才能满足足够的延迟要求，否则网络传输会耗费大量的数据拉取时间，导致监控的指标出现断点。