Prometheus 與Consul 實現服務發現
20.Prometheus 與Consul 實現服務發現
[2020-03-16 11:48:21](javascript:)
服務發現
在基於微服務,雲基礎設施監控的場景下,我們會發現監控項是可變的。這個時候我們需要一個基於服務發現的機制。Prometheus提供了很多的發現機制。在最前面介紹基礎配置檔案的時候,我們也講過基於檔案的發現,但是還需要使用修改檔案的這種形式,還是比較麻煩。不過 Prometheus 官方支援多種自動服務發現的型別,其中就支援 Consul。
consul 部署與服務註冊
1、拉取映象和部署(當然在生產環境,建議大家使用叢集的方式)
[root@nn-gx-service-java-99 ~]# docker pull consul
2、啟動測試:
[root@nn-gx-service-java-99 ~]# docker run --name consul -d -p 8500:8500 consul
1c59b43c57f54971c9fe2d23d35c2e4c559e3b13b8ffc27dc4ead09f9b6b1e57
訪問一下:http://10.10.1.113:8500 consul的web ui 發現成功了就沒問題。
3、我們使用API把這裡的啟動的node_exporter 服務註冊到consul:
[root@nn-gx-service-java-99 ~]# curl -X PUT -d '{"id": "node-exporter","name": "node-exporter-192.168.191.128","address": "192.168.191.128","port": 9100,"tags": ["linux"],"checks": [{"http": "http://192.168.191.128:9100/metrics", "interval": "5s"}]}' http://192.168.191.128:8500/v1/agent/service/register
新增一個docker 的監控:
[root@nn-gx-service-java-99 ~]# curl -X PUT -d '{"id": "docker-exporter","name": "docker-exporter-192.168.191.128","address": "192.168.191.128","port": 8080,"tags": ["devops"],"checks": [{"http": "http://192.168.191.128:8080/metrics", "interval": "5s"}]}' http://192.168.191.128:8500/v1/agent/service/register
4、服務登出
當然我們要是想登出這個服務,可以直接通過介面的方式刪除node-exporter即可:
curl -X PUT http://10.10.2.99:8500/v1/agent/service/deregister/node-exporter
5、配置prometheus 實現自動發現:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'consul'
consul_sd_configs:
- server: '10.10.2.99:8500'
遇到的問題:
1、會發現 Prometheus 同時加載出來了預設服務 consul,這個是不需要的。
2、如果需要自定義一些標籤,例如 team、group、project 等關鍵分組資訊,方便後邊 alertmanager 進行告警規則匹配,該如何處理呢?
3、所有 Consul 中註冊的 Service 都會預設載入到 Prometheus 下配置的 consul_prometheus 組,如果有多種型別的 exporter,如何在 Prometheus 中配置分配給指定型別的組,方便直觀的區別它們?
Prometheus的Relabeling機制
在Prometheus所有的Target例項中,都包含一些預設的Metadata標籤資訊。可以通過Prometheus UI的Targets頁面中檢視這些例項的Metadata標籤的內容,在第一講的時候我們也講過標籤的替換,大家可以去看看了解一下:
預設情況下,當Prometheus載入Target例項完成後,這些Target時候都會包含一些預設的標籤:
__address__:當前Target例項的訪問地址<host>:<port>
__scheme__:採集目標服務訪問地址的HTTP Scheme,HTTP或者HTTPS
__metrics_path__:採集目標服務訪問地址的訪問路徑
__param_<name>:採集任務目標服務的中包含的請求引數
Relabeling最基本的應用場景就是基於Target例項中包含的metadata標籤,動態的新增或者覆蓋標籤。例如,通過Consul動態發現的服務例項還會包含以下Metadata標籤資訊:
__meta_consul_address:consul地址
__meta_consul_dc:consul中服務所在的資料中心
__meta_consulmetadata:服務的metadata
__meta_consul_node:服務所在consul節點的資訊
__meta_consul_service_address:服務訪問地址
__meta_consul_service_id:服務ID
__meta_consul_service_port:服務埠
__meta_consul_service:服務名稱
__meta_consul_tags:服務包含的標籤資訊
Relabeling 應用與解決問題
詳細 relabel_configs 配置及說明可以參考 relabel_config 官網說明,這裡我簡單列舉一下里面每個 relabel_action 的作用,方便下邊演示。
replace: 根據 regex 的配置匹配 source_labels 標籤的值(注意:多個 source_label 的值會按照 separator 進行拼接),並且將匹配到的值寫入到 target_label 當中,如果有多個匹配組,則可以使用 ${1}, ${2} 確定寫入的內容。如果沒匹配到任何內容則不對 target_label 進行重新, 預設為 replace。
keep: 丟棄 source_labels 的值中沒有匹配到 regex 正則表示式內容的 Target 例項
drop: 丟棄 source_labels 的值中匹配到 regex 正則表示式內容的 Target 例項
hashmod: 將 target_label 設定為關聯的 source_label 的雜湊模組
labelmap: 根據 regex 去匹配 Target 例項所有標籤的名稱(注意是名稱),並且將捕獲到的內容作為為新的標籤名稱,regex 匹配到標籤的的值作為新標籤的值
labeldrop: 對 Target 標籤進行過濾,會移除匹配過濾條件的所有標籤
labelkeep: 對 Target 標籤進行過濾,會移除不匹配過濾條件的所有標籤
解決問題方案
1、問題1方案:
修改Prometheus配置檔案:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'consul'
consul_sd_configs:
- server: '10.10.2.99:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: (.*linux.*|.*devops.*)
action: keep ##對沒有匹配到的表示式進行拋棄
我們可以配置 relabel_configs 來實現標籤過濾,只加載符合規則的服務。以上邊為例,可以通過過濾 __meta_consul_tags 標籤為 linux,devops 的服務,relabel_config 向 Consul 註冊服務的時候,只加載匹配 regex 表示式的標籤的服務到自己的配置檔案。
2、問題2
要實現給服務新增自定義標籤,我們還得做一下修改,就是在註冊服務時,將自定義標籤資訊新增到 Meta Data 資料中,具體可以參考這裡(Consul Service - Agent HTTP API) 官網說明,下邊來演示一下如何操作。
[root@nn-gx-service-java-99~]# curl -X PUT -d '{"id": "node-exporter","name": "node-exporter-10.10.2.99","address": "10.10.2.99","port": 9100,"tags": ["linux"],"Meta":{"app":"linux"},"checks": [{"http": "http://10.10.2.99:9100/metrics", "interval": "5s"}]}' http://10.10.2.99:8500/v1/agent/service/register
然後我們開啟consul找到Meta Data然後我們會發現已經存在了新增的app:linux的值。
修改配置檔案使之生效:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'consul'
consul_sd_configs:
- server: '10.10.2.99:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: (.*linux.*|.*devops.*)
action: keep
- regex: __meta_consul_service_metadata_(.+) #新增meta的重新匹配
action: labelmap #
驗證一下:
我們看到我們新增的標籤{app:linux}已經生效。
3、問題3:在服務發現前提下如何把這些服務區分出來:
這個需求是,我們直接通過標籤匹配的方式把服務區分出來,下面我直接修改配置檔案,通過tag來區分。
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'node-exporter'
consul_sd_configs:
- server: '10.10.2.99:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*linux.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
- job_name: 'docker-exporter'
consul_sd_configs:
- server: '10.10.2.99:8500'
relabel_configs:
- source_labels: [__meta_consul_tags]
regex: .*devops.*
action: keep
- regex: __meta_consul_service_metadata_(.+)
action: labelmap
到此我們consul的基本操作已經完成,當然標籤的操作大家可以深入瞭解。
總結
相比於直接使用靜態配置,在雲環境以及容器環境下我們更多的監控物件都是動態的。通過服務發現,使得Prometheus相比於其他傳統監控解決方案更適用於雲以及容器環境下的監控需求。
@版權宣告:51CTO獨家出品,未經允許不能轉載,否則追究法律責任
留言5
-
wx5ddcd236487b0
1樓2020-03-30 11:27:02
1
老師辛苦啦 ,更新的這幾節筆記還有上傳,麻煩您上傳下 謝謝
-
後面的在git上面有的,可以上去找找相關文件
2020-03-30 15:48:40
回覆
-
-
wx5ddcd236487b0
2樓2020-03-30 15:51:50
好的 不好意思 可能沒發現
-
wx5b925e538fe73
3樓2020-03-31 10:06:03
1
老師 後面的兩節21、22還打算更嗎?
-
21其實已經更新了的,至少這邊老師放到新增裡面了,其實已經講了,22這兩天補充
2020-03-31 14:55:21
回覆
-
-END-