【云原生】Prometheus 服务自动发现使用详解

目录

一、前言

二、Prometheus常规服务监控使用现状​​​​​​​

2.1 Prometheus监控架构图

2.2 Prometheus服务自动发现的解决方案

三、Prometheus服务自动发现介绍

3.1 什么是Prometheus服务自动发现

3.2 Prometheus自动服务发现策略

3.3 Prometheus自动服务发现应用场景

3.4 Prometheus自动服务发现原理

四、Prometheus 基于文件的服务发现​​​​​​​

4.1 Prometheus基于文件服务发现介绍

4.2 Prometheus基于文件服务发现使用场景

4.3 基于文件服务发现配置说明

4.3.1 核心配置文件模板

4.3.2 核心配置文件支持格式

4.3.3 基于文件服务发现动态更新机制

4.4 基于文件服务发现操作实践

4.4.1 环境准备

4.4.2 添加Prometheus配置信息

4.4.3 编辑自动发现文档

4.4.4 重新加载Prometheus服务

4.4.5 自动发现文件添加新的监控指标

五、Prometheus基于Consul的服务自动发现

5.1 Prometheus基于Consul的服务发现介绍

5.2 Prometheus基于Consul的服务发现工作原理

5.3 基于Consul的服务发现使用场景

5.4 基于Consul的服务发现操作实践

5.4.1 安装Consul服务

5.4.2 访问Consul控制台

5.4.3 注册服务到Consul

5.4.4 配置Prometheus文件

5.4.5 重新加载Prometheus服务

5.4.6 注册consul服务实现自动发现

六、写在文末

---

一、前言

在之前分享的文章中，详细介绍了Prometheus的使用，以及使用Prometheus结合各类exporter监控不同的服务，但是细心的同学可能会发现，每次接入一种新的待监控的组件时，需要在Prometheus的配置文件中添加新的配置信息，然后重启Prometheus的服务，这个过程多少显得有点繁琐，针对这个问题有没有什么解决办法呢？答案是肯定的，这就是Prometheus的服务自动发现机制。

二、Prometheus常规服务监控使用现状

2.1 Prometheus监控架构图

如下是一张在日常使用Prometheus进行服务的配置监控的架构图，通常来说，为了监控某种服务指标，需要做如下几步操作：

• 被监控的机器上安装部署exporter服务；

• Prometheus机器上配置job，监控上述的exporter暴露的端点；

• 上一步配置完成后，重新加载Prometheus服务；

• 配置Grafana，将待监控的指标通过可视化大屏展示出来；

在上述的操作中，如果是小规模的监控，比如说使用Prometheus监控少量的几个服务，这种操作人力也是可以完成的，但是如果后续待监控的服务越来越多的时候，每次对接一种新的服务，就需要修改一下Prometheus的配置文件然后重新加载服务，这是一个很繁琐的事情，因此是不适合生产环境的大规模监控架构设计的。

2.2 Prometheus服务自动发现的解决方案

基于上述的痛点，所以prometheus提供了这种问题的两种解决方案，基于文档的自动发现和基于网络的自动发现，以基于文档的自动发现来说，有了这种机制，就变成下面这样：

有了这种机制之后，只需要第一次在prometheus的配置文件中配置一次重启一次服务即可，后续只需要维护自动发现文档，对于后续新加入的被监控的服务，只需要按要求将配置维护到该文档中即可让prometheus自动发现被监控的服务了。

三、Prometheus服务自动发现介绍

3.1 什么是Prometheus服务自动发现

Prometheus服务自动发现是一种机制，允许Prometheus监控系统动态地检测并监控网络中新的目标（targets），而无需手动更新配置文件。

在云原生和微服务架构中，服务实例可能会频繁地启动和停止，这使得手动维护监控目标列表变得不切实际。因此，Prometheus引入了自动服务发现功能，以便更高效地管理监控目标。

3.2 Prometheus自动服务发现策略

Prometheus支持多种自动服务发现的策略，以下列举了Prometheus常用的服务发现方法

• 基于文件的服务发现

  • file_sd，Prometheus可以定期从特定的文件中读取目标列表。这些文件可以被外部程序动态更新，以反映当前的网络状态；

• DNS 服务发现

  • dns_sd，使用DNS查询来查找目标。Prometheus可以配置为查询特定的DNS记录类型（如SRV记录），以找到要监控的服务实例；

• Consul 服务发现

  • consul_sd，通过与Consul服务注册中心通信，Prometheus可以自动检测注册在Consul中的服务实例；

• Kubernetes 服务发现

  • kubernetes_sd，当Prometheus运行在Kubernetes环境中时，可以使用Kubernetes API来自动发现并监控Pods、Services等资源；

• EC2 服务发现

  • ec2_sd，在AWS EC2环境中，Prometheus可以自动发现并监控EC2实例；

自动服务发现的配置通常包含在Prometheus的prometheus.yml配置文件中，通过scrape_configs部分定义如何寻找和收集目标。例如，使用Kubernetes服务发现，你可能需要配置kubernetes_sd_configs，它将指向Kubernetes API以获取服务信息。

这种自动化的机制极大地简化了监控系统的管理，尤其是在高度动态的环境中，如容器化应用和服务网格。通过自动服务发现，Prometheus能够保持监控目标的最新状态，确保没有服务被遗漏或错误地监控。

3.3 Prometheus自动服务发现应用场景

Prometheus的自动服务发现机制适用于许多不同的场景和环境，特别是在动态和云原生架构中，它能够有效地管理和监控各种服务实例的变化。以下是一些典型的应用场景：

• 微服务架构

  • 在微服务环境中，服务实例的数量和位置经常发生变化。使用Kubernetes或Consul服务发现可以自动检测和添加新的服务实例，保持监控系统的实时性和准确性；

• 容器化环境

  • 使用Docker或Kubernetes部署的应用程序，可以利用Kubernetes服务发现功能，自动将新的Pod添加到监控目标中，而无需手动更新配置；

• 传统数据中心

  • 即使在传统的物理或虚拟化数据中心中，文件和静态配置的服务发现方法仍然非常有用。它们提供了一种简单而可靠的方式来管理和监控服务目标；

• 云平台

  • 在云环境中，例如AWS的EC2实例，使用Prometheus的EC2服务发现可以自动检测和监控新的实例启动和停止，以及其状态变化；

• 动态扩展

  • 当服务实例需要动态扩展或收缩时，自动服务发现确保新实例可以立即添加到监控中，而无需人工干预

总的来说，Prometheus的自动服务发现功能是为了应对现代复杂和动态变化的IT环境而设计的，它能够显著简化监控系统的维护和管理，同时提升监控的实时性和覆盖范围。

3.4 Prometheus自动服务发现原理

Prometheus的服务自动发现机制用于动态识别和更新监控目标列表，确保监控系统可以适应基础设施的变化。其服务自动发现的主要机制和其工作原理：

• 目标发现

  • Prometheus通过不同的服务发现插件或机制来获取当前可用的服务实例列表。这些插件包括：

    • Kubernetes API：获取Kubernetes集群中的Pod和服务信息。

    • Consul HTTP API：从Consul中获取服务实例。

    • EC2 API：通过AWS API发现EC2实例。

• 目标标识

  • 从服务发现中获取的信息会被处理并提取出监控目标的标识符，如IP地址、主机名、端口号及其他相关元数据。这些标识符用于唯一地识别和访问监控目标。

• 动态更新

  • Prometheus会将发现的目标动态地添加到其内部的监控目标列表中，并开始对这些目标进行指标数据的采集。这个过程是自动化的，无需人工干预。

• 拉取指标数据

  • 一旦目标被添加到监控列表中，Prometheus会定期从这些目标中获取指标数据。数据采集通常通过HTTP或HTTPS协议进行，具体的抓取频率和方式可以在配置文件中定义

• 自动清理

  • 如果发现的服务实例不再可用，Prometheus会自动从监控目标列表中删除这些实例，停止对其进行监控。这样可以确保监控数据的准确性和时效性。

总的来说，Prometheus服务自动发现机制的原理是基于动态地从各种来源获取服务实例的信息，并将其集成到监控系统中。这使得监控系统能够自动适应服务实例的变化，保持实时性和全面性。

四、Prometheus 基于文件的服务发现

4.1 Prometheus基于文件服务发现介绍

Prometheus基于文件的服务发现（File Service Discovery），是一种允许Prometheus动态加载和更新监控目标列表的机制，而无需重启Prometheus服务。这种服务发现方式特别适用于那些不能或不需要与Prometheus进行实时交互的服务注册中心的情况。

在基于文件的服务发现中，Prometheus会周期性地检查一个或多个文件，这些文件包含了要监控的目标列表。每个目标都是一个URL，指向一个提供Prometheus格式的指标数据的HTTP端点。当文件中的内容发生变化时，Prometheus会自动调整其监控配置，添加新目标或移除不再存在的目标。

4.2 Prometheus基于文件服务发现使用场景

Prometheus基于文件的服务发现（File-Based Service Discovery）在很多种场景下非常有用，特别是在那些无法或不需要实时交互的服务注册中心的环境中。下面介绍一些常用的使用场景：

• 离线/预配置环境

  • 在某些情况下，如边缘计算或物联网设备，可能没有实时的网络连接或服务注册中心。在这种情况下，可以预先配置一个文件，其中包含所有需要监控的设备列表。

• 静态服务监控

  • 如果有一些服务实例不会经常变化，或者变化频率较低，使用基于文件的服务发现可以避免过度复杂的服务发现机制，同时仍然能够有效地监控这些服务。

• 混合环境监控

  • 如果你的环境既包括云原生服务也包括传统服务，基于文件的服务发现可以帮助你监控所有服务，而不仅仅是那些可以自我注册的服务。例如，你可以在文件中手动列出所有需要监控的传统服务器的地址。

• 集成第三方工具

  • 有时候，你可能使用了像Ansible、Chef、Puppet这样的配置管理工具，这些工具可以生成Prometheus目标列表的文件。这样，你就可以利用这些工具的自动化能力，根据基础设施的变化自动更新Prometheus的监控目标。

• 自定义逻辑或脚本

  • 你可以编写自己的脚本来动态生成目标列表文件，该脚本可以根据业务逻辑、环境状态或其他条件来决定哪些目标应该被监控。例如，你可以编写一个脚本来监控只有在特定条件下才激活的微服务。

• 跨云环境

  • 当你在多个云提供商之间运行服务时，每个云可能都有不同的服务发现机制。基于文件的服务发现可以作为一个统一的解决方案，允许你手动或通过脚本将不同云环境中的服务实例添加到监控列表中。

• 测试和开发环境

  • 在测试或开发环境中，服务的实例可能由手动启动的容器或虚拟机组成，而不是由编排器或服务注册中心管理。基于文件的服务发现提供了一种简单的方式来管理这些环境的监控目标。

• 安全性考虑

  • 在一些对安全要求较高的环境中，可能不希望使用网络广播或依赖于可公开访问的服务注册中心。基于文件的服务发现提供了一种更可控的方式，可以限制谁有权修改监控目标列表。

4.3 基于文件服务发现配置说明

4.3.1 核心配置文件模板

在Prometheus的配置文件（通常是prometheus.yml）中，基于文件的服务发现可通过如下方式配置：

scrape_configs:- job_name: 'my_job'file_sd_configs:- files:- /path/to/targets/*.txt- /path/to/static/*.{json,yaml,yml}

参数说明：

• job_name 是一组监控目标的标识符，Prometheus会用它来标记从这些目标收集的数据。

• file_sd_configs 指定了一组文件的位置，Prometheus将从中读取目标列表。

• files 列出了Prometheus应该检查的文件或文件模式。这里可以是文本文件（每个URL一行），也可以是JSON或YAML文件，其中包含了目标列表的结构化数据。

4.3.2 核心配置文件支持格式

Prometheus可以解析下面几种不同格式的配置文件：

• 纯文本格式：每行一个目标，目标是一个URL，例如 http://host:port/metrics

• JSON 格式：目标列表可以嵌套在数组或对象中

• YAML 或 YAML 格式：与JSON类似，但使用YAML语法

4.3.3 基于文件服务发现动态更新机制

Prometheus 的基于文件的服务发现 (File SD) 允许用户通过定期检查文件中的目标列表来动态更新监控目标。这特别适用于那些不能或不需要使用其他服务发现机制（如 DNS 或 Consul）的情况。以下是基于文件的服务发现如何实现动态更新的机制：

• 配置文件

  • Prometheus 需要配置文件中指定的 file_sd_configs 来加载和监视目标文件。这个配置通常包含一个或多个文件路径，Prometheus 将从这些文件中读取目标列表。

• 目标文件

  • 目标文件是一个 JSON 文件，其中包含一个目标数组，每个目标都是一个带有 __address__ 字段的对象，该字段指定了目标的地址和端口。此外，可以包含 labels 字段来添加额外的元数据。

• 动态更新

  • Prometheus 会周期性地重读配置文件中指定的目标文件。默认情况下，它每分钟检查一次文件更新，但可以通过 refresh_interval 参数调整这个间隔。

• 自动应用更改

  • 当 Prometheus 检测到目标文件中有任何更改时，它会自动应用这些更改，这意味着新的目标会被添加到监控列表中，而不再存在的目标则会被移除。这使得你可以动态地调整监控配置，而无需重启 Prometheus 服务。

• 外部管理

  • 目标文件通常由外部系统或脚本管理，这些系统或脚本可以响应环境变化（例如，新服务实例的启动或现有实例的关闭）并更新目标文件。例如，你可以使用 Ansible、Chef 或 Puppet 这样的配置管理系统，或者编写自定义脚本来动态生成和更新目标列表。

• 错误处理

  • 如果在读取文件过程中发生错误，如文件不存在或格式错误，Prometheus 将继续使用最后成功读取的配置，并在日志中记录错误信息。

4.4 基于文件服务发现操作实践

下面通过实际案例演示下Prometheus基于文件服务发现的具体操作实践过程。

4.4.1 环境准备

两台（或3台）服务器，其中一台安装prometheus，另外的1~2台安装其他的服务，后面作为被监控使用。

第一台服务器部署prometheus

第二台部署了node_exporter

4.4.2 添加Prometheus配置信息

在第一台安装了Prometheus服务的安装目录下，编辑prometheus.yml配置文件，添加下面的配置信息

- job_name: "remote_file_node_job"file_sd_configs:- files:- /usr/local/soft/pro/file-sd/sd-config.yaml

4.4.3 编辑自动发现文档

在上一步的配置中，通过file_sd_configs这个标签，最终是要找到目标目录下sd-config.yml这个配置文件，即自动发现的配置文件，在该文件中添加如下配置信息：

- targets:- '远程机器的node_exporter的IP:9100'labels:job: remote_exporterinstance: 远程机服务器author: james

也可以写成下面这样

- targets: ['远程机器的node_exporter的IP:9100']labels:job: remote_exporterinstance: 远程机服务器author: james

参数说明：

• targets，即监控的目标，这里监控的是远程机上的node_exporter服务指标，也可以监控远程机上其他的服务指标，在后面继续追加即可；

• labels，自定义标签信息，可以根据自己的需求添加；

4.4.4 重新加载Prometheus服务

通过上面的几步操作就完成了最基本的配置，然后重启Prometheus服务，等待一会，进入Prometheus的控制台，在Targets菜单下可以发现，当前的Prometheus机器上，就通过文件服务发现的方式监控了远程148这台机器的node_exporter

同时，由于我们在服务发现文件中添加了相应的标签，这里把标签信息也展示出来了，后续就可以在界面上通过标签去搜索指标信息了

4.4.5 自动发现文件添加新的监控指标

如何验证Prometheus在不重启服务的情况下通过上述的自动发现文件自动发现待监控的服务指标呢？下面做过实验，首先，在148被监控机器上安装一个mysql的exporter，启动之后，访问一下端点

修改上述的sd-config.yml配置文件，增加mysql的exporter配置指标地址，如下：

- targets: ['远程机器的node_exporter:9100','远程机器的mysql exporter:9104']labels:job: remote_exporterinstance: 远程机服务器author: james

为了更好的区分不同指标，也可以写成下面这样：

- targets: ['远程机的node_exporter:9100']labels:job: remote_exporterinstance: 远程机服务器的node-exporterauthor: james
- targets: ['远程机的mysql exporter:9104']labels:job: mysql_exporterinstance: 远程机服务器的mysql-exporterauthor: james    

编辑完成后，预计等待10s左右，不需要对prometheus做任何的操作，然后再在prometheus的控制台上看到下面的效果，即通过服务发现文件自动发现了远程机的mysql-exporter服务并对其进行服务监控

通过上面的操作不难发现，只需要在第一次对prometheus的配置文件将服务发现文件配置进去即可，后续如果是类似的待监控的服务，只需要在服务发现文件中追加，即可自动纳入到prometheus的指标监控中，这样就做到了自动发现的效果，避免了对prometheus的服务反复启动

五、Prometheus基于Consul的服务自动发现

5.1 Prometheus基于Consul的服务发现介绍

Prometheus 基于 Consul 的服务发现是一种高级的服务发现机制，它允许 Prometheus 动态地从 Consul 注册表中发现和监控服务。Consul 是一个服务网格解决方案，主要用于服务发现、配置和协调服务间通信。在微服务架构中，服务实例可能频繁地创建和销毁，使用 Consul 作为服务注册中心可以帮助 Prometheus 自动跟踪这些变化。

5.2 Prometheus基于Consul的服务发现工作原理

当服务在 Consul 中注册时，它们会报告自己的状态、位置、健康状况和其他元数据。Prometheus 可以配置为定期查询 Consul 的服务注册表，从而动态地构建和更新其监控目标列表。这意味着当新的服务实例启动时，Prometheus 可以自动开始监控它们；当服务实例关闭时，Prometheus 也会自动停止监控。具体来说，其工作机制如下：

• Consul 服务注册

  • 在 Consul 中，服务实例（即微服务、应用程序或其他需要监控的组件）在启动时向 Consul 注册自己。注册信息通常包括服务的名称、IP 地址、端口、健康检查信息等。

• Prometheus 配置

  • 在 Prometheus 的配置文件中，需要定义一个或多个 scrape_configs 来指定 Consul 服务发现的参数。这通常包括 Consul 服务器的地址以及要监控的服务名称。

• Prometheus 查询 Consul

  • Prometheus 根据配置定期（默认每分钟）查询 Consul，获取注册的服务实例列表。Prometheus 通过调用 Consul 的 HTTP API 来获取这些信息。

• 目标转换和过滤

  • Prometheus 可能需要对从 Consul 获取的信息进行转换和过滤，以匹配其内部的监控目标模型。这通常是通过 relabel_configs 来实现的。例如，可以将 Consul 的元数据转换成 Prometheus 需要的 __address__ 标签，或者过滤掉不需要的服务实例。

• 动态更新监控目标

  • 每次 Prometheus 查询 Consul 并收到新的服务实例列表后，它会更新其内部的监控目标列表。这意味着当有新的服务实例注册到 Consul 时，Prometheus 会自动开始监控这些新实例；同样，如果服务实例从 Consul 中注销，Prometheus 也会自动停止监控它们。

• 健康检查和状态感知

  • Consul 进行服务健康检查，这意味着它会持续监控服务实例的健康状况。Prometheus 可以利用 Consul 的健康检查结果，例如，仅监控健康的服务实例，忽略那些标记为不健康的实例。

• 监控和数据收集

  • 一旦 Prometheus 更新了其监控目标列表，它就会按照配置的时间间隔（例如，15 秒）从这些目标收集监控数据。收集的数据会被存储在 Prometheus 的时间序列数据库中，供查询和警报使用。

通过上述过程，Prometheus 能够实现动态的服务发现和监控，即使在服务实例频繁变化的情况下也能保持监控的完整性和实时性。这在微服务架构和容器化环境中尤其重要，因为它们往往具有高度动态的服务实例生命周期。

5.3 基于Consul的服务发现使用场景

Prometheus 基于 Consul 的服务发现机制非常适合于微服务架构和动态服务环境，其中服务实例可能频繁地启动和停止。以下列举了常用的几个使用场景：

• 微服务架构

  • 在微服务架构中，服务实例可能分布在多个主机上，且数量和位置经常变化。Consul 可以作为一个中心化的服务注册和发现平台，帮助 Prometheus 动态地发现和监控这些服务实例。这减少了手动维护监控配置的负担，确保了即使在服务实例变化时，监控也不会中断。

• 容器化环境

  • 在 Docker、Kubernetes 或其他容器平台上，容器的生命周期管理可能导致服务实例的快速创建和销毁。Consul 可以跟踪这些容器的运行状态，Prometheus 则可以通过 Consul 自动发现和监控这些动态服务实例。

• 服务健康检查

  • Consul 提供了服务健康检查功能，可以监测服务实例的状态。结合 Prometheus 的基于 Consul 的服务发现，可以确保 Prometheus 只监控健康的服务实例，从而提高监控的准确性和效率。

• 多数据中心环境

  • 在跨数据中心的部署中，Consul 可以在多个数据中心之间同步服务注册信息。Prometheus 可以配置为从每个数据中心的 Consul 实例中发现服务，从而实现全局范围内的服务监控。

• 故障切换和高可用性

  • Consul 支持集群模式，可以提供高可用性和故障切换。当其中一个 Consul 节点失效时，Prometheus 可以从其他节点继续发现服务，确保监控的连续性。

• 配置和动态调整

  • 在大规模或复杂的环境中，手动配置监控目标可能是不可行的。Consul 的服务发现特性允许 Prometheus 根据服务实例的实际状态自动调整监控配置，减少人工干预的需求。

• 服务迁移和弹性伸缩

  • 当服务实例因负载变化而迁移或弹性伸缩时，Consul 可以及时更新服务注册信息。Prometheus 通过 Consul 的服务发现可以迅速适应这些变化，保持监控的有效性。

通过上述场景的介绍，可以看到，Prometheus 结合 Consul 的服务发现机制，不仅能够简化监控配置，还能够提高监控的可靠性和灵活性，特别是在高度动态和分布式的服务环境中。

5.4 基于Consul的服务发现操作实践

下面通过实际操作来体验下基于Consul的服务发现过程。

5.4.1 安装Consul服务

可以基于二进制的包安装，也可以基于docker安装，这里选择基于docker的方式安装，在第一台安装了Prometheus服务的机器上，执行下面的命令启动consul容器

docker run -d --name consul -p 8500:8500 consul:1.14.5

5.4.2 访问Consul控制台

访问地址，IP:8500，效果如下

5.4.3 注册服务到Consul

通过上面的介绍可以知道，Consul可以作为一个服务注册中心，接收不同的服务注册，其提供了HTTP接口供客户端注册服务，比如，可以将148上面的node-exporter服务注册进去，使用下面的http方式注册。

curl -X PUT -d '{"id":"node_exporter","name":"node_exporter","address":"被监控的服务IP","port":9100,"tags":["node_exporter"],"meta":{"job":"node_exporter","instance":"Prometheus监控的node_exporter"},"checks": [{"http":"http://被监控的服务IP:9100","interval":"10s"}]}' http://consul服务地址:8500/v1/agent/service/register

参数说明：

• id：注册到consul上面的服务唯一标识；

• name：自定义的名称；

• address：注册的服务自身的IP地址，比如需要将node_exporter服务注册进去，即148的机器IP；

• port：对应的服务端口，这里node_exporter端口为9100；

• tags：服务打的标签信息；

• meta：自定义的元信息参数（非必须）；

• checks：被监控的服务被检测监控状况的时间；

• 注册的consul的服务地址；

在consul服务所在的节点上执行上面的请求地址：

执行成功后，进入到consul控制台查看，可以看到有一个node-exporter服务注册进来了

当然，上面注册服务时，也可以将请求参数的信息写到json文件里面，自定义一个node_exporter.json的文件，内容如下：

{"id":"node_exporter","name":"node_exporter","address":"注册的服务自身的IP地址","port":9100,"tags":["node_exporter"],"meta":{"job":"node_exporter","instance":"Prometheus监控的node_exporter"},"checks": [{"http":"http://注册的服务自身的IP地址:9100","interval":"10s"}]
}

定义完成json文件之后，使用下面的方式进行注册

curl --request PUT --data @node_exporter.json http://consul服务地址:8500/v1/agent/service/register

5.4.4 配置Prometheus文件

找到prometheus.yml文件，将consul信息配置进去，这样才能通过consul来监控注册进去的服务指标信息，参考下面的配置：

- job_name: 'consul-discovery'consul_sd_configs:- server: consul服务IP:8500services: []relabel_configs:- source_labels: [__meta_consul_service]regex: .*exporter.*action: keep

参数说明：

• services标签，不填，表示所有服务；

• source_labels，匹配consul的源标签字段，这里表示服务的名称；

• regex，指定源标签的正则表达式，若不定义，默认值为"(.*)"；

• action，执行动作，默认值为"replace",有效值: replace, keep, and drop

5.4.5 重新加载Prometheus服务

参照上面的配置完成后，重新加载Prometheus服务，再次访问控制台可以发现，通过Consul就能自动监控148远程机上面的node-exporter服务指标信息了

5.4.6 注册consul服务实现自动发现

通过这种方式是不是也可以在不用重启Prometheus服务的情况下，自动监控其他注册到consul的服务呢？下面我们再将148机器上的mysql的exporter服务注册进去，执行下面的命令：

curl -X PUT -d '{"id":"mysql_exporter","name":"mysql_exporter","address":"注册的服务自身的IP地址","port":9104,"tags":["mysql_exporter"],"meta":{"job":"mysql_exporter","instance":"Prometheus监控的mysql_exporter"},"checks": [{"http":"http://注册的服务自身的IP地址:9104","interval":"10s"}]}' http://concul服务IP:8500/v1/agent/service/register

注册成功后，在consul控制台上可以看到注册成功的mysql的exporter服务信息

回到Prometheus控制台，可以看到mysql的exporter指标信息也被纳入监控了

六、写在文末

本文详细介绍了Prometheus 服务自动发现的使用，理论结合实践，全方位展示了常用的两种服务发现机制的如何配置和使用，如果在你的项目中还有更多的服务需要通过自动发现的方式进行管理，可以提供一个参考，本文到此结束，感谢观看。