2. prometheus服务发现机制
- 一、 Prometheus与服务发现
- 1.1 目前支持的服务发现方式
- 二、 案例
- 2.1 基于文件的服务发现
- 2.2 基于Consul的服务发现
- 三、本地测试
- 3.1 基于文件的服务发现
- 1.测试环境
- 2.配置文件
- 3.可视化
- 3.2 prometheus.yml热加载
- 3.1 基于文件的服务发现
一、 Prometheus与服务发现
云原生、容器场景下按需的资源使用方式对于监控系统而言就意味着没有了一个固定的监控目标，所有的监控对象(基础设施、应用、服务)都在动态的变化，这对基于Push模式传统监控软件带来挑战。
对于Prometheus这一类基于Pull模式的监控系统，显然也无法继续使用的static_configs的方式静态的定义监控目标。而对于Prometheus而言其解决方案就是引入一个中间的代理人（服务注册中心），这个代理人掌握着当前所有监控目标的访问信息，Prometheus只需要向这个代理人询问有哪些监控目标控即可， 这种模式被称为服务发现。
通过服务发现的方式，管理员可以在不重启Prometheus服务的情况下动态的发现需要监控的Target实例信息。
1.1 目前支持的服务发现方式
# List of Azure service discovery configurations. azure_sd_configs: [ - <azure_sd_config> ... ] # List of Consul service discovery configurations. consul_sd_configs: [ - <consul_sd_config> ... ] # List of DNS service discovery configurations. dns_sd_configs: [ - <dns_sd_config> ... ] # List of EC2 service discovery configurations. ec2_sd_configs: [ - <ec2_sd_config> ... ] # List of OpenStack service discovery configurations. openstack_sd_configs: [ - <openstack_sd_config> ... ] # List of file service discovery configurations. file_sd_configs: [ - <file_sd_config> ... ] # List of GCE service discovery configurations. gce_sd_configs: [ - <gce_sd_config> ... ] # List of Kubernetes service discovery configurations. kubernetes_sd_configs: [ - <kubernetes_sd_config> ... ] # List of Marathon service discovery configurations. marathon_sd_configs: [ - <marathon_sd_config> ... ] # List of AirBnB's Nerve service discovery configurations. nerve_sd_configs: [ - <nerve_sd_config> ... ] # List of Zookeeper Serverset service discovery configurations. serverset_sd_configs: [ - <serverset_sd_config> ... ] # List of Triton service discovery configurations. triton_sd_configs: [ - <triton_sd_config> ... ] |
二、 案例
2.1 基于文件的服务发现
用户可以通过JSON或者YAML格式的文件，定义所有的监控目标。例如，在下面的JSON文件(targets.json)中分别定义了3个采集任务，以及每个任务对应的Target列表：
模板：
[
{
"targets": [ "<host>", ... ],
"labels": {
"<labelname>": "<labelvalue>", ...
}
},
...
]
|
PS:以上targets是必填项。
实例：
[
{
"targets": [ "localhost:8080"],
"labels": {
"env": "localhost",
"job": "cadvisor" #默认是prometheus.yml中配置的file_ds（见下），此cadvisor会覆盖前者
}
},
{
"targets": [ "localhost:9104" ],
"labels": {
"env": "prod",
"job": "mysqld"
}
},
{
"targets": [ "localhost:9100"],
"labels": {
"env": "prod",
"job": "node"
}
}
]
|
创建Prometheus配置文件/etc/prometheus/prometheus-file-sd.yml，并添加以下内容：
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 15s
scrape_configs:
- job_name: 'file_ds'
file_sd_configs:
- files:
- /opt/prometheus/file_sd_configs/targets.json #也可以模糊匹配多个文件
refresh_interval: 10s
|
通过这种方式，Prometheus会自动的周期性读取文件中的内容。当文件中定义的内容发生变化时，不需要对Prometheus进行任何的重启操作。
2.2 基于Consul的服务发现
Consul是由HashiCorp开发的一个支持多数据中心的分布式服务发现和键值对存储服务的开源软件，被大量应用于基于微服务的软件架构当中。
Consul作为一个通用的服务发现和注册中心，记录并且管理了环境中所有服务的信息。Prometheus通过与Consul的交互可以获取到相应Exporter实例的访问信息。在Prometheus的配置文件当可以通过以下方式与Consul进行集成：
- job_name: node_exporter
metrics_path: /metrics
scheme: http
consul_sd_configs:
- server: localhost:8500 #指定了consul的访问地址
services: #为注册到consul中的实例信息
- node_exporter
- cadvisor
|
在consul_sd_configs定义当中通过server定义了Consul服务的访问地址，services则定义了当前需要发现哪些类型服务实例的信息，这里限定了只获取node_exporter和cadvisor的服务实例信息。
三、本地测试
3.1 基于文件的服务发现
1.测试环境
1）export：在m162p84和m162p65两台机器上分别启动两个node_export；
2）prometheus: 通过m162p84机器上的globle Prometheus监控收集node数据 ;
2.配置文件
1）prometheus_main.yml 配置文件
2）targets.json配置文件
以上targets是先后加入，通过查看章节3.可视化部分验证其可自动加载配置文件并生效。
3.可视化
prometheus_UI:
grafana:
3.2 prometheus.yml热加载
我们从上可以知道prometheus支持动态加载，通过file_sd_configs配置将target放置到yaml文件中，当yaml文件中的内容发生变化时，Prometheus会自动更新自身的target，从而实现动态配置target。
同样我们也可以将rule放置到yaml文件中，我们也希望Prometheus能够动态更新rule规则。然而实验中却发现，修改了rule配置文件后Prometheus并不会动态刷新，重启Prometheus后才能生效。
开启配置文件热加载，Prometheus启动时在参数中加入--web.enable-lifecycle(该参数默认关闭)，然后执行curl命令刷新配置：
./执行路径/prometheus --web.enable-lifecycle curl -X POST http://IP:port/-/reload #测试也支持put请求 |
