本系列着重介绍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/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}