Prmetheus 主要用来做来Metrics的监控和报警，这张图是官方的架构图。

这是他的核心 它的作用是根据我们的配置去完成数据的采集、服务的发现，以及数据的存储。

这是服务的发现，通过Service discovery,prmethesu就会知道去哪里采集数据。Service discovery有两种形式，一种是是静态的，就是通过文件去配。告诉它你要去哪拿这个Metrics的数据，另一种就是动态的，通过zookeeper或者其他的一些配置中心，配置中心里面的数据变化的时候，Prometheus也跟着变，去不同的地方去抓数据，

这都是我的应用来提供的，普罗米修斯是抓数据，是一个拉的模式，Prometheus调用我们的接口，然后把我们的数据抓走，是Prometheus来我们这拉数据，这样的好处是，对于我们的应用来说，我们不需要知道Prometheus的服务在哪的，不需要做这些配置，我们只要暴露我们的数据就看可以了。 统一在Prometheus里面来配置.这样Prometheus就可以去各种 地方抓各种各样的数据。


Pushgateway是用来支持推模式的，因为有些时候，有些数据它并不是一直存在的，比如说我们的定时任务，Prometheus来抓的时候，我的定时任务刚好没启动，那么你就抓不到数据，所以向定时任务的数据 它会发给Pushgateway一个推送网关，这个时候，定时任务调用Pushgateway调用的接口，把数据直接给到Pushgateway。然后Prometheus去Pushgateway去拿东西，相当于Pushgateway是一个中间的临时存储，把这种短活的数据把它存储起来。然后供Prometheus来拉。


采集的都是一些格式化的数据，流量啊，响应时间，这些数字格式化的数据，这个页面可以帮你把这些数据 图形化的展示出来。但这个页面很简陋。所以为了解决这个问题有个专门的项目叫做Grafana，它是一个更高级的图形界面Grafana，它可以从Prometheus里面拿数据。把数据用图标的形式展示出来。然后让你一眼就看到你现在的系统是什么状况。
当然你可以自己去写代码API clients去调Prometheus的服务，然后你自己拿出来去做处理。。

他们和Prometheus通讯的时候，主要 用到的语言是PromQL,Prometheus自己的一个查询语言，和SQL类型，但是唯一不同的是，这个语言只能写查询，

右上角，AlertManager管理警告警用的，它来做报警，报警的方式有很多种。
Prometheus和AlertManager之间会有一些推送，你可以定义一些规则，Prometheus是做Metrics监控的，所谓的Metrics就是所有可以用数字来表示的数据，都可以用Metrics来采集。比如说你的系统的流量，服务的相应时间 ，那么根据这些Metrics可以去定义一些规则，比如说可以定义，服务的相应时间 如果大于100毫秒，那么我就报警，如果你定下了这样的规则以后，Prometheus隔一段时间，这个时间也是你自己指定的，比如说每隔10秒，或者每隔一分钟就去评估一下采集到的数据，然后根据你定的规则去评估，如果你采集的数据超过了你定义的预值，比如说响应时间超过了100毫秒，那么它就会往这边推送一个警告。但是这个警告推过去以后，并不会立刻报警。因为它会再连续的评估几个周期。比如说你设的评估周期是10秒。他可能再评估5次左右，在这个后面5次都是要报警的情况，它才会真正的报这个警。而不是说每一次评估没过就立马报警。这样很可能就会出现误报的情况。比如说网络抖动啊。导致你的服务某些情况延迟了。 但是可能这些抖动，可能马上就会过去了。 这个时候如果你采集到异常数据，马上报警。很可能有很多的报警是假的，是没有真正发现问题的。

这个就是整个Prometheus大的架构
在项目里面建了个文件夹。叫做monitoring，监控的一个文件夹，


这里面放了很多的配置文件。代码不再敲了  带着大家一行行的去读代码。


这是一个docker的复合文件，作用是一次替我装几个docker镜像。


一旦你装了Prometheus，橙色的框的就都安装上了 ， 只有黄色的框需要单独安装。

这里安装了两个 一个是prometheus和hgrafana,
image配置的，启动后就会docker的中央仓库把它拉下来。一run起来，我就有了一个Prometheus的服务器了。

每个镜像run的时候就生成一个容器，给这个容器起个名字prometheus.

我们下了prometheus，我们要给它一些配置，告诉你这个prometheus去哪里抓数据，

需要有一个服务发现的配置。告诉它你要去我的那些服务orderService抓我的监控数据，，那么这些配置怎么放进去。就是通过volumes ，挂载卷的方式，

也就是我们之前讲的物力资源映射到容器的方式

那么映射的值是什么？就是配置的这个

冒号前面是我本地机器的目录，相对我当前所在的这个目录，里面的prometheus文件夹。

实际上指的就是我左边项目里的这个文件夹，里面放了一个prometheus的配置文件。
然后我把这个文件放在prometheus镜像里的/etc/prometheus这个文件夹下面。

也就是说这各prometheus.yml最终会出现在镜像的/etc/prometheus/这个目录里。默认情况prometheus就是从这个路径下/etc/prometheus读配置文件的。这样我就可以把我的配置文件放到了prometheus的镜像里，那么跑的时候就按照我定义的配置来跑。

机器访问用9092端口，9090是容器的端口。为什么没有用9090的端口，因为我的9090端口被认证服务器的api占用了。所以这里把它映射到9092



进入到monitoring文件夹

-f指定一个文件为docker-compose.yml 。up是启动。

第一跑的话，可能会有下镜像的日志，因为这里已经运行过了。所以这里直接量done


访问9092。这个是就peometheus自身带的ui

targets就是你要从哪里采集你的数据

现在这里有两个目标。一个是prometheus本身。它从自己9090/metrics这个路径来采集信息，状态 up表示正常启动。因为prometheus本身是启动着的，

最新的一次从这个端点获取数据，

srpingBoot这个app还没启动起来。

那么这两个目标是从哪里来的呢？

它怎么知道去要去这个位置抓springboot-app的 信息的呢？

prometheus.yml的配置文件

全局的配置，抓取的频率。prometheus是一个拉的模式，每隔一段时间去目标拉取数据，合理配置的就是拉取的频率默认是每隔十五秒一次。


拉取的目标，定义了两个job

抓取prometheus本身的时候又配置了 scrape_interval频率是5秒。这就意味着抓取自己的时候是 5秒每次。

静态的配置下有个targets，就是你要去哪抓数据。配置的是去本机的9090端口去抓。

prometheus是跑在容器里面的，容器你本身可以认为它就是一个机器。我们自己的电脑是另一个机器。你要理解为这两个是两个完全不同的机器。这个配置文件你要明白它是放在prometheus的机器上的。

抓数据，请求路径。一会我们会在Order-APi上做一些操作，让他可以提供出这个路径的接口来。供普罗米修斯来抓数据。

你要去运行docker环境的宿主机的9082端口上去抓，springboot-app的数据。 一会我们会吧orderAPi跑在9082的端口上。

labels就是把抓出来的数据打一个标签。标签名字叫做springboot-app

结束

原文：https://www.cnblogs.com/wangjunwei/p/12001221.html