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的方式提供簡單的介面，可以實現在單獨的配置檔案中配置拉取物件，並監視這些檔案的變化並自動載入變化。基於這個機制，我們可以自行開發程式，監控監控物件的變化自動生成配置檔案，實現監控物件的自動發現。
其他服務發現機制，在特定應用場景下可方便接入，作為通用解決方案則不方便使用。原因：服務發現機制包含在prometheus實現中，如果新增sd支援，需修改prometheus原始碼；目前prometheus版本頻發，自行修改原始碼很難與官方版本保持同步。仿製現有服務發現機制的api，與prometheus通訊也是個思路，但未得其利反徒增複雜度，沒必要。
總上所述：宜基於file_sd_configs機制提供通用的targets sd方案。
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
在 file_sd_configs中，通過files配置監控的配置檔案，支援萬用字元。如配置為 conf.d/*.json表示conf.d下的所有字尾為json的檔案。
target.json範例：
[},}
]
- targets:
- 10.16.19.21:9090
labels:
city: haidian
idc: ruc
- targets:
- 10.32.19.21:9090
labels:
city: haidian
idc: laishui
上面介紹的 file_sd_configs 配置方法，仍然是手工配置，並沒有實現 sd 。
對於 file_sd ，prometheus是這樣考慮的，檔案發生變化，則自動載入並reload，從而被discovery了。proemetheus提供的只是基礎機制，至於如何在應用環境發生變化時，觸發配置檔案發生變化，需要應用者自行實現。
需要實現：配置檔案生成 的功能。
首先，配置檔案生成功能只覆蓋target.json或target.yml的生成，簡便期間，先只支援json。
其次，在統一的控制台進行配置展現和修改，但需要發布到多idc的、多個prometheus例項下。
最後，配置資訊是自上而下下發的，這樣基於cmdb或註冊中心，很方便進行管理。沒有統一cmdb或註冊中心的同學可以考慮其他方式。
通訊鏈路：
控制台到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_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。
todo
config server bus動態更新配置
config server用來搭建配置中心，而配置資訊一般使用gitlab倉庫來儲存，這樣在你的配置發生改變時，不需要從新打包，而如果使用native的試，則需要從新打乙個config server的jar包。當你的服務的配置資訊發生改變時，一般來說需要從新重啟你的服務，配置資訊才能生效，這對於我們...
Nacos Config配置中心，動態改變配置
nacos 中建立的properties 名字和此對應 gulimall coupon.properties nacos位址 spring.cloud.nacos.config.server addr 127.0.0.1 8848 nacos中的命名空間，可以按 不同服務分命名空間，按不同的時間段分...
44 萬用字元匹配（動態規劃）
給定乙個字串 s 和乙個字元模式 p 實現乙個支援 和 的萬用字元匹配。可以匹配任何單個字元。可以匹配任意字串 包括空字串 兩個字串完全匹配才算匹配成功。說明 輸入 s aa p a 輸出 false 解釋 a 無法匹配 aa 整個字串。輸入 s aa p 輸出 true 解釋 可以匹配任意字串。輸...