一步步教你用Prometheus搭建实时监控系统系列(二)——详细分析拉取和推送两种不同模式
前言
本系列着重介绍 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/pushgateway/releases
按照需要下载对应的包，我这里是需要部署在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/{/
这个测试用例为意思是，推送一个指标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 中引入依赖包：
io.prometheus
simpleclient_pushgateway
0.9.0
对 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 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的技术资料
About The Author
