文章目录

一、存在问题
二. 问题分析
三. 方案介绍
- 1. Prometheus配置
- 2. 配置文件生成
- - 1）配置文件生成应用场景
  - 2）配置文件生成的架构设计
  - 3）配置文件生成的实现
- 4）prometheus 热加载配置

一、存在问题

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: 15sscrape_timeout: 10smetrics_path: /metricsfile_sd_configs:refresh_interval: 5mfiles: - 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:9090labels:city: Haidianidc: RUC- targets:- 10.32.19.21:9090labels:city: Haidianidc: 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 提供的热更新方法实现在不停服务的情况下实现配置文件的重新加载。

热更新加载方法有两种：

kill -HUP pid
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

Prometheus Targets动态配置相关推荐

开源监控Prometheus介绍,安装,配置,使用详解
介绍什么是Prometheus? Prometheus是一个开源监控系统,前身是SoundCloud的告警插件.从2012年开始,Prometheus逐渐被大量公司使用.该项目的社区也便跃起来,收到 ...
（四） prometheus + grafana + alertmanager 配置Kafka监控
安装请看https://blog.51cto.com/liuqs/2027365 ,最好是对应的版本组件,否则可能会有差别. (一)prometheus + grafana + alertmanage ...
Prometheus资源监控工具配置小结
文章目录前言 prometheus简介开始下载并安装 Node Exporter 配置自动启动下载安装 Prometheus 配置Prometheus 配置nginx代理转发运行Promet ...
Prometheus+Grafana安装配置并配置linux服务器监控dashboard
一.简介: prometheus是谷歌用golang语言开发的一款开源的监控软件,使用安装在远程机器上的exporter,通过HTTP协议从远程的机器收集数据并存储在本地的时序数据库上. Promet ...
Prometheus监控主机的配置
Prometheus监控主机的配置 exporter介绍 node_exporter 安装部署 Prometheus配置重启Prometheus服务查看Prometheus的UI界面 export ...
springboot整合Quartz实现动态配置定时任务
版权声明:本文为博主原创文章,转载请注明出处. https://blog.csdn.net/liuchuanhong1/article/details/60873295 前言在我们日常的开发中,很多 ...
Spring Boot 整合 Quartz 实现 Java 定时任务的动态配置
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 首先说下这次主题,动态配置.没接触过定时任务的同学可以先看 ...
分布式动态配置后浪推前浪 -- Nacos
???? 前言 Nacos 是阿里巴巴的开源的项目,全称 Naming Configuration Service ,专注于服务发现和配置管理领域. Nacos 致力于帮助您发现.配置和管理微服务.N ...
kafka原理_Kafka动态配置实现原理解析
总第19篇 2019年第15篇一.问题导读Apache Kafka在全球各个领域各大公司获得广泛使用,得益于它强大的功能和不断完善的生态.其中Kafka动态配置是一个比较高频好用的功能,下面我们 ...

Prometheus Targets动态配置