标签：serve script http load docke cto meta any 区别
[2020-03-16 11:48:21](javascript:)
在基于微服务，云基础设施监控的场景下，我们会发现监控项是可变的。这个时候我们需要一个基于服务发现的机制。Prometheus提供了很多的发现机制。在最前面介绍基础配置文件的时候，我们也讲过基于文件的发现，但是还需要使用修改文件的这种形式，还是比较麻烦。不过 Prometheus 官方支持多种自动服务发现的类型，其中就支持 Consul。
1、拉取镜像和部署（当然在生产环境，建议大家使用集群的方式）
[root@nn-gx-service-java-99 ~]# docker pull consul
2、启动测试：
[root@nn-gx-service-java-99 ~]# docker run --name consul -d -p 8500:8500 consul
1c59b43c57f54971c9fe2d23d35c2e4c559e3b13b8ffc27dc4ead09f9b6b1e57
访问一下：http://10.10.1.113:8500 consul的web ui 发现成功了就没问题。
3、我们使用API把这里的启动的node_exporter 服务注册到consul：
[root@nn-gx-service-java-99 ~]# curl -X PUT -d ‘{"id": "node-exporter","name": "node-exporter-192.168.191.128","address": "192.168.191.128","port": 9100,"tags": ["linux"],"checks": [{"http": "http://192.168.191.128:9100/metrics", "interval": "5s"}]}‘ http://192.168.191.128:8500/v1/agent/service/register
添加一个docker 的监控：
[root@nn-gx-service-java-99 ~]# curl -X PUT -d ‘{"id": "docker-exporter","name": "docker-exporter-192.168.191.128","address": "192.168.191.128","port": 8080,"tags": ["devops"],"checks": [{"http": "http://192.168.191.128:8080/metrics", "interval": "5s"}]}‘ http://192.168.191.128:8500/v1/agent/service/register
4、服务注销
当然我们要是想注销这个服务，可以直接通过接口的方式删除node-exporter即可：
curl -X PUT http://10.10.2.99:8500/v1/agent/service/deregister/node-exporter
5、配置prometheus 实现自动发现：
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: ‘consul‘
consul_sd_configs:
- server: ‘10.10.2.99:8500‘
1、会发现 Prometheus 同时加载出来了默认服务 consul，这个是不需要的。
2、如果需要自定义一些标签，例如 team、group、project 等关键分组信息，方便后边 alertmanager 进行告警规则匹配，该如何处理呢？
3、所有 Consul 中注册的 Service 都会默认加载到 Prometheus 下配置的 consul_prometheus 组，如果有多种类型的 exporter，如何在 Prometheus 中配置分配给指定类型的组，方便直观的区别它们？
在Prometheus所有的Target实例中，都包含一些默认的Metadata标签信息。可以通过Prometheus UI的Targets页面中查看这些实例的Metadata标签的内容，在第一讲的时候我们也讲过标签的替换，大家可以去看看了解一下：
默认情况下，当Prometheus加载Target实例完成后，这些Target时候都会包含一些默认的标签：
__address__：当前Target实例的访问地址<host>:<port>
__scheme__：采集目标服务访问地址的HTTP Scheme，HTTP或者HTTPS
__metrics_path__：采集目标服务访问地址的访问路径
__param_<name>：采集任务目标服务的中包含的请求参数
Relabeling最基本的应用场景就是基于Target实例中包含的metadata标签，动态的添加或者覆盖标签。例如，通过Consul动态发现的服务实例还会包含以下Metadata标签信息：
__meta_consul_address：consul地址
__meta_consul_dc：consul中服务所在的数据中心
__meta_consulmetadata：服务的metadata
__meta_consul_node：服务所在consul节点的信息
__meta_consul_service_address：服务访问地址
__meta_consul_service_id：服务ID
__meta_consul_service_port：服务端口
__meta_consul_service：服务名称
__meta_consul_tags：服务包含的标签信息
详细 relabel_configs 配置及说明可以参考 relabel_config 官网说明，这里我简单列举一下里面每个 relabel_action 的作用，方便下边演示。
replace: 根据 regex 的配置匹配 source_labels 标签的值（注意：多个 source_label 的值会按照 separator 进行拼接），并且将匹配到的值写入到 target_label 当中，如果有多个匹配组，则可以使用 ${1}, ${2} 确定写入的内容。如果没匹配到任何内容则不对 target_label 进行重新， 默认为 replace。
keep: 丢弃 source_labels 的值中没有匹配到 regex 正则表达式内容的 Target 实例
drop: 丢弃 source_labels 的值中匹配到 regex 正则表达式内容的 Target 实例
hashmod: 将 target_label 设置为关联的 source_label 的哈希模块
labelmap: 根据 regex 去匹配 Target 实例所有标签的名称（注意是名称），并且将捕获到的内容作为为新的标签名称，regex 匹配到标签的的值作为新标签的值
labeldrop: 对 Target 标签进行过滤，会移除匹配过滤条件的所有标签
labelkeep: 对 Target 标签进行过滤，会移除不匹配过滤条件的所有标签
修改Prometheus配置文件：
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: ‘consul‘
consul_sd_configs:
- server: ‘10.10.2.99:8500‘
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: (.*linux.*|.*devops.*)
action: keep ##对没有匹配到的表达式进行抛弃
我们可以配置 relabel_configs 来实现标签过滤，只加载符合规则的服务。以上边为例，可以通过过滤 __meta_consul_tags 标签为 linux,devops 的服务，relabel_config 向 Consul 注册服务的时候，只加载匹配 regex 表达式的标签的服务到自己的配置文件。
要实现给服务添加自定义标签，我们还得做一下修改，就是在注册服务时，将自定义标签信息添加到 Meta Data 数据中，具体可以参考这里(Consul Service - Agent HTTP API) 官网说明，下边来演示一下如何操作。
[root@nn-gx-service-java-99~]# curl -X PUT -d ‘{"id": "node-exporter","name": "node-exporter-10.10.2.99","address": "10.10.2.99","port": 9100,"tags": ["linux"],"Meta":{"app":"linux"},"checks": [{"http": "http://10.10.2.99:9100/metrics", "interval": "5s"}]}‘ http://10.10.2.99:8500/v1/agent/service/register
然后我们打开consul找到Meta Data然后我们会发现已经存在了添加的app:linux的值。
修改配置文件使之生效：
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: ‘consul‘
consul_sd_configs:
- server: ‘10.10.2.99:8500‘
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: (.*linux.*|.*devops.*)
action: keep
- regex: __meta_consul_service_metadata_(.+) #添加meta的重新匹配
action: labelmap #
验证一下：
我们看到我们添加的标签{app:linux}已经生效。
3、问题3：在服务发现前提下如何把这些服务区分出来：
这个需求是，我们直接通过标签匹配的方式把服务区分出来，下面我直接修改配置文件，通过tag来区分。
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: ‘node-exporter‘
consul_sd_configs:
- server: ‘10.10.2.99:8500‘
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*linux.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
- job_name: ‘docker-exporter‘
consul_sd_configs:
- server: ‘10.10.2.99:8500‘
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*devops.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
到此我们consul的基本操作已经完成，当然标签的操作大家可以深入了解。
相比于直接使用静态配置，在云环境以及容器环境下我们更多的监控对象都是动态的。通过服务发现，使得Prometheus相比于其他传统监控解决方案更适用于云以及容器环境下的监控需求。
@版权声明：51CTO独家出品，未经允许不能转载，否则追究法律责任
留言 5
1楼 2020-03-30 11:27:02
1
老师辛苦啦 ，更新的这几节笔记还有上传，麻烦您上传下 谢谢
后面的在git上面有的，可以上去找找相关文档
2020-03-30 15:48:40
回复
2楼 2020-03-30 15:51:50
好的 不好意思 可能没发现
3楼 2020-03-31 10:06:03
1
老师 后面的两节21、22还打算更吗？
21其实已经更新了的，至少这边老师放到新增里面了，其实已经讲了，22这两天补充
2020-03-31 14:55:21
回复
-END-
标签：serve script http load docke cto meta any 区别
原文地址：https://www.cnblogs.com/jinmuqq222/p/14915062.html
