本系列着重介绍Prometheus以及如何用它和其周边的生态来搭建一套属于自己的实时监控告警平台。
Prometheus
本系列受众对象为初次接触Prometheus的用户,大神勿喷,偏重于操作和实战,但是重要的概念也会精炼出提及下。系列主要分为以下几块
PromQL
Grafana
拉取模式:
Prometheus获取数据的方式只有拉取(PULL),即Prometheus会以固定频率去请求每个target所提供的http url来获取数据。这就需要每个服务端点提供http的接口来获取实时的数据。
target
http url
http
推送模式:
Prometheus也变相的实现了推送数据的方式。
为什么说是变相呢。因为Prometheus获取数据的方式一直是拉取方式,官方并没有提供推送数据的功能。但是官方为了兼容推送这种方式,增加了一个PushGateway组件。
PushGateway
这个组件相当于一个代理服务,独立部署。它没有数据抓取功能,只能被动的等待数据推送。应用把数据推送到PushGateway后,Prometheus再从PushGateway抓取。
即便客户端推了全量的数据到了PushGateway,Prometheus也不是每次拉取这个期间用户推上来的所有数据。
事实上Prometheus只拉取用户最后一次push上来的数据。
在这个系列一的时候,曾经提到过Prometheus其实并不需要每一个精确的数据,长期保存的是中等或者低精度的数据。它每次只抓取一个数据,在固定的频率下。也能形成某种数据的趋势。
如果客户端一直没有推送新的指标到PushGateway,那么Prometheus将始终拉取最后推送上的数据,直到指标消失,默认是5分钟。
Pushgateway本意是不会存储指标的,但是为了让pushgateway意外重启一类的故障之后能够重新读取到原来的指标,添加了一个将指标暂时存储到本地的功能,参数--persistence.interval=5m就是默认保持5分钟,5分钟后,本地存储的指标会删除。可以通过调节这个值来修正发现异常的时间。
Pushgateway
pushgateway
--persistence.interval=5m
通过单个Pushgateway监控多个实例时,Pushgateway有可能成为单点故障和潜在瓶颈
如果要用Pushgateway的话,建议多点部署。然后前面通过nginx进行反向代理多个节点,进行负载均衡。
nginx
Target
Pushgateway分docker安装和普通安装两种,这里才用普通安装
docker
先上prometheus的github release主页
prometheus
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。
UP
设置阶段就完成了。
我这里用postman软件进行推送测试,推送url的格式为: /metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
postman
url
/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
这个测试用例为意思是,推送一个指标aaa,标签为bbb=BBB,ccc=CCC,值为111.1到一个组上,这个组为job=pushgateway,instance=demo。
bbb=BBB,ccc=CCC
job=pushgateway,instance=demo
其实你可以简单的理解为这个指标aaa带有4个标签:job,instance,bbb,ccc。只是job和instance是属于组上的标签。
同一个组里的相同的指标,Prometheus每次只取最新的,不同组内可以有相同的指标。
关于数据结构和标签结构系列的下一篇文章会详细介绍。
总之,你提交这个POST请求后,可以在http://ip:9091上看到如下数据:
POST
http://ip:9091
可以看到,aaa这个标签已经成功的被提交到Pushgateway里了。
接下来,我们在Prometheus里查询这个指标:
可以看到,Prometheus也成功的拉取到了这个指标。
虽然我们在java服务端也能利用httpclient等工具进行提交,但是需要自行组装很多请求体。Prometheus官方提供了一个SDK。
httpclient
首先在Maven中引入依赖包:
Maven
<dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_pushgateway</artifactId> <version>0.9.0</version> </dependency>
对Gauge,Timer,Counter,Summary四种常见的指标进行推送示例:
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。
CollectorRegistry.defaultRegistry
pushAdd
我们可以在Pushgateway里查询到提交的指标:
同样在Prometheus里也能查询到这4个指标,具体图示就不贴了。可以自己尝试下。
这个系列旨在利用实战操作教你一步步搭建自己系统和业务监控大盘。后面会继续更新。下一个章节将分析:Prometheus中的数据格式分析以及PromQL的使用。
原文链接:https://www.cnblogs.com/bryan31/p/13390355.html