前言
本系列着重介绍Prometheus
以及如何用它和其周边的生态来搭建一套属于自己的实时监控告警平台。
本系列受众对象为初次接触Prometheus
的用户,大神勿喷,偏重于操作和实战,但是重要的概念也会精炼出提及下。系列主要分为以下几块
-
Prometheus
各个概念介绍和搭建,如何抓取数据(一步步教你用Prometheus搭建实时监控系统系列(一)——上帝之火,普罗米修斯的崛起) - 如何推送数据至
Prometheus
,推送和拉取分别用于什么样的场景(本次分享内容) -
Prometheus
数据的结构以及查询语言PromQL
的使用 - Java应用如何和
Prometheus
集成,如何启用服务发现,如果自定义业务指标 -
Prometheus
如何和Grafana
可视化套件进行集成和设置告警 - 教你如何手写一个集成了监控Dubbo各个指标的java套件
- 实际案例分享,如何做各个业务端和系统端的监控大盘
抓取和推送
拉取模式:
Prometheus
获取数据的方式只有拉取(PULL),即Prometheus
会以固定频率去请求每个target
所提供的http url
来获取数据。这就需要每个服务端点提供http
的接口来获取实时的数据。
推送模式:
Prometheus
也变相的实现了推送数据的方式。
为什么说是变相呢。因为Prometheus
获取数据的方式一直是拉取方式,官方并没有提供推送数据的功能。但是官方为了兼容推送这种方式,增加了一个PushGateway
组件。
这个组件相当于一个代理服务,独立部署。它没有数据抓取功能,只能被动的等待数据推送。应用把数据推送到PushGateway
后,Prometheus
再从PushGateway
抓取。
推送模式要注意的点
即便客户端推了全量的数据到了PushGateway
,Prometheus
也不是每次拉取这个期间用户推上来的所有数据。
事实上Prometheus
只拉取用户最后一次push上来的数据。
在这个系列一的时候,曾经提到过Prometheus
其实并不需要每一个精确的数据,长期保存的是中等或者低精度的数据。它每次只抓取一个数据,在固定的频率下。也能形成某种数据的趋势。
如果客户端一直没有推送新的指标到PushGateway
,那么Prometheus
将始终拉取最后推送上的数据,直到指标消失,默认是5分钟。
Pushgateway
本意是不会存储指标的,但是为了让pushgateway
意外重启一类的故障之后能够重新读取到原来的指标,添加了一个将指标暂时存储到本地的功能,参数--persistence.interval=5m
就是默认保持5分钟,5分钟后,本地存储的指标会删除。可以通过调节这个值来修正发现异常的时间。
通过单个Pushgateway
监控多个实例时,Pushgateway
有可能成为单点故障和潜在瓶颈
如果要用Pushgateway
的话,建议多点部署。然后前面通过nginx
进行反向代理多个节点,进行负载均衡。
推送模式适用的场景
-
Prometheus
采用定时拉取模式,可能由于子网络或者防火墙的原因,不能直接拉取各个Target
的指标数据,此时可以采用各个Target
往PushGateway
上推送数据,然后Prometheus
去PushGateway
上定时拉取 - 在监控各个业务数据时,需要将各个不同的业务数据进行统一汇总,此时也可以采用
PushGateway
来统一收集,然后Prometheus
来统一拉取
搭建
Pushgateway
分docker
安装和普通安装两种,这里才用普通安装
先上prometheus
的github release主页
https://github.com/prometheus...
按照需要下载对应的包,我这里是需要部署在linux服务器上,所以下载这个
下载好,解压。运行:
nohup ./pushgateway &
启动起来后,默认端口为9091
在浏览器上根据ip+port可以访问到如下页面,就算启动成功了:
除此之外还要在Prometheus
的配置文件里设置Target
:
- job_name: 'pushgateway'
scrape_interval: 10s # 每过10秒拉取一次
honor_labels: true
static_configs:
- targets: ['localhost:9091']
labels:
instance: pushgateway
设置完毕后重启Prometheus
,然后会在Target
选项卡里看到状态为UP
的Pushgateway
。
设置阶段就完成了。
URL推送测试
我这里用postman
软件进行推送测试,推送url
的格式为:/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
这个测试用例为意思是,推送一个指标aaa,标签为bbb=BBB,ccc=CCC
,值为111.1到一个组上,这个组为job=pushgateway,instance=demo
。
其实你可以简单的理解为这个指标aaa带有4个标签:job,instance,bbb,ccc。只是job和instance是属于组上的标签。
同一个组里的相同的指标,Prometheus
每次只取最新的,不同组内可以有相同的指标。
关于数据结构和标签结构系列的下一篇文章会详细介绍。
总之,你提交这个POST
请求后,可以在http://ip:9091
上看到如下数据:
可以看到,aaa这个标签已经成功的被提交到Pushgateway
里了。
接下来,我们在Prometheus
里查询这个指标:
可以看到,Prometheus
也成功的拉取到了这个指标。
Java端利用SDK进行推送
虽然我们在java服务端也能利用httpclient
等工具进行提交,但是需要自行组装很多请求体。Prometheus
官方提供了一个SDK。
首先在Maven
中引入依赖包:
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>simpleclient_pushgateway</artifactId>
<version>0.9.0</version>
</dependency>
对Gauge
,Timer
,Counter
,Summary
四种常见的指标进行推送示例:
public void run(String... args) throws Exception {
Gauge guage = Gauge.build("my_custom_metric", "This is my custom metric.")
.labelNames("aaa","bbb").register();
Gauge.Child child = guage.labels("AAA","BBB");
child.set(334.5);
Gauge timerGauge = Gauge.build("my_timer_metric","this is my timer metric.").register();
Gauge.Timer timer = timerGauge.startTimer();
Thread.sleep(3000L);
Counter counter = Counter.build("my_count_metric","this is my count metric.").register();
counter.inc();
counter.inc();
Summary summary = Summary.build("my_summary_metric","this is my summary metric.").register();
summary.observe(45.6);
summary.observe(54.5);
String url = "xxx.xxx.xxx.xxx:9091";
PushGateway pg = new PushGateway(url);
Map<String, String> groupingKey = new HashMap<>();
groupingKey.put("instance", "my_instance");
pg.pushAdd(CollectorRegistry.defaultRegistry, "my_job", groupingKey);
}
这段代码演示了4个指标批量提交的场景。通过注册到CollectorRegistry.defaultRegistry
里,最后一起pushAdd
。
我们可以在Pushgateway
里查询到提交的指标:
同样在Prometheus
里也能查询到这4个指标,具体图示就不贴了。可以自己尝试下。
最后
这个系列旨在利用实战操作教你一步步搭建自己系统和业务监控大盘。后面会继续更新。下一个章节将分析:Prometheus
中的数据格式分析以及PromQL
的使用。
关注作者
如果你喜欢作者的文章,欢迎微信公众号关注 「元人部落」,一个只做原创的技术科技分享号
关注后回复“资料”获取50G的技术资料
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。