开发者学堂课程【3天吃透 Prometheus：Prometheus 监控系统】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18452
Prometheus 监控系统
2. Prometheus 数据模型
来说一说 Prometheus 数据模型， Prometheus 是如何存储指标数据的、如何表达指标的，那我们有了这段概念才能进行后面的课程，所以各位要耐心的把这些概念搞清楚。
Prometheus 仅用于以键值形式来存储时序的聚合数据，你可以理解为说我们正常情况下，通过从每一个 target 之上可能会采集出来很多指标。随着我们时间流逝，在这一刻我们要采集数据的时候，一个 target 上可能有多个指标，每一个指标都会报出一个样本数据点，这些数据点我的 Prometheus 都要存下来，然后随着时间流逝，这每一个指标都会随着以固定的时间间隔生成很多很多的采集的数据点，所以我们把它称之为叫做时序数据，而在 Prometheus 内部如何去标识、如何去引用这每一个指标？如何去标示这每一个指标序列或者称为叫时间序列。这里有这样一个基本的概念：在其内部，其中的键我们就称之为叫指标，它意味着 CPU 速率、内存使用率或者分区空闲比例等等任何一个我们关注的或者我们需要去关注的对象，任何一个被关注对象，但凡能产生数据的这样的这样的组件我们就称之为一个指标，以固定的时间间隔生成很多很多的采集的数据点，所以我们把它称之为叫做持续数据，而在 Prometheus 的内部如何去表示，如何去引用，如何是如何去标识这每一个指标，所以如何去标志着每一个指标序列或者称为叫时间序列。这里有这样一个基本的概念，再去内部其中的件我们就称之为叫指标，它意味着CPU速率、内存使用率或者分区空闲比例等等，任何一个我们关注的或者我们需要去关注的对象，任何一个被关注对象，但凡能产生数据的这样的这样的组件，我们就称为叫一个指标。
那很显然同一个指标可能会适配到多个目标和设备，很显然你有三个主机，每一个主机可能都会有 CPU 过去一分钟的平均负载，那很显然这他们用的是同一个指标名称，而同一个指标名称下却有三个设备都会输出样本数据，那我如何去表示这三个设备的样本数据？如何去表示这分属于三个设备的不同的时间序列？再说一遍，这有三个主机，每个主机都可能会有过去一分钟之内 CPU 负载我们称为 load 1 ，大家应该知道的，一分钟之内的平均负载，那很显然这三主机各自都会有一个时间序列，甚至可能不止一个，因为你 CPU 多核心的话，每一个核心都会有一个。那我们在 Prometheus 内部如何去表达在每一个时间序列，第一这三个时间序列它的指标名称是统一的，都叫指标，接着这每个时间序列我们会在指标名称之后给它使用叫做标签的机制和拥有不同的标签值来进行表达。你比如说第一个我们指标就叫 load 1，而后给它取名，比如我们有一个标签叫做主机 host ，然后等于node 1，形如 load 1{host=node 1}那就是第一个指标序列，那host等于node 2就是第二个指标，host等于node 3就是第三个指标，希望大家明白。那所以这就是所谓的在 Prometheus 的内部如何表现指标数据的格式，这点至关重要，因为学 Prometheus 最关键的就是学他的 PromQL ，学 PromQL 就是我们要知道它的数据表达格式。
以上这页 PPT 当中给我们的一个示意示例，比如说 cpu_usage 这叫指标名称，然后{core=”1”,ip=”128.0..0.1”} 就叫做标签，标签可以有多个，14.04 是我们的样本数据。随后 Prometheus 在其内部存下来的每一个样本数据都包含了标示、时间序列标示和当前这个时间点的样本值，还有这个样本值所在的时间戳大概是在什么时间点采集的，这点大家要注意。这是 Prometheus 的数据模型的基本形式，很显然跟根据我刚才说过的，没准你的 Prometheus 可能监控了上万个指标，可能有上万个时间序列，那我怎么去从这上万个时间序列当中过滤、取出来取出来我所关注的那个时间序列。注意清楚我刚才说的概念，我们如何从上万个时间序列当中过滤出来我们关注的有限的时间序列，甚至是还要过滤这有限的时间序列在特定时间范围内的样本，这里就是 Prometheus 学习当中最为关键的一步，那我们要自己构建出一个样时间序列表达式来过滤我们所关注的样本质。
3. 指标类型
接下来来关注一下 Prometheus 的指标类型。
对于 Prometheus 而言，刚才讲过那我们可以有很多很多的指标数据，这每一个指标它应该会有它的数据格式，比如文本的或者什么之类的，其实在 Prometheus Service 上所有数据都是以双精度浮点来存储的，它不支持什么日志，至少默认情况下没装插件、没有外置系统的时候是不支持日志数据这样的文本信息的存储的，都是双精度浮点型数据，而且没有类型的概念，类型其实是对客户端来讲的，这点各位要注意。
目前来讲 Prometheus 支持四种方法来描述监控的指标，表示不同格式的数据，第一个 Counter 我们称为叫计数器；第二个叫 Gauge 我们称为叫仪表盘；第三个叫 Histogarm 称为叫直方图，其实直方图主要是用来做分位数的，做分位数它是一种统计的概念，那 Summary 其实也主要是做分位数统计的，我来做一个简要的说明：比如说计数器就是那些单调递增的数据， Gauge 我们称为叫仪表盘，它通常是那些有起伏特征的数据，而Hostogarm 则是直方图，它主要是用来存储那些数据采样或者在一定时间范围内的数据采样的相关结果，尤其是存储一些分位数，以避免像平均值等会存在统计误差或者能带给我们误解的这样一种聚合的概念的。那百分位数是比较常见的，还有四分位数什么之类的。我相信那些统计学专业的同学应该特别了解方差、标准差、分位数包括四分位数、百分位数，还有回归分析、线性分析等等，如果了解这些概念的话，那我们对于所谓的监控系统才能真正的做到掌握，因为所谓的 Data Ops 、 AI Ops 它其实就是做这些简单的数据分析以后，对我们的决策做支撑的。而对于监控系统，如果想使用监控系统，你不了解这个概念，想用好它也无异于痴人说梦。我是不是讲的稍微有点难了，有的同学已经在表示说听不懂，没关系，再听一遍可能对我们朋友来讲应该会有就会有不一样感受，我仍然按照我准备的去描述。
4. 作业和实例
在 Prometheus 当中，我们有两个非常重要的概念，第一个叫做作业，第二个叫实例。
所谓作业，你可以理解为我们前面讲到过的的每一个能够被监控的系统，我们称之为一个target，，而后多种同类的 target 比如所有的主机，为了便于管理可能把它归为一个类，这个类别在 Prometheus 内部就一个Job，这样不知道各位能不能听明白。多个同类型的产品的，比如你多个 MySQL 的监控放一块叫一个 Job ，多个 Mongodb 叫一个 Job ，所有的主机系统级的监控叫一个 Job ，是这样来进行定义了。第二个概念 Iinstance ，Instance就是一个实例，你可以理解为就是我们所谓的 target ，但是它这个和Instance本身可能还会有一点点的区别，我们把它就理解为概念也可以，它其实就是具有类似功能的 Instance 的集合就成为一个 Job ，那因而这个时候 Instance 就可以完全理解为就是一个 target 。好了，这是 Prometheus 的两个非常重要的概念，那等一会我们去使用 Prometheus 监控的时候，第一就是我们要准备好 target ，每一个 target 就是一个 Instance ；第二我们把同类的 target 组合在一块，给它用一个 Job 来进行归类在一起进行管理。 Prometheus 就是非常灵活，但灵活及责任或者自由及责任这个大家知道的。
5. PromQL
第二个概念 PromQL ：刚才讲过了 Prometheus 的内部的各种各样的指标数据，那我们要对指标数据进行过滤的话，就得用 Prometheus 内置的数据查询语言叫 PromQL 来完成。 PromQL 支持两种向量的处理，并且还提供了一组用于数据处理的函数，来帮助我们对于样本数据做基础的，注意是基础的分析，真正要做 AI Ops ，那可能我们自己需要设计算法 AI 算法，利用机器学习和深度学习的方式来分析我们的系统，来预测我们系统接下来的运行走势。 Prometheus 内部支持两种向量或者叫两种获取数据的格式，第一种叫即时向量，第二叫时间范围向量，也有人称为叫时间区间向量。那我们把它怎么称呼就可以，第一个我们称为叫 Instant vectors ，第二个称谓叫做 Range vectors ,我这样给你描述下它的基本语言。那这是我们的 PromQL ，大体上我们对 Prometheus 的基本的工作逻辑已经说差不多了，最后我们来说一说 Prometheus 的告警功能。
6. Prometheus 的告警功能
还是那句话，抓取指标数据，有些指标有可能会出现异常值，而后一旦出现这种异常，被 Prometheus 发现了，发现就是通过告警规则发现的，那这个时候 Prometheus 对于每一个样本数据或者对于我们配置的那个样本数据基于某个表达式做分析，如果这个分析的结果超出了我们预料的合理范围，那我们认为它就是异常值。
Prometheus 支持通过告警机制向用户发送反馈或者警示，以便用户及时采取措施，这应该是我们的告警系统的一种事后监控或者叫事后采取处理机制的一种办法，我们说过正常如果用的好的监控系统，你应该有一些事先预测到系统异常并提前采取措施的办法。那是题外话，我这里不描述了。而 Prometheus Server仅负责生成告警指示，具体的告警操作和告警信息的发送则由 AlertManager 来负责，有点不一样记得。而 AlertManager 接受到Proserv，我发了告警指示以后，会基于用户定义的告警路由，路由从根开始向下是一个树状结构，然后像我们的 receivers 去发送告警信息，那至于 receivers 通过何种media来接收告警信息接收notification，那要取决于用户的定义。
我希望这里 Prometheus 的概念给大家说清楚了，我不知道说清楚没有，我再做个简单重复 Prometheus Server，来对标一下我们的这个监控系统，它内建了抓取数据样本采集器，然后你可以告诉 Prometheus Server到哪个被监控系统上或者哪个被监控的目标上去采集指标数据，采集完以后 Prometheus 自己存储在自己内建的时间序列存储当中，然后提供了 PromQL 支持查询和过滤操作，也支持我们定义出规则来作为告警规则，他自己自我去分析，持续的去监控着每一个样本数据，去分析是否有异常值发生，一旦有发生，将告警信息通知给我们的 AlertManager， 由 AlertManager 发送告警信息，同时他也支持通过 PromQL 对接外置的 UI 比如 Garafana 来做展示功能。因而采集和存储它自己可以搞定，展示和告警需要借助于辅助的 AlertManager 和 Garafana 来完成。另外真正去采集数据的时候，虽然自己能有采集或叫抓取的功能，但是被抓取的指标数据一般是来自于我们所谓的 Exporter 当中或者由 Instrumentation 来完成的，就是所谓叫指标数据暴露器或者是应用程序自己内建的测量系统来完。你不要把它想得过于复杂，测量系统就像我们的汽车，通常也有个仪表盘，你可以理解为我们发动机自己内置的一个测量系统，它会显示你的发动机的温度、油量、速度等等，并通过一个仪表盘展示给我们，那我们可以认为说在这个车内部就一定有个测量系统，不然他怎么知道你的时速、怎么知道你的油量。所以这就叫测量系统。各位是不是可以基本明白了。
三、部署 Prometheus
接下来我们就开始正式的去部署一个 Prometheus ，我相信很多同学也就等待这一刻了。其实部署 Prometheus 实在是一个很简单的事情，因为 Prometheus 本身使用Google Go语言研发的，他是受启发于 Borgmon 。很多同学应该应该听说过，各位知道在 Google 内部有一个非常著名的容器调度系统叫 Borg ，应该说它的克隆版叫 Kubernetes ；另外一个就是 Borg 的监控系统叫 Borgmon ，然后对应的克隆的或者山寨的版本，这叫 Prometheus ，希望大家明白这个逻辑。那么所以 Prometheus 也无比适配的或者是到我们的这个 Kubernetes 的监控或者 Kubernetes 统的监控之上，那它也使用 Go语言研发，在构建成二进程程序以后，它几乎没什么别的依赖关系，我们直接把这个应用程序拿到本地，它表现为一个统一的或者有限几个二级的应用程序，直接拿过来运行就完了。
我现在切换到我的操作界面上来，所以我们如果想去使用 Prometheus ，那直接下载 Prometheus 就好了。那我们去搜索一下 Prometheus 关键词，打开Prometheus的官方站点叫 prometheus .io 。那当然他这里会有很多介绍，如果我们想去使用 Prometheus ，我们只需要切换到它的download界面去下载它的最新版本，或者去下载符合我们所需期望使用的版本即可。事实上 Ubuntu 系统服务器在它的仓库当中有 Prometheus 的DB格式的包，我们直接使用APD instore 就能安装上去，那如果是 CentOS 系统的话需要做一些额外配置，才能基于 rpm 包或者基于我们的 yum或者是dnf工具进行安装。如果想在 CentOS 使用rpm包或者使用就是所谓使用yum或者dnf包管理器进行安装的话，那我们要使用 packadecloud 所提供的仓库来进行安装。
它其实可以理解为是我们的云端的包的构建和存储工具，其实就是一个制品库。然后我们配置一个yum repository 的post文件，我相信各位应该理解我说的是什么，那我们就可以在本地使用 yum instore 去安。，我们这里采用一个比较粗糙的安装方式或者比较原生态的安装方式，我们直接到官方站点上去下载它预制的二进制格式的程序包来进行安装。那这个预制的二进制程序包在 download 的界面上这里有个 Prometheus ，这其实就是我们所需要的打包好的这个对应的格式，而后我们选择适配到我们系统类型，适配到我们平台格式的版本，然后他就帮我们过滤好了这个对应的文件，无脑下到本地直接展开， GO 语言研发没有什么依赖性，直接运行。所以很简单。
我这里有下载好的，为了节约时间，我提前下载了一下，那多种组件都下载好了，所以就以这里的Prometheus 为例，我们现在用的是2.24.1的版本，那我们可以使用 tar 去展开 Prometheus 。熟悉我课的同学或者熟悉我使用风格的同学应该知道，我通常习惯把它放在usr local 这样的路径下。我们使用 tar xf指定展开格式以后，展开到user local 这样的目录下，这里它会带着对应的版本和使用的平台的这样的后缀，那我可以使用 ln-sv去链接为 Prometheus 。
接着塞到 Prometheus 里来，就是这样的一个程序， promtool 是他的一个辅助工具，主配置文件叫 Prometheus.yml 。见名知意，顾名思义它是一个 yml 格式的配置文件，这种格式配置文件对我们来讲现在是用的非常多，而且是非常直观的配置。
对于我们 Prometheus.yml 来讲，我们来看一下它的初始配置文件的定义。
其实也没什么特别难理解的地方，各位能够看到它指明了每隔多长时间，我们去抓取一次指标数据默认是一分钟。它官方所提供的预制报告改成了十五秒钟，我记得默认应该是一分钟，这写的也有Default is every 1 minute。接着evaluation intervals，你可以理解为就是它内置定义的那个记录规则和告警规则的评估周期，我们后面讲到告警规则和计数规则或者称之为叫查询持久化的概念时，会将到这个概念。接着底下是我们的告警系统或者 AlertManager 如何对接到 Prometheus 的配置，后面我们后面再讲。 rule_files 这是如何载入外置部分的文件，那些文件中可能保存的有记录规则和告警规则，这些规则是什么？其实就是我的 PromQL 的查询语句，后面我们会将的，别着急。关键我们要关注的是这，叫 scrape_configs ，就是我们要监控了，刚才说过监控的一个最重要的功能叫指标数据的采集，那怎么采集？ scrape_configs 就是我们的指标数据抓取、刮擦或者叫采集的相关的配置。在这个配置当中最为重要的现象，大家记住这几个概念就行：第一 Job ，我们要配备一个Job ，在一个 Job 下可以有多个target，我们target可以是静态定义的，也可以是基于服务发现、自动发现的。
我们这里就来给大家看一看我们如何去配置这里所谓的刮擦的目标：假如说我这里大家看到了还准备了另外一个主机，我这里一共有三个主机node 01，node 02、node 03。我们期望我们的 Prometheus 能够监控这三个主机级的指标数据的话，那我就需要在三个主机上去安装另外一个组件叫做 Exporter ，而且这个 Exporter 是节点级的Exporter ，叫nodeExporter 。其实为什么要这么搞？原因很简单，我再做个解释不知道各位能不能听明白：刚刚讲了， Prometheus Server是通过 HTTP 调用或者叫 HTTP 协议到被监控系统上抓指标的，而 Linux 主机内核很显然并没有内置任何 HTTP 服务器，所以我们内核并不支持直接通过 HTTP 来抓内核指标了，那怎么办？我们就需要在每一个被监控的 Linux 主机上部署一个nodeExporter，由这个nodeExportee 于本地拿到内核中的各种内核参数的状态信息，而后再通过Prometheus兼容的指标格式暴露给 Prometheus Server。与此同时 Prometheus 自己也内置了 Instrumentation 叫测量系统，那就它默认监听在9090上，而且通过 metrics 来输出指标数据，那也就意味着说我们部署完以后直接基于默认的配置文件启动 Prometheus 就可以。各位来看，直接启动 Prometheus ，启动完以后我另打开一个终端来看，它会监听在我们的9090这样一个端口上，通过 HTTP 协议对外提供服务，而且这个9090端口有一个URL叫做 metrics 或者还有个part metrics ，它暴露了 Prometheus Server 这个程序自身的指标数据。我们来访问一下试试，各位来看：比如说那我换个浏览器，我是用 Edge 浏览器，我当前主机地址是172.29.1.11，所以我上172.29.1.11的9090，跟上 metrics 这么一个特定的路径。各位能看到这里有大量的指标数据存在，对每一个指标数据它会有两行信息提供说明，第一这个指标是用来干什么的，一个description或者一个summary；第二，介绍一下这个指标数据的数据格式，所以叫 TYPE ，希望各位能看得懂。那这下面有很多指标数据，我们每一次抓取对应的 target ，就会把这些所有指标都提供给 Prometheus ，我不知道这样讲大家能不能听明白，我再重复一遍，这些概念对我们使用 Prometheus 来讲至关重要。每一个被监控的就叫target，大家发现一个target 可以用一个IP地址和一个端口到达，每一个 target 上都可能会有多个指标， Prometheus 的每一次指标数据的采集周期都会把些这所有指标一次性的提供给 Prometheus Server 。 Prometheus Server 需要存下来，而对于每一个指标而言，一次采集就有一个数据项，一次就有一个数据项，所以多次采集就会生成时间序列，我觉得我应该说明白了。接着对于 Prometheus 来讲，它还有自己的内建的一个 UI 界面，我直接去访问这个9090的根路径，那就会打开这样一个界面。
在这个界面下，它会显示这样几个信息。这个组件我们称之为叫做 Prometheus 的表达式，浏览器默认进入的。但除此之外它还有几个导航的标签，比如说我们可以去看看内建的时间序列数据库的状态叫 TSDB 的status，也可以看看我们定义的记录规则，也可以看看发现了target。这里告诉我们本地主机的9090端口，其实就是 Prometheus 自身被作为 target来使用了，那也就意味着它就是我们的监控目标之一。对每个target而言，你也可以理解为它也是个指标，也有自己的label，那这些就是我们将来可以过滤的基准。回到我们的主界面，这里就是我们可以使用 PromQL 了。各位来看，比如说如果我们想去获取某个数据，它默认我们只要把这个项 Enable autocomplete勾上，它会显示可置的各种指标数据，选择任何一个指标，比如我自己写一个
prometheus_http_requests_total，那这里你可以理解为他就是记录了我们 Prometheus 自己所接收到的 HTTP 请求的时间序列。注意，我们这样默认它会显示出在该指标名称下，
每一个时间序列的当前样本值。
prometheus_http_requests_total我们称之为叫指标名称也叫键，后半部分我们称之为叫做标签。一个键加一组标签的集合就代表着一个时间序列，对于该时间序列来讲，当前的这次采样值是几。，我们可以再执行一次，很有可能这值会发生变化，因为它后一次的采集之后，因为这次刷新会发起了新的请求或再次发起了请求，因此这个数据会不断的在上涨，这是 Prometheus 自身接收到了HTTP请求的相关的数据的记录，结果都看到了，这就是 Prometheus 的相关的指标数据，当然我们也可以自己给它附加条件：附加什么条件？你比如我们只想看一看响应码是302的指标，我们可以使用 code=302，这其实就是一个叫做指标过滤器，也就是我们所谓叫 PromQL 。大家看，这次查询就只有一个时间序列符合我们的查询期望，进而得到了我们这次的查询的结果，这里{code=302}就叫做 PromQL 的表达式。其实我们学习 Prometheus 最重要的就是构建这么个表达式，当然它很显然没有这么简单，因此我们明天的课程当中所讲到的 PromQL 才是学习 Prometheus 当中最为重要的组成部分，剩下的无非就是在实践当中如何把 Prometheus 的概念投射到我们自己的具体需求当中。
大家先有一个基本认识，接下来我们来看一看如何能够把节点自身也纳入到监控系统中来，进而让我们了解如何配置一个 Job 和一个 target 的。回顾一下我们前面讲的一个概念：对 Prometheus 而言，每一个被监控端要想能够正常抓取其指标，有三种方式，第一通过 Exporters 来完成；第二，如果应用程序自己内建了测量系统，通过这个内建测量系统就可以。其实是 Prometheus 就是一个内建的测量系统的服务，我刚才没有额外装任何东西，他自己通过9090端口的 metrics 路线就输出了；第三 Pushgateway 这通常对那些需要推送指标的短生命周期的应用有用。接下来我们就通过第一种类型当中的一个最著名的代表。因为我们监控系统讲过了，监控体系还有印象吗？自底而上有这么几个程序要监控，首先你应该监控我们操作系统，自身包括网络，其次我们监控这个操作系统之上所运行的中间件或者基础设施类的服务，再次监控业务级别的应用程序，最后甚至可以监控业务层自己内部的交易数据，比如像 QPS 、DAU 的日活、转化率等等。回过头各位来看，所以在我们 Prometheus 上，我们要监控我们操作系统本身。以 linux 为例，包括 Prometheus 本身这个主机为例，装一个叫做node Exporter的组件，nodeExporter可能会适配多种不同的系统，我们这里选择 All。然后我们来看我们的node Exporter，能看到这里有适用于Macos的，net bsd 的，还有适用于 linux 的，事实上甚至可能还会有其它系统。我们下载适用于 linux 系统的这个node Exporter，它就能把我们系统的内核中的各种数据输出给我们的 Prometheus ，比如像CPU的用户空间的比例、空闲比例等等这种各种各样的这种数据，对你可以理解为node Exporter 就是一个监控的专用的 agent ，我们把它称作指标暴露器，这是 Prometheus 当中的非常重要概念，如果在 Zabbix 中就相当于 Zabbix 的agent。第一个问题我们讲了这就是一种内省机制，那如果系统自己没有内建，我们只好通过辅助工具来实现。这里我已经下载好了一个组件，所以我们就安装到本地，同样是 Go语言开发，所以直接展开于本地直接运行即可。那于是我们使用 tar xf 展开 nodeExporter 这个我们甚至说展开完以后都不用做什么特殊配置。他就一个应用程序，我把它展开完以后，把里面那个二进制程序给他复制到 usr_local_bin 目录下，这样还好去加载。直接另一行 node Exporter，当然在这之前我们使用 gank help 来看一下它内部要能输出哪些指标，比如我可以输出磁盘的、输出CPU的、输出内存的，哪些你想输出就指定到 cellector ，哪些不想输出我把它disable 掉，想输出我们把它enable 弄起来就行了。因此现在就可以使用node Exporter ，直接回车就可以，不过他可以工作的前台为了便于后面使用，我们也可以把工作的后台这儿给大家提供一个Unitfile 便于各位使用。
这里可以理解为我们安装以后，把它运行在后台。复制下来。粘贴一下，然后创建为一个 Unitfile 就能运行起来了。我先手动跑一下试试看， node Exporter 就直接启动。它会监控什么？Arp 、Be Catch 这些都是默认启用的 collector ，那有些默认，没启用的，我们想启用的话再自己去添加，你比如说这个是示例性的文件当中，就把这四个默认没启用的，像 ntp 、mountstats 、 sysyemed 、 tcpstat 都启用起来了，你想想启用什么自己定义，在后面使用_collector .加那个子系统就可以了。这里正常已经能够工作起来了，我这里再复制了一个终端使用 ss -tnl ， node Exporter 默认监听在9100端口上，事实上他也通过 metrics 来输出指标数据.我们来看这次我们使用到172.29.1.11的9100端口，跟上 metrics ，这个路径也有指标，不过这个指标是我们的 node Exporter 所输入的系统指标，node CPU seconds total 就是 CPU 自己抓取的 CPU 的标数据，比如他空闲比例有多大？处于 io wait 内部的时间长度，irq 的时间长度等等有这么多指标数据。很显然我们只需要把这个指标让我的 Prometheus 能抓取，它就能通过表达式浏览器让我们去过滤这些指标了，那怎么能够让他去抓取？我们来看，我们切换到 Prometheus 的配置路径下去编辑它的主配置文件， Prometheus .yml 定义法很简单，在scrape之下，我们自己定义一个 Job ，使用 Job name 给一个名称，比如就叫做 nodes ，意思是这时候我们要监控的各个节点了，你可以再来注释。就是 All nodes按需来定义就行。这是第一个。Job name 一定要指明我的 Job name 同一个配置当中，在同一个 Prometheus 之上要唯一。第二，指明我们的配置文件或者我们的目标主机怎么配置，怎么生成， static 是最为简单的方法，就表示我们要静态给定。对于静态给定而言，列表格式可以给出多个不同的 target 的定义，而且对 targets 而言，他的数据也是列表格式的，那我们同样可以以列表格式给出，比如我们有一个主机，我们已经定好了，就是本金叫172.29.1.11，而且它在9100端口上，就刚才我们在浏览器中间访问的，任何一个地址加端口能拿到指标的我们都认为它就是一个target，然后我们可以把同一类 target 放在一块，因为前面这个是监控 Prometheus 的自身的应用程序，而不是节点，所以我们额外建一个专门的节点叫nodes 。我们 target 只有一个，其实我里这给大家准备了三个可被监控的系统，一个是11，一个是12，一个是13这三个主机，那另外两个我 node Exporters 还没安装，我现在先把它预备到这。那于是我们就有三个 target ，我们纯粹静态配置的它有没有我们都得先写上，可以这么去理解。
我们保持退出以后，就可以重启一下我们的 Prometheus 。于是我们把此前启动的这个 Prometheus 给它终止掉，再重新启动一次。回过头来，我们再看我们的 Prometheus 的这个图形界面，就在9090这个界面上，我们选择 state 之下的targets ，你能看到这里有这样几个target就显现在这了：
就是我们自己手动指定的那三个 targets ，它归类到 nodes 当中，一共有三个，其中有一个处于up状态，即172.29.1.11的9100，up表示它当前处于正常工作状态这种配置，但另外两个主机没有监听的端口，更别提输出指标数据，所以它的状态为 DOWN 无法抓取到。按照正常逻辑来讲，如果我们配置了告警规则，配置了告警工具，那这里就应该发出告警信息的，向用户告警你的主机当机了，快过来收拾收拾大概意思就这样的概念。我们这还没有配置这样的主机，所以就不用搞那么麻烦。怎么监控容器，我们后面会讲到服务发现的机制，尤其是我们会讲如何结合我们的 Kubernetes 来进行监控，而且我们会讲如何进行重新达标，过滤哪些不监控哪些进行监控，这些搞不懂，后来就会更麻烦。
