最近自己個人嘗試在使用prometheus+grafana監控工作業務上的指標, 但是報警功能還沒有實際用上,但是感覺是很好用,寫下一些啃prometheus官網文檔並且自己用到的一些配置的總結,后續還用到其他東西再更新。如果想深入理解還是請看官方文檔(https://prometheus.io/docs/introduction/overview/)
安裝
直接在操作系統上安裝
略
docker compose
version: "3"
networks:
monitor:
driver: bridge
services:
prometheus:
image: prom/prometheus
container_name: prometheus
restart: always
volumes:
- ./prometheusConfig:/etc/prometheus
- ./data/prometheus:/prometheus
ports:
- "9090:9090"
hostname: prometheus
networks:
- monitor
command:
- "--config.file=/etc/prometheus/prometheus.yml"
- "--storage.tsdb.path=/prometheus"
- "--web.console.libraries=/usr/share/prometheus/console_libraries"
- "--web.console.templates=/usr/share/prometheus/consoles"
- "--storage.tsdb.retention.time=3d"
- "--web.enable-lifecycle"
alertmanager:
image: prom/alertmanager
container_name: alertmanager
hostname: alertmanager
restart: always
ports:
- '9093:9093'
volumes:
- ./data/alertmanager:/alertmanager/data
- ./alertmanager.yml:/alertmanager.yml
command:
- "--config.file=/alertmanager.yml"
networks:
- monitor
grafana:
image: grafana/grafana
container_name: grafana
restart: always
ports:
- "3000:3000"
volumes:
- ./data/grafana:/var/lib/grafana
networks:
- monitor
prometheus
理解
prometheus是一個時序性數據庫,能夠比較高效, 方便的采集時序列數據並以時間建立索引,以及維護數據的存儲時間以免磁盤被打滿。畢竟時序性數據庫主要就是用來監控,監控指標存儲過早之前的數據並沒什么意義。
此外prometheus還提供規則功能,報警規則用於報警,但是prometheus只是做發現以及生成需要報警的消息, 發送報警的工作由alertmanager來完成。
prometheus.yml
# prometheus_config/prometheus.yml
global: # 全局變量
scrape_interval: 1m # 訪問目標間隔 可以在job單獨配置
evaluation_interval: 30s # 訪問規則的間隔
rule_files: # 規則文件
- 'rules/*'
alerting:
alertmanagers:
- scheme: http # 使用http協議發起請求
static-configs:
- targets: [alertmanager:9093]
scrape_configs:
- job_name: 'nginx_demo'
scrape_interval: 10s
#static_configs: # 靜態配置
#- targets: ['192.168.56.100:9100']
file_sd_configs: # 動態配置
- files:
- /etc/prometheus/nginx.yml
refresh_interval: 1m # 刷新時間 即修改后最大生效時間
metrics_path: "/metrics" # 默認數據采集路徑 不配置的話就是 metrics
# prometheus_config/nginx.yml
- targets:
- "192.168.56.100:9100"
metrics接口返回格式
key0 value0
key1 value1
key2{label0=value0} value2
如
nginx_2xx 10234
nginx_3xx 1023
nginx_4xx 12
nginx_5xx{level="error"} 239
報警規則文件 rules/alert.yml
# rules/alert.yml
groups:
- name: nginx_example
rules:
- alert: test
expr: nginx_5xx > 100
for: 1m
labels:
serverity: warning
process: nginx
annotations:
summary: "nginx 5xx is too much"
description: "instance: {{ $labels.instance }} number:{{ $value }}"
alertmanger
理解
alertmanager進程作用是接收來自prometheus進程的報警規則消息后, 進行下一步動作(通知到人), 而alertmanager並不真正關心指標(規則)的具體細節, 而只關心告警規則的labels用於進行路由分類 將告警以合適的方式發送到應當通知到的人而不騷擾其他人。
同時altermanager提供的高級功能則是 將短時間內的報警郵件進行統一發送以及重復持續的報警有間隔的發送, 有過被重復報警刷滿收件箱前幾頁的同學 經常能體會到這個功能的人性化。
但最重要的還是制定好報警規則, 少即是多, 多即是無, 大量無意義的報警不僅只是騷擾到收件人, 更會讓真正需要被注意到的報警被掩蓋,失去報警這件事情原本的意義。
alertmanager.yml
# alertmanager.yml
global:
# 郵件報警設置 都可以在 receiver單獨配置
smtp_from: example@demo.com
smtp_smarthost: smtp.example.org:587
smtp_auth_username: example@demo.com
smtp_auth_password: password
smtp_require_tls: false # 協議是否使用tls 需要注意默認是 true
# 報警時調用api 暫略
route: # 路由 這將會是一個樹形數據結構, 如果不滿足任何子節點 才會使用本節點配置 核心數據是規則的label
receiver: default # 接收者 下面會定義
group_by: ['serverity'] # 分組使用的labels 屬性 如果是 ... 則使用所有labels分組
group_interval: 1m # 針對該組發送報警郵件的間隔 間隔內多封報警會集合后發送一封
repeat_interval: 20m # 相同報警郵件發送頻率間隔 如報警a b兩個規則郵件發送后, c也觸發了則算是新的報警 abc 1m 后一起發送
match: # 全等匹配
serverity: notice
match_re: # 正則匹配
serverity: warning | error
continue: true # 是否嘗試匹配子節點路由 注意 默認是false
routes: # 子節點路由
- [route] # 也是route結構
receivers: # 接收者
- name: default
email_config: # 接受者的郵件設置
to: all@demo.com
grafana
登錄
默認賬號密碼都是admin
增加prometheus作為數據源
- 右邊側邊欄 Configuration --> Data Sources 進入配置頁
- 右上角 Add data source 按鈕 進入增加數據源頁
- 選擇prometheus 並進行host等配置即可
增加第一個簡單折線圖標
在Home頁面 選擇Add dashboard
選擇右上角按鈕 Add panel
選擇Add Query 進入pannel配置頁面
Query 選擇prometheus
可以在一個panel顯示多個指標 這里只弄一個 Metrics框輸入nginx_2xx Min time interval框和采集時間時間間隔保持一致 如 10s
點擊頁面左下角設置圖標 給panel title改為 nginx
保存即可
其他
- panel可以分多個ROW 創建一個新ROW的方法是新建一個panel 點擊conver to row
- row的排序拖動按鈕在row標題最右邊 黑色皮膚下可能會忽略