Prometheus 监控目标为什么要自动发现
频繁对Prometheus配置文件进行修改，无疑给运维人员带来很大的负担，还有可能直接变成一个“配置小王子”，即使是配置小王子也会存在人为失误的情况。
Prometheus支持的多种服务发现机制
Prometheus数据源的配置主要分为静态配置和动态发现, 常用的为以下几类：
- static_configs: 静态服务发现
- file_sd_configs: 文件服务发现
- dns_sd_configs: DNS 服务发现
- kubernetes_sd_configs: Kubernetes 服务发现
- consul_sd_configs: Consul 服务发现
- ...
kubernetes 频繁更新的pod，svc，等等资源配置应该是最能体现Prometheus监控目标自动发现服务的好处。
Prometheus基于consul自动发现监控对象
Consul是一个分布式k/v数据库，是当前比较流行的服务注册组件，下面对consul+prometheus自动发现监控目标大致流程做个介绍。
- 通过在consul注册服务或注销服务（监控targets）
- Prometheus 一直监视（watch）consul服务，当发现consul中符合要求的服务有新变化是更新Prometheus监控对象
Prometheus主要配置prometheus.yml中的scrape_configs以及consul_sd_configs如下：
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
- job_name: 'consul'
consul_sd_configs:
- server: 'localhost:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*,prome,.*
action: keep
- source_labels: [__meta_consul_service]
target_label: job
- scrape_configs 配置数据源
- consul_sd_configs 基于consul服务发现的配置
- relabel_configs 重新标记
consul_sd_configs的相关relabel通过下面实例来说明。Prometheus安装这边不说明了，到prometheus目录启动即可：
./prometheus --config.file="prometheus.yml" --web.listen-address="0.0.0.0:9090" --web.enable-admin-api --web.enable-lifecycle &
--web.enable-admin-api 运行通过web方式管理prometheus（删除清空数据等操作）
--web.enable-lifecycle 运行通过web方式重新加载prometheus配置（相当于reload）
我这里懒得配置腾讯云安全组规则了，直接nginx反向代理暴露一个80端口出来，配置如下:
server {
listen 10.135.13.136:80;
server_name p.iloxp.com www.p.iloxp.com;
resolver 8.8.8.8 8.8.4.4 valid=300s;
location / {
limit_req zone=allips burst=5 nodelay;
proxy_pass http://127.0.0.1:9090;
}
include agent_deny.conf;
location ~ /.ht {
deny all;
}
}
启动一个consul服务
consul安装比较简单，下载二进制放在/usr/local/bin/目录下即可使用consul命令启动一个agent，consul 集群需至少启动一个server agent，下面是我单机启动consul server的一个示例：
consul agent -server -bootstrap-expect 1 -data-dir=/data/consul -node=server1 -bind=127.0.0.1 -client=127.0.0.1 -ui & consul将默认侦听TCP 8500端口，-ui表示启用web。
我这里懒得配置腾讯云安全组规则了，直接nginx反向代理暴露一个80端口出来，配置如下:
server {
listen 10.135.13.136:80;
server_name c.iloxp.com www.c.iloxp.com;
resolver 8.8.8.8 8.8.4.4 valid=300s;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8500;
}
include agent_deny.conf;
location ~ /.ht {
deny all;
}
}
测试整个流程
向consul注册一个服务作为prometheus的监控target
curl -X PUT -d '{"id": "node-10-135-13-136_test","name": "node_exporter","address": "10.135.13.136","port": 9100,"tags": ["prod","prome","node"],"checks": [{"http": "http://10.135.13.136:9100/metrics","interval": "35s"}]}' http://localhost:8500/v1/agent/service/register
检查consul和prometheus是否已有对应target：
这是注册我本机node_exporter的示例，到grafana里面看下是否能获取，上面图片黑色部分能看到consul与prometheus relabel各个配置的对应关系。
按理说是能看到监控数据有中断的图片，由于我刚刚重新注册、注销consul服务的时间间隔太短了，所以看不出来，在grafana下的效果如下：
从consul中注销刚刚注册的node_exporter prometheus 监控目标：
curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/node-10-135-13-136