开发者学堂课程【3天吃透 Prometheus：Prometheus 服务发现和重新打标】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18446
Prometheus 服务发现和重新打标
内容介绍：
一、服务发现
二、抓取的生命周期
三、Prometheus 可集成的服务发现机制
四、基于文件的发现
五、基于 DNS 的服务发现
六、基于 Kubernetes API 的服务发现机制
七、各个资源发现时要注意哪些问题
八、重新打标
九、relabel 示例
一、服务发现
Prometheus 算得上是一个复杂的生态系统中的一个组件，我们可以理解为以后我们提到的 Prometheus 主要就是指 Prometheus-server，除此之外，围绕在 Prometheus-server 还有很多组件，比如通过 exporters 进行抓取，或者是通过应用程序自带的 instrumentation （仪表盘）进行抓取，还有一些短期的任务会把自己主动推出等待抓取，抓取的数据存储在 Prometheus 内置的tsdb上，除此之外 Prometheus 还存在 PromQL，我们称之为Prometheus的查询语言，它主要借助于Prometheus自身的指标类型，数据类型等来完成对应表达式的构建，而后从众多数据中过滤出所要表示的数据来。
除了上述之外，Prometheus 还可以自动生成监控告警信息，但是真正要发送信息还要依靠 alertmanager，需要持久化的保存浏览器的查询信息需要借助 grafana 实现。
对 Prometheus 而言，曾介绍过很多作用和功能等，接下来会介绍其他系列的功能。
我们先来介绍service discover 的功能，叫做服务发现。能够被prometheus 发现的节点都是能够静态的配置在文件中的，就是一个 configs 文件。
static configs:
targets :
" master01.magedu. com: 9100"
" node01.magedu.com: 9100"
"node02.magedu.com: 9100"
如果新增节点或者新增 tagets，那我们就不得不重载文件才能完成，这些不需要手动进行。当然这只适用于小规模，如果规模大，那每个容器可能会有多个端点，每个容器就类似于节点暴漏自己的指标，可能会消失，在这种情况下，我们要手动配置配置文件去监控抓取重要数据。这时候 tagets 不是一个重要的选择，接下来要介绍一下 Prometheus 为何要进行服务发现。
Prometheus 为何要进行服务发现?
Prometheus Server 的数据抓取工作于 Pull 模型，因而，它必需要事先知道各 Target 的位置，然后才能从相应的 Exporter 或Instrumentation 中抓取数据。
对于小型的系统环境来说，通过 static_configs 指定各 Target 便能解决问题，这也是最简单的配置方法；（每个Targets用一个网络端点(ip:port)进行标识；）
对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以适用；因此，Prometheus 为此专门设计了一组服务发现机制，以便于能够基于服务注册中心(服务总线)自动发现、检测、分类可被监控的各Target，以及更新发生了变动的Targe。
作为发现服务的最为简单的就是文件，跟我们刚才讲到的静态配置还是有区别的，静态配置就意味着我们自己在配置文件当中写好要监控的各个 target，这叫静态配置，而基于文件的服务发现则指的告诉配置文件有一个文件当中记录的哪些是 target，所以 Prometheus 启动起来以后会加载这个文件，并周期性的刷新这个文件。只要改了这个文件，只要这个文件中定义了端点都会被识别为监控的 target，这是一种叫做基于文件的服务发现。它只是比纯静态文件的方式进步了那么一点，因为我们不需要再去重启或者要人为的向 Prometheus 的进程发送一个 hash 信号，让它重新加载配置文件了，因为它会周期性的自动加载更新的文件。那除此之外基于dns也能服务发现，基于 api各种各样的公有云，比如阿里云，亚马逊云，这种云服务都会有自己的api来输出，甚至给不同的客户。比如你作为一个企业客户在阿里云上注册以后，它会给你提供一个api接口，从这个 api 我能检索出自己所创建的所有虚拟机来，在这种机制之下我们对接的公有云也能够让 Prometheus 抓取到所有可以被监控的 tagets。同样的 k8s 也有自己的 api，这种叫基于 api的发现，但不论是哪一种，这种发现的功能都比纯静态配置要好用得多。所以我们要了解一种系统中可以定义很多个 tagets，然后再进行分析，这种动态的配置方式要好得多。在 zabbix 当中这种运用统统是要进行单独的监控的，但是在 Prometheus 当中就可以定义 tagets 来监控，方便得多。
二、抓取的生命周期
接下来我们介绍指标抓取的生命周期，就是在进行指标抓取时要进行哪些步骤。
下图展示了 Prometheus 上进行指标抓取的简单生命周期。
第一，要先进行服务发现，这个指标一定属于某个 tagets，所以要先通过服务发现这个步骤把这个 tagets 添加到 Prometheus 的监控对象中来，这是第一步，是指标抓取的先前步骤，不过我们之前都是用的是静态，而不是服务发现。
第二步，配置。对于对应的监控发现对象来讲，都要配置这个监控独有的指标抓取周期之类的。
第三，我们可以对这个抓取序列的标签做一个重新打标，这个过程叫 relable configs，我们认为有一些标签不符合我们的期望，我们可以进行重新打标，比如添加标签前，移除标签等等都可以，但是改变标签就相当于创建新的时间处理序列，因为每一个时间序列由标签名和标签来共同决定的。
然后是数据抓取的过程，对于抓取过来的数据我们可以进行重新标记，第一个重新打标是对 tagets 数据进行重新标记，而第二个重新打标是对抓取过来
的数据。
这里解释一下我们使用 up 可以查询对应的 Prometheus 监控的每一个当前的状态，而 tagets 就使用 instance 和job 来进行标记，表示时间序列。这些只代表了 tagets 自身，而 tagets 是有很多指标可以代表的，可以把 up 理解为对应的 tagets 自身的指标，其他指标是在 tagets 之上的指标。因而我们的第一个重新打标指的是对 tagets 自己的标签做标记，一般而言只有两种，一种是 instance，一种是 job，是时间序列的标识。
在每个scrape_interval 期间，Prometheus都会检查执行的作业(Job)；
这些作业首先会根据 Job上指定的发现配置生成 target 列表，此即服务发现过程；服务发现会返回一个 Target列表，其中包含一组称为元数据的标签，这些标签都以“_meta_为前缀；服务发现还会根据目标配置来设置其它标签，这些标签带有“_”前缀和后缀，包括
“_scheme__”、 “_address_”和“_metrics_path_”，分别保存
有 target支持使用协议(http或https，默认为http) 、target的
地址及指标的URI路径（默认为/metrics)；若URI路径中存在任何
参数，则它们的前缀会设置为“_param_”；这些目标列表和标签会
返回给Prometheus，其中的一些标签也可以配置中被覆盖。
配置标签会在抓取的生命周期中被重复利用以生成其他标签，例如，指标上的instance标签的默认值就来自于_address__标签的值。
对于发现的各目标，Prometheus提供 了可以重新标记(relabel)目标的机会：
它定义在job配置段的relabel config配置中，常用于实现如下功能：
①将来自服务发现的元数据标签中的信息附加到指标的标签上；
②过滤目标；
这之后，便是数据抓取、以及指标返回的过程；抓取而来的指标在保存之前，还允许用户对指标重新打标并过滤的方式；它定义在job配置段的metric_ relabel _configs配置中，常用于实现如下功能：
①删除不必要的指标；
②从指标中删除敏感或不需要的标签；
③添加、编辑或修改指标的标签值或标签格式。
三、Prometheus 可集成的服务发现机制
接下来我们介绍 Prometheus 可集成的服务发现机制。
在不同场景中，服务注册中心的指代也会有所不同：
①公有或私有 IaaS 云自身保存有平台上的所有资源信息，其 API Server 便可作为 Prometheus 的服务发现媒介，比如 azure、 ec2、digitalocean、gce、hetzner。
②Prometheus 也可以集成到多种不同的开源服务发现工具上，以动态发现需要监控的目标；比如 Consul、Eureka Zookeeper Serverset 或 Airbnb Nerve 等。
③Prometheus 也可以很好地集成到 Kubernetes 平台上，通过其 API Server动态发现各类被监控的 Pod (容器集)、Service、 Endpoint、 Ingress 和 Node 对象；它也支持基于dockerswarm和marathon两款编排工具进行服务发现；
④Prometheus 还支持基于 DNS 或文件的动态发现机制。
四、基于文件的发现
接下来我们来介绍一下基于文件的发现以及他是怎样实现的。
基于文件的服务发现是仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式;
①Prometheus Server 定期从文件中加载 Target 信息，文件可使用JSON和YAML格式，它含有定义的Target列表，以及可选的标签信息；下面第一个配置，能够将 Prometheus 默认的静态配置转换为基于文件的服务发现时所需的配置：
- targets:
- localhost:9090
labels:
app: prometheus
job: Prometheus
- targets:
- localhost:9100
labels:
app: node-exporter
job: node
②这些文件可由另一个系统生成，例如 Puppet、 Ansible 或 Saltstack等配置管理系统，也可能是由脚本基于CMDB定期查询生成。对于运维工程师来说， cmdb 可以算得上是一个非常重要的监控设施了，cmdb是系统化运维所依赖的重要的系统功能之一，但是很多公司可能是没有的。将资产信息纳入 cmdb 才是后期我们能进入标准化的前提。
这就是基于发现的文件的第一步，我们要编排好发现文件的系统。，第二步发现target的配置，定义在配置文件的job之中：
global:
scrape_ interval: 15s
evaluation_ jinterval: 15s
alerting:
alertmanagers:
- static_ configs:
- targets:
rule_ files:
scrape_ configs:
- job_ name: 'prometheus'
- files: #指定要加载的文件列表;
- targets/prometheus*.yaml # 文件加载支持glob通配符;
refresh_ _interval: 2m #每隔2分钟重新加载-次文件中定义的Targets, 默认为5m；
- job_ name: 'nodes'
file_ sd_ configs:
- files:
- targets/node* .yaml
refresh_ interval: 2m
接下来来模拟一下我们要把配置文件基于纯动态发现的模式该怎么做呢？假设把文件放到安装路径下，我们创建 tagets 目录，创建一个新文件。
接下来进行配置
第一步：
targets:
master01. magedu . com:9100
node01 . magedu. com:9100
node02 .magedu. com:9100
labels:
app: node_ exporter
接下来再创建一个服务器之后：
targets:
master0l. magedu . com:9090
labels:
app: prometheus-server
那这个文件就定义好了，还可以内置或额外开启一些指标的操作。
