在前面的文章中，我们介绍了Prometheus基于文件的服务发现方式。这种方式简单易懂，对于小型企业而言，可以较好地满足使用需求。
但在大规模的监控环境中，基于文件的方式往往会面临较多的挑战。首先，由于有大量的实例需要进行监控，运维人员得频繁地对 Prometheus 配置文件进行修改，这会给工作带来很大的负担，同时也容易出现人为的失误。
另外，在大型企业中往往会有细致的分工，服务器部署与监控的管理可能是由不同的团队成员在负责，每当实例部署完成后还需要在人员之间进行信息的传递，这更进一步增加了操作的复杂性。
对此，Prometheus提供了多种动态服务发现的功能，而基于Consul的服务发现即是其中较为常见的一种方案。
一. Consul简介
Consul 是HashiCorp 公司推出的开源工具，产品基于GO 语言开发，主要面向分布式、服务化的系统提供服务注册、服务发现和配置管理的功能。
产品具有以下特点：
1. 服务发现
Consul 的客户端可以注册一个服务，例如 api 或 mysql，其他客户端可以使用 Consul 来发现给定服务的提供者。
2. 健康检查
Consul 可以根据给定的信息，对服务的状态进行检查，并获取服务的健康状态。
3. Key/Value存储
通过HTTP API的方式实现Key/Value存储，可用于动态配置、功能标记、协商等多种场景。
4. 多数据中心支持
支持多数据中心的分布式架构。
二. Consul安装
1. 下载二进制文件，并解压缩。
$ wget https://releases.hashicorp.com/consul/1.10.4/consul_1.10.4_linux_amd64.zip
$ unzip consul_1.10.4_linux_amd64.zip
$ mv consul /usr/local/bin/
2. 启动Consul
$ consul agent -dev -client 0.0.0.0 &注：本文以dev方式启动，用于测试。该模式不适合用于生产环境，因为不会持久化任何状态。
3. 打开浏览器，访问http://<cousul_ip>:8500，可看到Consul已经正常启动，目前只有默认的consul服务。
三. 注册服务
现在我们可以使用Consul的register API 接口，注册相关的服务信息。
示例：本文将演示通过注册node_exporter的实例信息，实现Prometheus的自动发现。
我们在下面两台服务器上安装好node_exporter，端口为9100。
node1: 192.168.214.100
node2: 192.168.214.108此处通过curl 命令调用register API接口，并将实例信息注册到Consul，服务名称为node_exporter。
node1注册：
$ curl -X PUT -d '{
"id": "node1",
"name": "node_exporter",
"address": "192.168.214.100",
"port": 9100,
"tags": ["prometheus"],
"checks": [{"http": "http://192.168.214.100:9100/metrics","interval": "15s"}]}' \
http://<cousul_ip>:8500/v1/agent/service/register
node2注册：
$ curl -X PUT -d '{
"id": "node2",
"name": "node_exporter",
"address": "192.168.214.108",
"port": 9100,
"tags": ["prometheus"],
"checks": [{"http": "http://192.168.214.108:9100/metrics","interval": "15s"}]}' \
http://<cousul_ip>:8500/v1/agent/service/register完成后，打开Consul可以看到服务已经注册成功，服务中包含相关的实例信息。
四. Prometheus配置
在Prometheus配置Job，这里使用Consul的服务发现方式，并配置好Consul接口地址，用于发现Consul中的node_exporter节点。
- job_name: 'consul-prom'
consul_sd_configs:
- server: '<cousul_ip>:8500'
services: ['node_exporter']注释 ：services 用于过滤Consul服务，如果为空，则会获取全部服务信息。
重新加载配置后，可看到Prometheus已自动获取实例目标，并进行监控。
五. 添加自定义标签
使用上面的方式,我们已经可以通过Prometheus自动发现实例并进行监控。但这种方式默认只有instance和job的标签。而在实际环境中，往往还需要增加自定义的标签，用于从不同维度区分实例，并且在alertmanager告警时也需要依赖标签来分组。
对于自定义标签的添加，可通过json文件的方式进行操作。
1. 创建json文件
node1的json文件 ：
$ vi node1.json
{
"ID": "node1",
"Name": "node_exporter",
"Tags": ["prometheus"],
"Address": "192.168.214.100",
"Port": 9100,
"Meta": {
"group": "kafka",
"env": "dev"
},
"EnableTagOverride": false,
"Check": {
"Http": "http://192.168.214.100:9100/metrics",
"Interval": "15s"
}
}node2的json文件 ：
$ vi node2.json
{
"ID": "node2",
"Name": "node_exporter",
"Tags": ["prometheus"],
"Address": "192.168.214.108",
"Port": 9100,
"Meta": {
"group": "mysql",
"env": "dev"
},
"EnableTagOverride": false,
"Check": {
"Http": "http://192.168.214.108:9100/metrics",
"Interval": "15s"
}
}注释：ID 指定实例的唯一ID名称；Name 指定服务名，可以多个实例共用服务名；Tags 指定服务的标签列表，这些标签可用于过滤服务，并通过API进行公开；Address 指定服务的实例地址；Port 指定实例的端口号；Meta 指定服务的元数据，格式为key:value，此处用于保存我们的标签信息；EnableTagOverride 此处禁用服务标签的反熵功能；Check 服务的检查列表，Consul会根据配置信息定时发起检查，确定服务是否正常；
2. 通过json文件注册服务
$ curl --request PUT --data @node1.json http://<cousul_ip>:8500/v1/agent/service/register
$ curl --request PUT --data @node2.json http://<cousul_ip>:8500/v1/agent/service/register
3. 查看Consul，可看到实例的元数据中已包含标签信息
4. 元数据在Prometheus自动发现的过程中，会变成以__meta_consul_service_metadata_开头的标签，如下图所示。
我们可以通过前面介绍的Relabeling（标签重写）功能，将其转换为我们需要的标签。
将job进行如下修改：
- job_name: 'consul-prom'
consul_sd_configs:
- server: '192.168.214.108:8500'
services: ['node_exporter']
relabel_configs:
- regex: __meta_consul_service_metadata_(.+)
action: labelmap5. 重新加载配置后，可看到标签已经生成。
六. 注销服务
当我们某个实例下线后，我们需要把Consul的服务信息清理掉，可通过deregister API 接口+ID号进行删除。
示例：
$ curl -X PUT http://<cousul_ip>:8500/v1/agent/service/deregister/node1查看Cousul ，原有的node1实例已经被清理。
在Consul清理后，Prometheus也会进行同步，实现监控实例的自动清理。
专注于Devops运维技术分享，关注公众号，获取更多精彩内容！
