- 一、 Prometheus與服務發現
- 1.1 目前支持的服務發現方式
- 二、 案例
- 2.1 基於文件的服務發現
- 2.2 基於Consul的服務發現
- 三、本地測試
- 3.1 基於文件的服務發現
- 1.測試環境
- 2.配置文件
- 3.可視化
- 3.2 prometheus.yml熱加載
- 3.1 基於文件的服務發現
一、 Prometheus與服務發現
雲原生、容器場景下按需的資源使用方式對於監控系統而言就意味着沒有了一個固定的監控目標，所有的監控對象(基礎設施、應用、服務)都在動態的變化，這對基於Push模式傳統監控軟件帶來挑戰。
對於Prometheus這一類基於Pull模式的監控系統，顯然也無法繼續使用的static_configs的方式靜態的定義監控目標。而對於Prometheus而言其解決方案就是引入一個中間的代理人（服務注冊中心），這個代理人掌握着當前所有監控目標的訪問信息，Prometheus只需要向這個代理人詢問有哪些監控目標控即可， 這種模式被稱為服務發現。
通過服務發現的方式，管理員可以在不重啟Prometheus服務的情況下動態的發現需要監控的Target實例信息。
1.1 目前支持的服務發現方式
# List of Azure service discovery configurations. azure_sd_configs: [ - <azure_sd_config> ... ] # List of Consul service discovery configurations. consul_sd_configs: [ - <consul_sd_config> ... ] # List of DNS service discovery configurations. dns_sd_configs: [ - <dns_sd_config> ... ] # List of EC2 service discovery configurations. ec2_sd_configs: [ - <ec2_sd_config> ... ] # List of OpenStack service discovery configurations. openstack_sd_configs: [ - <openstack_sd_config> ... ] # List of file service discovery configurations. file_sd_configs: [ - <file_sd_config> ... ] # List of GCE service discovery configurations. gce_sd_configs: [ - <gce_sd_config> ... ] # List of Kubernetes service discovery configurations. kubernetes_sd_configs: [ - <kubernetes_sd_config> ... ] # List of Marathon service discovery configurations. marathon_sd_configs: [ - <marathon_sd_config> ... ] # List of AirBnB's Nerve service discovery configurations. nerve_sd_configs: [ - <nerve_sd_config> ... ] # List of Zookeeper Serverset service discovery configurations. serverset_sd_configs: [ - <serverset_sd_config> ... ] # List of Triton service discovery configurations. triton_sd_configs: [ - <triton_sd_config> ... ] |
二、 案例
2.1 基於文件的服務發現
用戶可以通過JSON或者YAML格式的文件，定義所有的監控目標。例如，在下面的JSON文件(targets.json)中分別定義了3個采集任務，以及每個任務對應的Target列表：
模板：
[
{
"targets": [ "<host>", ... ],
"labels": {
"<labelname>": "<labelvalue>", ...
}
},
...
] |
PS:以上targets是必填項。
實例：
[
{
"targets": [ "localhost:8080"],
"labels": {
"env": "localhost",
"job": "cadvisor" #默認是prometheus.yml中配置的file_ds（見下），此cadvisor會覆蓋前者
}
},
{
"targets": [ "localhost:9104" ],
"labels": {
"env": "prod",
"job": "mysqld"
}
},
{
"targets": [ "localhost:9100"],
"labels": {
"env": "prod",
"job": "node"
}
}
] |
創建Prometheus配置文件/etc/prometheus/prometheus-file-sd.yml，並添加以下內容：
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 15s
scrape_configs:
- job_name: 'file_ds'
file_sd_configs:
- files:
- /opt/prometheus/file_sd_configs/targets.json #也可以模糊匹配多個文件
refresh_interval: 10s |
通過這種方式，Prometheus會自動的周期性讀取文件中的內容。當文件中定義的內容發生變化時，不需要對Prometheus進行任何的重啟操作。
2.2 基於Consul的服務發現
Consul是由HashiCorp開發的一個支持多數據中心的分布式服務發現和鍵值對存儲服務的開源軟件，被大量應用於基於微服務的軟件架構當中。
Consul作為一個通用的服務發現和注冊中心，記錄並且管理了環境中所有服務的信息。Prometheus通過與Consul的交互可以獲取到相應Exporter實例的訪問信息。在Prometheus的配置文件當可以通過以下方式與Consul進行集成：
- job_name: node_exporter
metrics_path: /metrics
scheme: http
consul_sd_configs:
- server: localhost:8500 #指定了consul的訪問地址
services: #為注冊到consul中的實例信息
- node_exporter
- cadvisor |
在consul_sd_configs定義當中通過server定義了Consul服務的訪問地址，services則定義了當前需要發現哪些類型服務實例的信息，這里限定了只獲取node_exporter和cadvisor的服務實例信息。
三、本地測試
3.1 基於文件的服務發現
1.測試環境
1）export：在m162p84和m162p65兩台機器上分別啟動兩個node_export；
2）prometheus: 通過m162p84機器上的globle Prometheus監控收集node數據 ;
2.配置文件
1）prometheus_main.yml 配置文件
2）targets.json配置文件
以上targets是先后加入，通過查看章節3.可視化部分驗證其可自動加載配置文件並生效。
3.可視化
prometheus_UI:
grafana:
3.2 prometheus.yml熱加載
我們從上可以知道prometheus支持動態加載，通過file_sd_configs配置將target放置到yaml文件中，當yaml文件中的內容發生變化時，Prometheus會自動更新自身的target，從而實現動態配置target。
同樣我們也可以將rule放置到yaml文件中，我們也希望Prometheus能夠動態更新rule規則。然而實驗中卻發現，修改了rule配置文件后Prometheus並不會動態刷新，重啟Prometheus后才能生效。
開啟配置文件熱加載，Prometheus啟動時在參數中加入--web.enable-lifecycle(該參數默認關閉)，然后執行curl命令刷新配置：
./執行路徑/prometheus --web.enable-lifecycle curl -X POST http://IP:port/-/reload #測試也支持put請求 |