Prometheus Targets动态配置

一、存在问题

Prometheus的配置通过配置文件实现，每个配置文件对应一个Prometheus Server。生产环境部署时，Prometheus Server会部署多个实例，手工修改配置存在诸多不便。常见场景如下：

（1）为了实现高可用，Prometheus Server通常部署多个实例。

（2）联盟方式部署Prometheus，为了实现数据安全，同一个底层的Prometheus/或同一个pushgateway会被多个上层Prometheus Server拉取数据。

（3）多IDC情况下，不同IDC均部署Prometheus Server。

综上所述：为了简化多个Prometheus Server配置文件的修改维护工作，需提供机制简化。

二. 问题分析

Prometheus配置中变更最频繁的是Targets的变更，原因是被监控对象的频繁、动态变化。

对于Targets的配置，Prometheus提供了诸多配置方法，包括static_configs和诸多基于服务发现（Service Discovery）的配置。包括：

static_configs
file_sd_configs
serverset_sd_configs
azure_sd_configs
consul_sd_configs
dns_sd_configs
ec2_sd_configs
openstack_sd_configs
gce_sd_configs
kubernetes_sd_configs
marathon_sd_configs
nerve_sd_configs
triton_sd_configs

上述机制中，

static_configs最为简单，直接在配置文件中配置拉取对象，但在拉取对象发生变化时，需手动修改配置文件，不能快速、动态响应变化。

file_sd_configs的方式提供简单的接口，可以实现在单独的配置文件中配置拉取对象，并监视这些文件的变化并自动加载变化。基于这个机制，我们可以自行开发程序，监控监控对象的变化自动生成配置文件，实现监控对象的自动发现。

其他服务发现机制，在特定应用场景下可方便接入，作为通用解决方案则不方便使用。
原因：服务发现机制包含在Prometheus实现中，如果新增sd支持，需修改Prometheus源码；
目前Prometheus版本频发，自行修改源码很难与官方版本保持同步。
仿制现有服务发现机制的API，与Prometheus通讯也是个思路，但未得其利反徒增复杂度，没必要。

总上所述：宜基于file_sd_configs机制提供通用的targets sd方案。

三. 方案介绍

1. Prometheus配置

scrape_configs:
  
  - job_name: 'component_service'
    scrape_interval: 15s
    scrape_timeout: 10s
    metrics_path: /metrics
    
    file_sd_configs:
      refresh_interval: 5m
      files: 
        - conf.d/*.json

如上配置中，根据拉取间隔或超时时间不同，可分多个job配置。

在 file_sd_configs中，通过files配置监控的配置文件，支持通配符。如配置为 conf.d/*.json表示conf.d下的所有后缀为json的文件。

被监控的target配置文件支持json和yml格式，配置文件的修改会“立即”被Prometheus发现并触发重新加载，可以在Prometheus控制台target功能中看到。作为兜底机制，可以配置refresh_interval，将定期检查这些配置文件有无变化，是否需要reload。

target.json范例：

[
  {
    "targets": [ "10.32.19.21:9090" ],
    "labels": {
      "idc": "LAISHUI",
      "city": "Haidian"
    }
  },
  {
    "targets": [ "10.16.19.21:9090" ],
    "labels": {
      "idc": "RUC",
      "city": "Haidian"
    }
  }
]
target.yml范例：

- targets:
    - 10.16.19.21:9090
  labels:
    city: Haidian
    idc: RUC
 
- targets:
    - 10.32.19.21:9090
  labels:
    city: Haidian
    idc: Laishui 
另外，在relable中可以使用 __meta_filepath 获取配置文件的名称。

2. 配置文件生成

上面介绍的 file_sd_configs 配置方法，仍然是手工配置，并没有实现 sd 。

对于 file_sd，Prometheus是这样考虑的，
文件发生变化，则自动加载并reload，从而被discovery了。
Proemetheus提供的只是基础机制，至于如何在应用环境发生变化时，触发配置文件发生变化，需要应用者自行实现。

需要实现：配置文件生成 的功能。

1）配置文件生成应用场景

首先，配置文件生成功能只覆盖target.json或target.yml的生成，简便期间，先只支持json。

其次，在统一的控制台进行配置展现和修改，但需要发布到多idc的、多个Prometheus实例下。

最后，配置信息是自上而下下发的，这样基于cmdb或注册中心，很方便进行管理。没有统一cmdb或注册中心的同学可以考虑其他方式。

2）配置文件生成的架构设计

通讯链路：

控制台到Prometheus Server上的配置文件，如何进行通信，需要考虑。

可以是： 控制台–>Ansible跳板机–>Prometheus Server，但链路长、依赖多、速度慢，否决。

可以是：控制台–>Zookeeper/Redis/Kafka–>Prometheus Server，增加了新的组件依赖，增加了运维成本和故障点，可以、但可优化。

我选择的是：实现一个简单的配置中心（后面称作nconf），有可用配置中心服务的同学有福了，直接用即可。

程序架构：

【nconf-storage】--【nconf】--【nconf-client】

nconf-storage： 负责配置信息存储，可以是db、文件；通过后台rpc向其他idc同步；同步状态显示在界面上。

nconf：包含界面和应用，作为storage和client的中介，提供配置信息查询api。

client：拉取配置变化，生成配置文件；监控本地文件变化，发生变化时调用nconf，比对配置信息并处理。

数据架构：

nconf_group（group_id,namespace,app,group,version, create_time,modify_time）

nconf_data(data_id, group_id, key, value, version, create_time,modify_time)

nconf_template(template_id, template, create_time,modify_time)

业务流程：

控制台修改配置，更新存储中version和modify_time。

client根据自身配置的group和上次拉取配置信息的modify_time定期（默认为5m）向控制台发送查询请求，只返回modify_time发生变更的数据。

配置文件生成：客户端拉取模板和数据后，可生成配置文件。客户端配置template_id。

3）配置文件生成的实现

TODO

4）prometheus 热加载配置

在配置中加入--web.enable-lifecycle

当 Prometheus 有配置文件修改，我们可以采用 Prometheus 提供的热更新方法实现在不停服务的情况下实现配置文件的重新加载。

热更新加载方法有两种：

1. kill -HUP pid
2. curl -X POST http://IP/-/reload
   当你采用以上任一方式执行 reload 成功的时候，将在 promtheus log 中看到如下信息：

Loading configuration file prometheus.yml  source=main.go:221

如果因为配置信息填写不正确导致更新失败，将看到类似信息：

ERRO[0161] Error reloading config: couldn't load configuration (-config.file=prometheus.yml): unknown fields in scrape_config: job_xxx  source=main.go:146

注意：

• 个人更倾向于采用 curl -X POST 的方式，因为每次 reload 过后， pid 会改变，使用 kill 方式需要找到当前进程号。
• 从 2.0 开始，hot reload 功能是默认关闭的，如需开启，需要在启动 Prometheus 的时候，添加 --web.enable-lifecycle 参数。

Prometheus 内部提供了成熟的 hot reload 方案，这大大方便配置文件的修改和重新加载，在 Prometheus 生态中，很多 Exporter 也采用类似约定的实现方式。

原文链接：https://blog.csdn.net/stationxp/article/details/89531925