玩转Prometheus的pushgateway和联邦集群
一、部署pushgateway
Pushgateway 是一种中介服务,它允许从无法抓取的作业中推送指标。
通常,Pushgateway 唯一有效的用例是用于捕获服务级批处理作业的结果, “服务级别”批处理作业是与特定机器或作业实例在语义上不相关的作业。此类作业的指标不应包含机器或实例标签,以将特定机器或实例的生命周期与推送的指标分离。这减轻了在 Pushgateway 中管理陈旧指标的负担。
1.1、下载pushgateway
wget https://github.com/prometheus/pushgateway/releases/download/v1.10.0/pushgateway-1.10.0.linux-amd64.tar.gz
1.2、解压并创建软连接
# tar zxvf pushgateway-1.10.0.linux-amd64.tar.gz
# ln -sv /usr/local/src/pushgateway-1.10.0.linux-amd64 /usr/local/pushgateway
1.3、创建pushgateway的service文件
# vim /usr/lib/systemd/system/pushgateway.service
1.4、启动pushgateway
# systemctl daemon-reload
# systemctl start pushgateway
# systemctl status pushgateway
1.5、通过web页面访问pushgateway
1.6、向pushgateway推送数据
想要push数据到pushgateway,可以通过其提供的API标准接口来推送,默认URL地址为:
http://<IP>:9091/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
其中JOBNAME是必须的,后面可以跟任意数量的标签对,一般我们会添加一个intance/instance_name来标记指标来自哪个节点
# echo "mytest_metric 2024" | curl --data-binary @-http://172.16.1.70:9091/metrics/job/myteest_job/instance/172.16.1.100
从pushgateway的web页面上能查询到对应的指标说明推送成功
@-表示从标准输入读取数据
客户端推送多条数据:
#cat << EOF | curl --data-binary @- http://172.16.1.70:9091/metrics/job/test_job/instance/172.16.1.100
#TYPE node_memory_usage gauge
node_memory_usage 3456789
#TYPE memory_total gauge
node_memory_total 1698203945
EOF
可以通过脚本定时推送想要的指标数据,如下
脚本如下,自动获取本节点的内存使用量、内存总量
设置定时任务每分钟执行一次脚本
定时执行该脚本后,在pushgateway上可以定时收到该脚本推送的数据
1.7、配置prometheus定时抓取pushgateway上的数据
在prometheus的配置文件里添加一个job
添加一个读取pushgateway数据的一个job,重启prometheus即可
重启完成后,通过prometheus的web界面即可查询到从pushgateway上读取到的数据
1.8、删除pushgateway上的数据
curl -X DELETE http://172.16.1.70:9091/metrics/job/test_job/instance/172.16.1.100
同1.6设置的脚本,定时推送数据到pushgateway,pushgateway上可以看到推送过来的指标数据
通过curl -X DELETE命令可以删除指定的指标数据
执行命令后在pushgateway上看到指标数据被删除了
二、Prometheus联邦部署
对于大部分监控规模而言,我们只需要在每一个数据中心(例如:EC2可用区,Kubernetes集群)安装一个Prometheus Server实例,就可以在各个数据中心处理上千规模的集群。同时将Prometheus Server部署到不同的数据中心可以避免网络配置的复杂性。
如上图所示,在每个数据中心部署单独的Prometheus Server,用于采集当前数据中心监控数据。并由一个中心的Prometheus Server负责聚合多个数据中心的监控数据。这一特性在Promthues中称为联邦集群。
在一个数据中心里也可以根据不同的监控对象分别部署Prometheus,每个Prometheus只负责采集当前数据中心里的一部分任务(job),例如可以将不同的监控任务分离到不同的Prometheus实例中,再由中心prometheus实例进行聚合。
联邦集群的核心在于每一个Prometheus Server都包含额一个用于获取当前实例中监控样本的接口/federate。对于中心Prometheus Server而言,无论是从其他的Prometheus实例还是Exporter实例中获取数据实际上并没有任何差异。
2.1、部署联邦节点
我这里部署两个联邦节点,一个节点采集k8s-master节点的指标数据,另一个联邦节点采集k8s-nodes节点的指标数据,机器分布如下表
联邦节点 | 采集目标 |
---|---|
节点172.16.1.12 | k8s-master01(172.16.1.65) |
节点172.16.1.13 | k8s-node01(172.16.1.66) k8s-node02(172.16.1.67) k8s-node03(172.16.1.68) |
由于现在还没学习Prometheus在k8s集群里的自动服务发现功能,这里先通过node_exporter的方式采集node的指标数据,k8s-master和k8s-node各节点上分别部署node_exporter(部署方式参考上一篇文章)
两台联邦节点上分别部署prometheus server(部署方式参考上一篇),配置文件有所区别
172.16.1.12上配置采集k8s-master01(172.16.1.65)的指标数据
172.16.1.13上配置采集k8s-node01/k8s-node02/k8s-node03三台node节点的指标数据
分别重启172.16.1.12和172.16.1.13上的prometheus,之后通过web页面可以看到分别获取到了对应k8s节点的指标数据,如下图
2.2、配置核心Prometheus收集联邦节点上的指标
从2.1步骤可以看到两个联邦节点分别收集到了对应节点的指标数据,现在要将两台联邦节点上的指标数据汇总到核心Pormetheus上,进行统一监控和数据展示
现在需要在核心Prometheus Server上配置,这里我复用上面已经部署的Prometheus Server(172.16.1.71:9090),需要在Prometheus的配置文件中添加如下配置
- job_name: "prometheus-federate-1.12"scrape_interval: 10shonor_labels: truemetrics_path: '/federate'params:'match[]': #数据匹配条件- '{job="prometheus"}' #匹配联邦节点自己的指标数据- '{job="k8s-master"}' #匹配联邦节点采集到的指标数据- '{__name__=~"job:.*"}'- '{__name__=~"node.*"}'- '{__name__=~"node_memory.*"}'static_configs:- targets:- '172.16.1.12:9090'- job_name: "prometheus-federate-1.13"scrape_interval: 10shonor_labels: truemetrics_path: '/federate'params:'match[]':- '{job="prometheus"}'- '{job="k8s-nodes"}'- '{__name__=~"job:.*"}'- '{__name__=~"node.*"}'- '{__name__=~"node_memory.*"}'static_configs:- targets:- '172.16.1.13:9090'
重启核心Prometheus,从web上可以看到已经采集到了联邦节点上的指标数据
分别点开两个联邦节点的EndPoint可以看到联邦节点采集到的所有指标数据
通过核心Prometheus的PQL可以查询到不同联邦节点采集的指标数据
通过grafana也可以看到联邦节点采集到到指标数据
这样就完成了联邦节点的部署和指标数据汇总,综上,联邦节点既可以解决复杂的网络环境不能使用同一Prometheus Server收集所有节点的数据的问题,也能根据不同节点类型分别收集指标数据减轻核心Prometheus的性能压力,所以联邦集群的使用可以根据自己的环境灵活选择部署方式。
后面介绍在k8s集群里部署Prometheus,并实现K8S集群资源的自动发现,指标采集和告警功能,请关注我的帐号,敬请期待。
欢迎关注作者的公众号,公众号每天分享运维干货文章