Prometheus 監控目標爲何要自動發現
頻繁對Prometheus配置文件進行修改，無疑給運維人員帶來很大的負擔，還有可能直接變成一個「配置小王子」，即便是配置小王子也會存在人爲失誤的狀況。node
Prometheus支持的多種服務發現機制
Prometheus數據源的配置主要分爲靜態配置和動態發現, 經常使用的爲如下幾類：nginx
- static_configs: 靜態服務發現
- file_sd_configs: 文件服務發現
- dns_sd_configs: DNS 服務發現
- kubernetes_sd_configs: Kubernetes 服務發現
- consul_sd_configs: Consul 服務發現
- ...
kubernetes 頻繁更新的pod，svc，等等資源配置應該是最能體現Prometheus監控目標自動發現服務的好處。web
Prometheus基於consul自動發現監控對象
Consul是一個分佈式k/v數據庫，是當前比較流行的服務註冊組件，下面對consul+prometheus自動發現監控目標大體流程作個介紹。數據庫
- 經過在consul註冊服務或註銷服務（監控targets）
- Prometheus 一直監視（watch）consul服務，當發現consul中符合要求的服務有新變化是更新Prometheus監控對象
Prometheus主要配置prometheus.yml中的scrape_configs以及consul_sd_configs以下：bootstrap
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目錄啓動便可：api
./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的一個示例：bash
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端口出來，配置以下:curl
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