Prometheus Targets动态配置
文章目錄
- 一、存在問題
- 二. 問題分析
- 三. 方案介紹
- 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 提供的熱更新方法實現在不停服務的情況下實現配置文件的重新加載。
熱更新加載方法有兩種:
當你采用以上任一方式執行 reload 成功的時候,將在 promtheus log 中看到如下信息:
如果因為配置信息填寫不正確導致更新失敗,將看到類似信息:
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动态配置的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【HTTPS】Let's Encrypt
- 下一篇: KVM console 串口连接虚