共计 3653 个字符，预计需要花费 10 分钟才能阅读完成。
前言
本系列着重介绍 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 的技术材料
