prometheus運維指南
線上使用prometheus主要使用如下組件:
- prometheus
- alertmanager
- blackbox
- node_exporter
自我感覺prometheus這一套學習成本有點高。主要原因可能是太抽象了,有一些地方可能還有一部分開發工作,不過當你完全掌握了這一套報警架構的時候,相信你會覺得這一切都是值得的。
prometheus使用
prometheus,直接官網下載二進制文件,這裡只分享一個線上的啟動命令:
./prometheus --config.file=./prometheus.yml --storage.tsdb.retention=60d --web.enable-lifecycle --storage.tsdb.path=./tsdb_data/ --web.enable-admin-api
prometheus入門的主要難點可能是對如何監控指標有些摸不到頭腦,還有就是不太理解label的含義以及內部一些處理邏輯。
在這裡先分享一個配置文件,這裡以node_exporter為例。
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
- "rules/*.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
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: 'node_exporter_alert'
scrape_interval: 10s
metrics_path: /metrics
file_sd_configs:
- files: ['./file_sd_conf/*.json']
relabel_configs:
- source_labels: [__address__]
regex: (.*):.*
target_label: instance
- source_labels: [__address__]
regex: (.*)
target_label: __address__
replacement: $1:9100
- job_name: 'blackbox-http'
scrape_interval: 5s
metrics_path: /probe
params:
module: [http_2xx]
file_sd_configs:
- files: ['./file_sd_conf/http-*.json']
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: 10.41.144.153:9115
該配置分為四部分:
- global:
抓取(pull)時間間隔,默認是1m,抓取的是下面配置的scrape_configs內的對應配置項。
設置rules評估時間間隔,默認是1m,後面會新建rules目錄存放對應報警規則使用。
- alerting:
告警管理配置,默認配置,只需要修改對應alertmanager的地址即可。 - rule_files:
新增目錄rules來存放對應報警規則,後續會有rules的樣例。 - scrap_configs:
這裡配置的指標採集的配置項,一般靠job_name來區分,新增目錄file_sd_configs存放所有的主機信息。
介紹設計思路
想要打造一個監控平臺,必須要考慮到需要監控的指標在哪,如何獲取其次就是數據怎麼發現,如何更好的把信息準確切詳細的通知出來。
相信大家都會有一個cmdb系統用於存放主機信息,如果沒有自己cmdb信息肯定也會有阿里雲提供給用戶的API用來獲取實時的主機數據,這些數據在業務側需要提供一個定時腳本來把接口的主機信息序列化成prometheus可以識別的json或者yaml格式的數據。線上業務建議每個模塊或者每個應用生成一個獨立的json文件,該文件格式如下:
cat demo.json
[
{
"targets": [
"192.168.0.1:18718/monitor/health"
],
"labels": {
"app": "demo-api",
"hostname": "demo-01",
"port": "18718",
"product": "product-A",
"region": "beijing",
"url": "/monitor/health"
}
},
{
"targets": [
"192.168.0.2:18718/monitor/health"
],
"labels": {
"app": "demo-api",
"hostname": "demo-02",
"port": "18718",
"product": "product-A",
"region": "wuhan",
"url": "/monitor/health"
}
}
]
在此要著重說明幾個配置項,也是難點,很多人如果沒看過官方文檔只是隨便搜了一下如何配置在這裡肯定摸不到頭腦了官方說明
__address__標籤本身是以IP:port的內置標籤,不同監控有不同的內置標籤,如consul有consul的內置標籤,k8s有k8s的內置的meta標籤,具體內部標籤可以在status裡的discover-labels裡面查看,在此不做贅述。targets其實就是prometheus最終要去哪裡獲取對應的數據的endpoint,以node_exporter為例uri就是metrics,blackbox為例就是probe等等。也就是說你需要在通過json文件以及之前在主配置文件裡面配置的相關處理方法讓prometheus最終識別到你想讓他去請求的地址。labels裡面的數據都是可以從cmdb或者阿里雲api裡面獲取到的數據。這些數據後面會以key名為labels的body發送給你的alertmanager,所以這裡儘可能把你想要的數據都打上label。
此處就是將targets的 "192.168.0.1:18718/monitor/health" 通過(.*):.*分組正則拿到ip地址,賦值給instance標籤。然後還把__address__標籤重通過正則分組變成$1:9100用於去獲取node_exporter的數據。
blackbox的監控數據需要修改__address__標籤為整個的url。在此不用進行處理直接使用。9115端口服務會根據你的targets拿到的__address__標籤去請求對應http接口。prometheus只需要從9115端口拿返回的結果就可以了。
規則配置
下面介紹一下具體的報警規則的配置,以node_exporter為例所有的監控指標和說明直接請求對應服務的 9100/metrics 即可展示出來所以可以根據此來配置對應的報警規則。下面內存報警為例:
groups:
- name: "cpu檢測"
rules:
- alert: "cpu負載告警"
expr: (100-(avg(irate(node_cpu_seconds_total{mode="idle",job="node_exporter_alert"}[5m]))by (instance,hostname,region,app,product)) * 100) > 95
for: 1m
labels:
severity: warning
annotations:
value: " {{ $value }} "
summary: "{{ $labels.job}} - {{ $labels.instance }} CPU使用率高於95%"
description: "Prometheus 報警: cpu負載使用率超過95%\n 主機名: {{ $labels.hostname }}\n ip: {{ $labels.instance }}\n 當前值: {{ $value }} \n 應用: {{ $labels.app }} \n 可用區: {{$labels.region}} \n 產品線: {{ $labels.product }} \n"
這裡面要搞清楚2件事情,第一就是可以用job來篩選出來所有的targets也就是要監控的主機組信息,
第二就是通過自定義鍵值對用來,後面用alerts 來把所需要的值取出來,併發送報警。鍵值對類似如下:
{'receiver': 'webhook', 'status': 'firing', 'alerts': [{'status': 'firing', 'labels':
可以依靠status==firing來判斷是報警還是恢復了。大家可以在測試的時候用web.py啟動一個小型的web服務器來查看具體post的數據。
設計報警請求
首先去官網下載alertmanager的二進制文件。修改主配置文件如下:
global:
resolve_timeout: 10s
route:
group_by: ['alertname', 'app']
group_wait: 30s
group_interval: 10s
repeat_interval: 1m
receiver: 'webhook'
receivers:
- name: 'webhook'
webhook_configs:
- url: 'http://127.0.0.1:9347/'
send_resolved: True
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['instance']
可以看到最終是否報警取決於instance維度,所以在prometheus主配置文件配置時,一定要把instance的label統一賦值。
不同其他文件此處需要你自行開發一個接口來實現發送報警消息。此處採用python的小型web應用web.py實現。通過拿到post過來的數據裡面的alerts的值來實現很多邏輯,如根據之前設置的product label發送給不同的人,根據主機,根據報警類型都可以區分開來,此處不再贅述。
線上啟動alertmanager命令如下:
nohup ./alertmanager --config.file=./alertmanager.yml --storage.path=./data/ --log.level=debug --web.listen-address=0.0.0.0:9093 --data.retention=3h >> logs/alertmanager.log 2>&1 &
總結
prometheus的監控性能十分強大,單機跑到1500節點一點問題沒有結合簡單的開發可以實現足夠多的定製化報警需求。也可以自己開發一些簡單的程序甚至是腳本把數據push給gateway來實現監控目的。