前言

之前有整理过一次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: truemetrics_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: truemetrics_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: truemetrics_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: truemetrics_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: truemetrics_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进行指标采集时，无论是联邦还是单节点的方式，都要尽可能的使其在每个指标摄取端点减少数据的摄入，这样才能满足足够的延迟要求，否则网络传输会耗费大量的数据拉取时间，导致监控的指标出现断点。

【Prometheus】Prometheus联邦的一次优化记录[续]相关推荐

【Mac】mac 安装 prometheus 报错 prometheus: prometheus: cannot execute binary file
1.概述 1.下载官网:https://prometheus.io/download/ github : https://github.com/prometheus/prometheus/relea ...
【Docker】Docker 启动prometheus报错 parsing YAML file /etc/prometheus/prometheus.yml: yaml: unmarshal
1.背景本地docker 安装prometheus,然后启动,报错如下 (base) lcc@lcc grafana-storage$ docker logs 790f84fb094904a96b8 ...
mysql in优化_MySQL的一次优化记录（IN子查询和索引优化）
这两天实习项目遇到一个网页加载巨慢的问题(10多秒),然后定位到是一个MySQL查询特别慢的语句引起的: SELECT * FROM ( SELECT DISTINCT t.vc_date, t.c_ ...
[记录][续爬虫]模拟京东登录并且抢购物券
1.登录 2.进去卷中心 3.得到券列表 4.领券[大致路径:/freeGetCoupon.html?key=xxxx][权限原因,这里就不上模拟了,只提供思路] 1.找到登录js,分析登录请求[在登 ...
别再乱用 Prometheus 联邦了，分享一个 Prometheus 高可用新方案
作者 | 浪子燕青燕小乙来源 | https://zhuanlan.zhihu.com/p/368868988 前言我看到很多人会这样使用联邦:联邦 prometheus 收集多个采集器的数据实 ...
prometheus联邦集群
目录一:联邦集群二:什么时候会用到联邦集群 1)跨数据中心 2)垮服务三:prometheus配置文件解析 1) 整体配置文件 2)scrape_configs 四:prometheus部署联邦 ...
prometheus之记录规则(recording rules)与告警规则(alerting rule)
全栈工程师开发手册 (作者:栾鹏) 架构系列文章 Prometheus支持两种类型的规则:记录规则和警报规则. 要在Prometheus中包含规则,请创建一个包含必要规则语句的文件,并让Prometh ...
prometheus联邦监控主机及k8s
目录 1.前言 2.创建用于 Prometheus 访问 Kubernetes 资源对象的 RBAC 对象 3.然后获取上面的 Prometheus 对应的 Secret 的信息: 4.与外部prom ...
架构之美【kubernetes、Prometheus、微服务、LVS负载均衡】
kubernetes kubernetes,简称K8s,是用8代替8个字符"ub ...
搭建prometheus+grafana监控系统
prometheus简介 Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包 .自2012年成立以来,许多公司和组织都采用了Prometheus,该项目拥有非常活跃的开发 ...

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

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

前言

正文

服务器规划

分析过程

分组摄取

小结

【Prometheus】Prometheus联邦的一次优化记录[续]相关推荐

最新文章

热门文章