开发者学堂课程【3天吃透 Prometheus：Prometheus 基础】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18453
Prometheus 基础
9、向量匹配
在 Prometheus 内部，有一对一的向量匹配，也有一对多或多对一的向量匹配，我们可以把两个向量做组合，它会以左侧为标准以右侧为标准进行聚合，聚合时可以是精确匹配进行聚合。有一点不一样的地方在于，我们有精确匹配聚合，有一对多或者多对一聚合，其中一对一表示从左右两个集合中要找精确匹配的标签的样本，而一对多或多对一表示左侧可以有一个但右侧有多个值，也可以是右侧有一个但左侧有多个值。
要想能够监控多个目标，通常情况下，应该把每一个被监控的主机或者节点都包含进来，target 本身可以不只是节点，也可以是关键应用程序，每一个都可以被作为 target 使用。这里准备了三个主机：node01、node02 和 node03 。节点1上运行的有9100，这表示 node exporter 监听的端口，节点2和节点3上也有。现在把节点上各自运行的 node exporter 都添加为 Prometheus 的监控目标。对于 Prometheus 而言，为其添加 target 的方式有两种，第一是静态配置，第二是动态发现。先来看静态配置，这里使用 static-configs，使用 targets 来列出每一个被纳入到监控目标的 target 的地址和对应的端口。node exporter 默认监听的是9100端口，因此，可以直接指定9100 。另外，他会默认假设每一个 target 都使用 metrics 的后缀作为指标暴露或指标采集的端口。如果默认的不是这个值，则需要使用 metrics path 特别进行指定，多数情况下，对应的 Prometheus 监控系统都会使用 metrics 路径。定义好之后，使用 Prometheus 直接运行起来来访问对应的 Prometheus 的服务，去找 states，targets，可以看到，三个端点就被添加进来了。在第一次采集到对应指标数据之后，如果能够正常获取数据，就显示为 up 状态。其实，每一个 target 都会有一个标准的称之为 up 的时间序列。回到 Prometheus，使用 up 这个指标，就可以发现每一个 target 都有一个 up 的时间序列，它用来表示当前的 target 是处于正常的还是非正常的，1表示正常，0表示非正常。这就是静态配置机制。
正常情况下，我们理解的能被 Prometheus 监控的被监控端都可以基于静态配置的方式来给定监控机制。需要注意的是，如果 IT 信息系统是变动很小的话，显然静态配置是最容易使用的方式。如果 IT 信息系统变动很大的话，经常会加减 target，尤其是容器环境下，就随时可能会创建或销毁容器实例，这种情况下，手动编辑文件加减 target 就很麻烦。因此，这种静态配置机制就不适用了。就算是 IT 信息系统较为稳定，也比较推荐利用 Prometheus 的服务发现功能来进行发现。
三、Service Discovery
基于文件的服务发现
基于文件的服务发现是仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式。要想实现基于文件的服务发现无非另外建一个文件放入 target，让 Prometheus 基于另外的文件加载到 target。好处在于，可以在这个文件当中变动 target，Prometheus 可以周期性的重载这个配置文件，进而了解到新的 target。
另外，server 可以定期从文件中加载 target 信息，所以，更改时不需要重启 Prometheus server 就可以生效。这些文件一般是由另外一个系统生成，例如 puppet、ansible 或 saltstack 等配置管理系统，也可能是由脚本基于 CMDB 定期查询生成。因而，完全可以尝试用 Ansible 来获取整体系统中可以被监控的所有的 target 来生成这个文件，而后可以定一个周期性任务计划，周期性的从 ansible 的资产库中去读取对应的可以被监控的所有 target 来生成对应的静态文件。基于此，就可以实现基于文件的静态服务发现。他也有一定程度上的动态效果，并且不依赖于任何第三方服务，所以算得上比较好用的配置方法。
要想实现基于文件的服务发现，在 scrape-configs 当中的每一个 job 上，要使用 file-sd，file 就是基于文件的服务发现配置指定从哪个文件中加载被监控对象。接着，每隔多少时间重载 target，默认是5分钟，如果想让它更快些，也可以设定为2分钟。
现在可以看见我们这个系统中监控了两类 job，一个是 Prometheus 自身，它使用9090端口来获取 Prometheus 自己的 metrics，第二是监控的三个主机，它通过 node exporter 对接到 Prometheus 自身以及node01 node02 和 node03 这三个主机上来。接下来演示的内容都会在 git 仓库提供给大家，使用时在线克隆就可以获取。
可以访问 gitlab.magedu.com/ 的Prometheus-configs 仓库。接着，对应的获取即可。这个仓库中有一个 files-sd 的目录，这里边创建好了一个 Prometheus.yaml 的配置文件和一个 target 的目录，在 target 之下，把静态监控时使用的第一个 job 的 target 放在了 prometheus.servers.yaml 的文件当中。可以看见，这个文件的格式是 target 指定了地址和端口，人为的添加了几个端口，app:prometheus,job:prometheus 。第二个是在 target 目录之下的 nodes-linux.yaml，它一共有3个主机，以列表格式在 target 下直接给出，指定地址和端口，再加上一个 app：node-exporter 和一个 job：node 的 lable。接着，把 file-sd 目录直接复制到安装目录下。
随后，切换到安装目录，就有一个file-sd，在这里就有我们打算使用的主配置文件。Prometheus 对应的 target 的加载方式已经是基于文件的服务发现。文件是当前 target 目录下以 /prometheus 为前缀，以 .yaml 为后缀的任何文件名，这里支持文件名统配。而后，每隔两分钟去重载文件，看对应的 target 是否发生变动。接着，另一个 job 叫做 node，在 node 之下，可以看到对应的仍然使用基于文件的服务发现，他会连同另一个文件一起加载，以 nodes 为前缀，以 .yaml 为后缀的文件都作为去加载 target 的文件名。而后，refresh 依然为两分钟。
定义好之后，直接让它在 files-sd 下运行，于是，再一次运行 prometheus 时，我们使用 --config.files= 就告诉我们配置文件在当前目录的 files-sd 下，我们使用这个 Prometheus.yaml 的主配置文件。因为这个配置文件它会从当前所在目录的去加载被监控的主机，因而，就会产生动态效果，Prometheus 又一次的运行起来了。可以看到 Prometheus 的 target，依然是有3个 target，在 Prometheus 这个 job 下，有一个 target。更重要的是，它一定是通过文件服务发现进来的。因为在发现服务中，加了一个特殊标签，显示为--开头的标签，这就代表了这是基于文件服务发现获取的指标。如果把某个 target 删除，它会自动移除。
切换到 files-sd 内部，编辑 nodes-linux.yaml ,删除第三个主机，最多两分钟，它就可以反映到监控系统中。也可以添加文件，随后一旦发生重载，这些文件就被加回来了。这就是基于文件的服务发现，显然比编辑主配置文件看起来好很多。事实上，有一些信息系统中本身就有着服务总线，这些服务总线也可以作为 Prometheus 发现使用的总线。
基于 DNS 的服务发现
DNS 有一种资源记录叫做 SRV，它能指明在哪一个端口上对应的有哪个 service，所以，完全可以基于 DNS 服务中的 SRV 记录，让 Prometheus 去发现哪一个 target 之上的对应的哪个端口上是 exporter。Prometheus 完全可以基于 DNS中的 SRV 记录来做服务发现，只需告诉 Prometheus DNS 服务在哪里，手动的或用程序自动的去操控当中的 SRV 记录和对应的A记录就能完成服务发现。
基于 DNS 的服务发现针对一组 DNS 域名进行定期查询，以发现待监控目标。该发现机制依赖于A、AAAA 和 SRV 资源积累，且仅支持该类方法，尚不支持 RFC6763 中的高级 DNS 发现方式。要想基于 DNS 的服务发现，必须指明基于哪一种资源类型进行服务发现而后对应的端口。一般而言，这里必须要指定 SRV 资源记录的名称。
Consul 基础
Consul 是一款基于 golang 开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能，提供服务注册/发现、健康检查、Key/Value 存储、多数据中心和分布式一致性保证等功能。假设使用的是 consul 服务总线，首先，得有一个 consul 服务，为了更好的演示，把刚刚那些服务功能，包括 Prometheus 自身以及三个 node 都通过 consul 来配置。先配置一个 consul，把这些都注册到 consul 之上，让 Prometheus 都通过 consul 来加载待监控对象。总而言之，我们的目标就是假设在 IT 信息系统环境中有一个 consul 服务，在 consul 服务上有大量的做了注册的待监控对象，Prometheus 作为客户端连入 consul 服务去了解每一个可被监控的目标，从而查询到对应的组件后，在本地转换成可被监控的 target。部署 consul 的方法是，首先在 https://www.consul.io/downloads/ 上下载 consul，直接展开就可以运行。我们可以直接指定为一个 agent。使用 -dv 表示运行的开发模式，也可以使用 -server 表示为运行的 server 模式，-ui 表示打开它内件的外部界面，data-dir 表示指定的数据目录，config-dir 表示在哪个路径下去加载config。Config 可以是以文件的方式定义好的各个 services 的配置。当然 service 可以基于接口直接提供。Client 表示面向客户端提供服务时监听哪个地址，端口是8500，使用 -bind 来绑定使用的地址，bind 不与必须绑定多地址。
以 node1 为例，因为下载好了 consul，因而直接展开就行。展开consul 后，直接生成 consul 文件，因此直接运行 consul 即可。Consul 有多个子命令，其中，agent 表示作为一个节点加入到集群中，也可以使用 join 加入到 consul 集群中。也可以使用 reload 重载配置文件目录下所有的配置，可以使用 members 查看集群中所有的成员，等等。
要想命令正常运行，必须创建好 consul 下的 data 目录、etc 下加载配置文件时使用路径的目录，就可以正常启动了。正常启动后，就可以访问 ui 界面了，我们要访问的是主机地址，8500端口。内部已经注册了四个服务，切换到 etc 下的 consul 的目录，里面有两个 json 格式的文件，一个是 node.json，通过 services 定义了几个服务，其中每一个服务都有一个 ID、地址、名称和端口。Tags 表示给定服务加的标签，可以在 Prometheus 中基于标签进行过滤，consul 也能对注册进来的服务做健康状态检测，这表示对哪个地址发请求，如果对应的响应码是200，我们就认为他是健康的。所以，我们对健康状态进行检测。
为了看起来便捷，把它挪走到 tmp 下，使用 consul reload，可以发现没有任何内容了，只有 consul 服务自身。所以，通过某一个目录去加载的好处在于，我们能够直接以单个 service 的方式来进行定义有哪些可以注册到 consul 的服务方式，而 consul 可以直接通过来 API 定义。这些示例文件在对应的 consul-sd 的目录下提供就有。
在 consul-configs 有对应的 json 文件，其中 node01.json 是表示这个文件中只定义一个 service，一个文件中只定义一个 service，可以使用 service 这个关键词。顶级的 json 格式是每个 service 都有 id、name、address、port，偶尔会有 tags。如果定义多个 service 的话，要使用 services，并且使用多个 services 用逗号来分割。比如，nodes 文件当中就是用 services，用逗号隔开定义了3个 services，copy node01 到 etc 下的 consul，而后，让 consul 命令重载配置文件目录下的对应的服务。这就是单个 service 的定义方式。如果要定义多个 services，把它添加进来。假设主机被正常注册到 consul 之上，把 Prometheus server 复制到 etc 下的 consul 目录下，这表示 Prometheus 自身使用 consul 加载。服务虽然注册了，但显示为非健康状态，原因在于 Prometheus 未启动。
接下来，我们尝试基于 consul 的服务发现来启动 Prometheus，在 usr/local/prometheus 目录下有一个 consul-sd 的子目录，切换到 Prometheus 目录，启动 Prometheus前， 观察 Prometheus-sd.yaml 的格式，job 还是 nodes，但是对应的服务发现机制变成了 consul-sd configs，指明 consul server 监听的地址和端口，默认监听的是8500端口。接着，给 Prometheus 加了一个叫做 Prometheus 的 tags，因而，标示 Prometheus 时，过滤出来无论有多少个 service，只有那些有 Prometheus tags 的才被识别为 Prometheus server 进行监控。第二，只有加了 nodes 标签的才被识别为 nodes 来进行标识。
因此，对应这个配置文件来看看 Prometheus 能发现多少个 target 并进行监控，配置启动方式依然是 Prometheus 指定 --config=consul-sd.yaml。启动后，再一次访问 Prometheus，刷新后可以看到只有一个 target，原因在于在 consul 内部只配置了一个叫做 prom-server-node01 的 target，因为只有它拥有 Prometheus 标签，其他过滤 node 标签的没有任何。Consul 没有 node 标签，所以它不会被作为监控对象。
现在把另一个准备的文件 node.json 也复制进去urs/local/prometheus/consul-sd 目录下，在 consul-configs 目录下叫做 nodes.json，所以复制 nodes.json 到 etc 下的consul 目录下，再一次使用 consul 加载命令，一旦加载完成，consul 下就出现 node01、node02 和 node03 。接着回到 Prometheus，刷新 target，加载完成后，过滤拥有所有有 node 标签的节点作为 node exporter 的识别方法。正常的新的3个节点就被 Prometheus 动态的纳入到监控系统当中。当然，正常使用 consul 监控系统一定不是这么使用的。
因为 consul 注册的所有服务应该是应用程序或者节点，或者使用其他脚本工具基于 consul 的 API 注册到 consul 上去，演示过程为了降实践低难度，所以使用了一个文件进行加载。如果要使用基于 consul 的服务发现的话，要注意的是标签也有了不同之处，基于 consul 的服务发现，有很多 meta 开头的标签，称之为元标签，里面记录有 consul 的服务地址、consul 实例所处的数据中心，等等。这些标签是可以再做重新打标使用的重要素材。现在就可以基于 consul 进行服务发现。其实，也可以人为的使用 consul 的命令把其中的一个服务给它注销。假如，我们认为某一个服务消失了，从而 consul 监视不到对应的服务了，因此把该服务移除了，这时 Prometheus 就不再监视该节点了。以 node02 为例，人为的将其在 consul 上移除，使用 consul 命令的 services deregister，它的意思是注销。使用--指明注销哪个文件定义的 services，也可以使用-id指定注销哪一个services。以 node02 为例，其 ID 是 node-exporter-node02，以其为例注销，可以使用 consul 命令的 deregister-id=node-exporter-node02 将其注销。
在 Prometheus 上刷新以后，对应的 node02 就消失了。当然，也可以重新通过 consul services registrer 重新注册，指定 etc/consul/nodes.json，就会重新注册。接着在 Prometheus 之上 node02 又出现了。正常情况下，我们应该是调 API 进行正常的注册注销等过程，而我们这只是模拟。因此，基于 consul 的服务发现也就完成了。
基于 Kubernetes API 的服务发现
其实公有云服务一般都有底层的服务注册总线或者资产库，但凡有资产库通过 API 输出的公有云，Prometheus 支持的话，都可以基于 API 来进行服务发现。像 AWS 、亚马逊云这些 API 默认都是支持的。国内的某些云有可能是不支持的，可以通过做一次 Prometheus 的二开就可以完成支持了。国内的某些产家就是通过这样来研发自己的专有软件或商业软件。所以，我们正常使用也是同样的逻辑。事实上，要想使用 Prometheus 监控 Kubernetes，Kubernetes 有很多待监控对象，在Prometheus 之上分别要使用不同的 role 来完成。Prometheus 支持监控 kuberneters 上的这几种对象。第一，要监控 kuberneters 的 node，这有两种方式，第一，在每一个节点上部署 node exporter，第二，Kubernetes 每个节点上通常会部署一个Kubelete，就是 Kubernetes 的 agent，而 kubelet 本身就可以被 Prometheus server 拿来作为监控节点的一个路口之一。虽然它输出的指标不是那么多，但很多时候足够有用。有些时候，会把node exporter 和 kubelet 结合起来使用。
事实上，基于 Kubernetes API 的服务发现机制，支持将 API Server 中的 Node、Service、Endpoint、Pod 和 Ingress 等资源类型下相应的资源视作 target，并持续监视相关资源的变动。负责发现每种类型资源的组件在 Prometheus 中称为一个 role。Kubernetes 的这几种资源类型，每一种都需要使用一种独有的发现机制，这个独有的发现机制在 Prometheus 中称做 role。
