Prometheus 監控目標為什么要自動發現
頻繁對Prometheus配置文件進行修改，無疑給運維人員帶來很大的負擔，還有可能直接變成一個“配置小王子”，即使是配置小王子也會存在人為失誤的情況。
Prometheus支持的多種服務發現機制
Prometheus數據源的配置主要分為靜態配置和動態發現, 常用的為以下幾類：
- static_configs: 靜態服務發現
- file_sd_configs: 文件服務發現
- dns_sd_configs: DNS 服務發現
- kubernetes_sd_configs: Kubernetes 服務發現
- consul_sd_configs: Consul 服務發現
- ...
kubernetes 頻繁更新的pod，svc，等等資源配置應該是最能體現Prometheus監控目標自動發現服務的好處。
Prometheus基於consul自動發現監控對象
Consul是一個分布式k/v數據庫，是當前比較流行的服務注冊組件，下面對consul+prometheus自動發現監控目標大致流程做個介紹。
- 通過在consul注冊服務或注銷服務（監控targets）
- Prometheus 一直監視（watch）consul服務，當發現consul中符合要求的服務有新變化是更新Prometheus監控對象
Prometheus主要配置prometheus.yml中的scrape_configs以及consul_sd_configs如下：
scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9090'] - job_name: 'consul' consul_sd_configs: - server: 'localhost:8500' relabel_configs: - source_labels: [__meta_consul_tags] regex: .*,prome,.* action: keep - source_labels: [__meta_consul_service] target_label: job - scrape_configs 配置數據源
- consul_sd_configs 基於consul服務發現的配置
- relabel_configs 重新標記
consul_sd_configs的相關relabel通過下面實例來說明。Prometheus安裝這邊不說明了，到prometheus目錄啟動即可：
./prometheus --config.file="prometheus.yml" --web.listen-address="0.0.0.0:9090" --web.enable-admin-api --web.enable-lifecycle & --web.enable-admin-api 運行通過web方式管理prometheus（刪除清空數據等操作） --web.enable-lifecycle 運行通過web方式重新加載prometheus配置（相當於reload） 我這里懶得配置騰訊雲安全組規則了，直接nginx反向代理暴露一個80端口出來，配置如下:
server { listen 10.135.13.136:80; server_name p.iloxp.com www.p.iloxp.com; resolver 8.8.8.8 8.8.4.4 valid=300s; location / { limit_req zone=allips burst=5 nodelay; proxy_pass http://127.0.0.1:9090; } include agent_deny.conf; location ~ /\.ht { deny all; } } 啟動一個consul服務
consul安裝比較簡單，下載二進制放在/usr/local/bin/目錄下即可使用consul命令啟動一個agent，consul 集群需至少啟動一個server agent，下面是我單機啟動consul server的一個示例：
consul agent -server -bootstrap-expect 1 -data-dir=/data/consul -node=server1 -bind=127.0.0.1 -client=127.0.0.1 -ui & consul將默認偵聽TCP 8500端口，-ui表示啟用web。
我這里懶得配置騰訊雲安全組規則了，直接nginx反向代理暴露一個80端口出來，配置如下:
server { listen 10.135.13.136:80; server_name c.iloxp.com www.c.iloxp.com; resolver 8.8.8.8 8.8.4.4 valid=300s; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8500; } include agent_deny.conf; location ~ /\.ht { deny all; } } 測試整個流程
向consul注冊一個服務作為prometheus的監控target
curl -X PUT -d '{"id": "node-10-135-13-136_test","name": "node_exporter","address": "10.135.13.136","port": 9100,"tags": ["prod","prome","node"],"checks": [{"http": "http://10.135.13.136:9100/metrics","interval": "35s"}]}' http://localhost:8500/v1/agent/service/register 檢查consul和prometheus是否已有對應target：
這是注冊我本機node_exporter的示例，到grafana里面看下是否能獲取，上面圖片黑色部分能看到consul與prometheus relabel各個配置的對應關系。
按理說是能看到監控數據有中斷的圖片，由於我剛剛重新注冊、注銷consul服務的時間間隔太短了，所以看不出來，在grafana下的效果如下：
從consul中注銷剛剛注冊的node_exporter prometheus 監控目標：
curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/node-10-135-13-136