通过自动化的手段将被监控端监控起来，之前是每次都在普罗米修斯的配置文件里面写要监控谁，然后重载一下就生效了。最后就可以在普罗米修斯图形界面这里看到其配置了

如果被监控端的数据量很大的话，每次修改配置文件很复杂也容易出错。自动化的目的就是将预期的被监控端自动的加入监控。不需要人工干预这件事

Prometheus服务发现

Prometheus添加被监控端支持两种方式：

• 静态配置：手动配置   手动的在配置文件里面添加

• 服务发现：动态发现需要监控的Target实例

最常用的就是consul


 


服务发现


我们安装了exporter，并且抓取了主机和容器指标。对于指定的每个目标，我们在抓取配置中手动列出了它们的IP地址和端口。这种方法在主机较少时还可以，但不适用于规模较大的集群，尤其不适用于使用容器和基于云的实例的动态集群，这些实例经常会出现变化、创建或销毁的情况。


Prometheus 通过使用服务发现解决了这个问题：通过自动化的机制来检测、分类和识别新的和变更的目标。服务发现可以通过以下几种机制实现：


  • 从配置管理工具生成的文件中接收目标列表。
  • 查询API（例如Amazon AWS API）以获取目标列表。
  • 使用DNS记录以返回目标列表。

 


 


静态配置的局限

要了解服务发现的工作原理，我们需要回顾数据抓取的生命周期（如图所示 数据抓取生命周期 ）。当Prometheus开始作业时，第一步就是服务发现，这将生成作业将要抓取的目标和元数据标签列表。

Prometheus 基于文件的服务发现 file_sd_configs_配置文件


在现有的配置中，服务发现机制是在 static_configs 块中定义的： 静态服务发现


Prometheus 基于文件的服务发现 file_sd_configs_prometheus_02


目标列表和关联标签都是采用手动服务发现的方式。不难看出，在繁杂的工作中维护一长串主机列表并不是一个可扩展的任务（HUP的Prometheus服务器也不是每次都可以优雅地启动）。尤其对于


大多数环境的动态特性，以及被监控主机、应用程序和服务的规模来说，这种局限性更为明显。因此需要更成熟的服务发现方式，那么都有哪些方案可供选择呢？我们将探索以下几种服务发现


方案：


  • 基于文件的方式
  • 基于云的方式
  • 基于DNS的方式

我们将从基于文件的服务发现开始


作业可以使用多种类型的服务发现。我们可以通过多种服务发现技术在作业中指定目标。

 

 

支持服务发现的来源



• azure_sd_configs


• consul_sd_configs


• dns_sd_configs


• ec2_sd_configs


• openstack_sd_configs


• file_sd_configs


• gce_sd_configs


• kubernetes_sd_configs


• marathon_sd_configs


• nerve_sd_configs


• serverset_sd_configs


• triton_sd_configs


 

 

基于文件的服务发现



基于文件的发现只比静态配置更先进一小步，但它非常适合配置管理工具。借助基于文件的服务发现，Prometheus 会使用文件中指定的目标。这些文件通常由另一个系统生成，例如 Puppet 、 Ansible或Chef 等配置管理系统，或者从其他源（如 CMDB ）查询。定期执行脚本或进行查询可以（重新）生成这些文件。Prometheus 会按指定的时间计划从这些文件重新加载目标。 这个简单，只需要在配置文件里面。


这些文件可以是 YAML 或 JSON 格式，包含定义的目标列表，就像我们在静态配置中定义它们一样。让我们从将现有作业迁移到基于文件的服务发现开始。


基于文件的服务发现 :


Prometheus 基于文件的服务发现 file_sd_configs_prometheus_03



我们用file_sd_configs块替换prometheus.yml文件中的static_configs块。在这些块中，已经指定了文件列表，并包含在files列表中。我们在父目录targets下为每个作业指定了对应的文件，并为每个作业创建了一个子目录。你可以创建适合你的任何文件结构。然后使用*.json的glob样式来指定文件。每当这些文件发生更改时，系统都将从此目录中所有以.json结尾的文件加载目标。



我们选择了 JSON 格式，因为它是一种方便使用各种语言和集成来编写的流行格式。



每次作业运行或这些文件发生变化时， Prometheus 都会重新加载文件的内容。以防万一，我们还指定了refresh_interval 选项，该选项将在每个间隔结束时加载文件列表中的目标 —— 对这个示例来说是5分钟。



让我们快速创建上述的目录结构。




Prometheus 基于文件的服务发现 file_sd_configs_服务发现_04


 


创建保存目标的JSON文件

 

Prometheus 基于文件的服务发现 file_sd_configs_配置文件_05


 


 


实际操作如下


添加被监控端： 这里指定目录，只要在这个目录下创建配置文件就会被自动纳入监控，同时指定每隔多少秒检查有没有新的文件


[root@localhost ~]# cd /usr/local/prometheus/
[root@localhost prometheus]# mkdir sd_config


[root@localhost prometheus]# vim sd_config/node.yml 
- targets: ['192.168.179.101:9100']
[root@localhost prometheus]# cat sd_config/node.yml 
- targets: ['192.168.179.101:9100']


启用基于文件的服务发现：修改普罗米修斯配置文件 


[root@localhost prometheus]# vim prometheus.yml 
  - job_name: 'file_sd'
    file_sd_configs:
    - files: ['/usr/local/prometheus/sd_config/*.yml']
      refresh_interval: 5s  # 每隔5秒检查一次

[root@localhost prometheus]# ./promtool check config prometheus.yml 
Checking prometheus.yml
  SUCCESS: 1 rule files found

Checking rules/node.yml
  SUCCESS: 2 rules found

在192.168.179.101上面启动node_exporter

[root@k8s-master2 node_exporter]# ./node_exporter

热加载一下普罗米修斯 让配置生效，去普罗米修斯界面查看一下

Prometheus 基于文件的服务发现 file_sd_configs_服务发现_06

Prometheus 基于文件的服务发现 file_sd_configs_加载_07

可以看到基于文件的服务发现生效了

 如果需要认证可以使用

  - job_name: 'file_sd'
    basic_auth:
     username: prometheus
     password: 123456
    file_sd_configs:
    - files: ['/usr/local/prometheus/sd_config/*.yml']
      refresh_interval: 5s

所以当指定路径下面有yml文件或者yml文件有更新的时候，那么普罗米修斯会自动的帮你加载，就不需要重启这种操作

所以只需要生成yml配置文件就行了