1. 程式人生 > 其它 >Prometheus+Grafana部署及模板展示(我熬夜成癮,卻換不來你一句晚安。)

Prometheus+Grafana部署及模板展示(我熬夜成癮,卻換不來你一句晚安。)

一、Grafana部署及模板展示

grafana是一款基於go語言開發的通用視覺化工具,支援從不同的資料來源載入並展示資料,可作為其資料來源的部分儲存系統如下所示: TSDB:Prometheus、IfluxDB、OpenTSDB和Graphit 日誌和文件儲存:Loki和ElasitchSearch 分散式請求跟蹤:Zipkin、Jaeger和Tenpo SQL DB:Mysql、PostgreSQL和Microsoft SQL server grafana基礎預設監聽於TCP協議的3000埠,支援整合其他認證服務,且能夠通過/metrics輸出內建指標 資料來源(Data Source):提供用於展示的資料的儲存系統 儀表盤(Dashboard):組織和管理資料的視覺化面板(Panel) 團隊和使用者:提供了面向企業組織層級的管理能力 1.Grafan部署步驟 [root@prometheus ~]# ls grafana-7.3.6-1.x86_64.rpm [root@prometheus ~]# yum install grafana-7.3.6-1.x86_64.rpm -y [root@prometheus ~]# systemctl start grafana-server.service [root@prometheus ~]# ss -antp | grep grafana-server

二、打標籤

1.重新打標定義(在job上定義) 對target重新打標是在資料抓取之前動態重寫target標籤的強大工具,在每個資料抓取配置中,可以定義多個relabel步驟,它們將按照定義的順序依次執行 對於發現的每個target,Prometheus預設會執行如下操作: job的標籤設定為其所屬的job name的值; _address_標籤的值為該target的套接字地址":" instance標籤的值為_address_的值; _scheme_標籤的值為抓取該target上指標時使用的協議(http或https) ; _metrics _path_標籤的值為抓取該target上的指標時使用URI路徑,預設為/metrics; param_標籤的值為傳遞的URL引數中第一個名稱為的引數的值 重新標記期間,還可以使用該target上以"meta "開頭的元標籤; 各服務發現機制為其target新增的元標籤會有所不同; 重新標記完成後,該target上以"_"開頭的所有標籤都會被移除; 若在relabel的過程中需要臨時儲存標籤值,則要使用tmp標籤名稱為字首進行儲存,以避免同Prometheus的內建標籤衝突 2.relabel config(重新打標配置) 修改標籤值、增加刪除標籤,通過呼叫不同引數實現自己的需求 source_labels:指定呼叫哪些已有的標籤(可引用多個)在重新打標的時候會將這些標籤對應的值給引用/提取並連線起來,例如: cpu指標{host=node1; host=node2 } target_labels:與source_labels組合使用,可以指定使用哪個已有標籤賦值給指定的新標籤 separator:對應源標籤的標籤值使用什麼連線符,預設為" ;" regex:對於源標籤,使用哪個正則表示式對源標籤進行模式匹配、匹配後可以將對應的結果複製到target上,賦值方式:(引用所有正則表示式的內容進行賦值) moulus:hash演算法函式 replacement:把目標標籤的值改為新的值 action <relabel_action>:表示重新打標的方式是什麼,以及要實現什麼功能

三、prometheus告警功能

Prometheus對指標的收集、儲存同告警能力分屬於Prometheus Server和AlertManager(通用的元件)兩個獨立的元件,前者僅負責基於"告警規則"生成告警通知,具體的告警操作則由後者完成。Alertmanager負責處理由客戶端發來的告警通知客戶端通常是Prometheus server,但它也支援接收來自其它工具的告警。Alertmanager對告警通知進行分組、去重後,根據路由規則將其路由到不同的receiver,如Email、簡訊或PagerDuty等。目前Alertmanager還不支援釘釘,那使用者完全可以通過Webhook與釘釘機器人進行整合,從而通過釘釘接收告警資訊。同時AltManager還提供了靜默和告警抑制機制來對告警通知行為進行優化 1.告警功能概述 prometheus對指標的收集、儲存與告警能力分屬於Prometheus serve和alertmanager兩個獨立的元件,pro-server只負責通過"告警規則"生成告警通知,具體告警操作是由alertmmanager完成 2.告警規則 是由PromQL編寫的布林值表示式使用>< =與一個常用量值,比如80%進行比較,其返回值為true或false,prometheus-server對抓取到的指標序列與告警規則中做為比較的Prometheus匹配,則會把此樣本值抓取過來作比較,若返回值為true則認為指標異常,不能滿足false,則為正常值以上表達式為告警規則表示式。比如:篩選一個指標資料cpu使用率<0%系統異常 3.通知告警資訊 一旦條件表示式為true了就會觸發通知資訊,送給altermanager,由alter藉助特定服務的API或者訪問入口,將此資訊發出去一般稱為告警媒介,也可以藉助郵件進行告警SMTP 4.prometheus監控系統的告警邏輯 route:告警路由,分組、分類分發告警訊息給不同渠道 prometheus通過alter-rule規則,生成告警通知給altermanager,altermanager會生成本地的告警路由表(第一路由預設稱為根路由,所有的告警資訊都需要一個根路由,沒有一個匹配項,則需要設定一個預設路由)為實現將特定的資訊傳送給特定的使用者。 例如: 按訊息級別來看,嚴重、中等、普通級別,紅色報警、藍色報警,應用傳送方 按分組:業務運維、系統運維、基礎設施運維、k8s運維 5.告警功能 除了基本的告警通知能力外,Altermanager還支援對告警進行去重、分組、抑制 6.靜默、抑制、分組等功能 分組 (Grouping):將相似告警合併為單個告警通知的機制,在系統因大面積故障而觸發告警潮時,分組機制能避免使用者被大量的告警噪聲淹沒,進而導致關鍵資訊的隱沒; 抑制(Inhibition):系統中某個元件或服務故障而觸發告警通知後,那些依賴於該元件或服務的其它元件或服務可能也會因此而觸發告警,抑制便是避免類似的級聯告警的一種特性,從而讓使用者能將精力集中於真正的故障所在; 靜默(silent):是指在一個特定的時間視窗內,即便接收到告警通知,Alertmanager也不會真正向使用者傳送告警資訊的行為;通常,在系統例行維護期間,需要啟用告警系統的靜默特性; 路由(route):用於配置Alertmanager如何處理傳入的特定型別的告警通知,其基本邏輯是根據路由匹配規則的匹配結果來確定處理當前告警通知的路徑和行為

四、部署告警對接郵箱

在prometheus-server端定義告警規則,指定alertmanager的位置,將告警資訊傳送給alert處理 1.安裝altermanager [root@prometheus ~]# cd /opt/ [root@prometheus opt]# ls alertmanager-0.23.0.linux-amd64.tar.gz [root@prometheus opt]# tar zxf alertmanager-0.21.0.linux-amd64.tar.gz -C /usr/local/ [root@prometheus opt]# ln -s /usr/local/alertmanager-0.21.0.linux-amd64/ /usr/local/alertmanager [root@prometheus opt]ln -s /usr/local/prometheus-0.21.0.linux-amd64/prometheus /usr/local/bin 2.檢視配置檔案 [root@prometheus ~]# cat /usr/local/alertmanager-0.21.0.linux-amd64/alertmanager.yml route: #路由資訊 group_by: ['alertname'] #分組 group_wait: 30s #分組緩衝/等待時間 group_interval: 5m #重新分組時間 repeat_interval: 1h #重新告警間隔 receivers: - name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/' #標註5001埠 inhibit_rules: #抑制規則的策略 - source_match: #匹配項 severity: 'critical' #嚴重的級別 target_match: severity: 'warning' #target匹配warning級別 equal: ['alertname', 'dev', 'instance'] #符合alertname、dev、instance 3.修改alertmanager的配置檔案 global: resolve_timeout: 5m smtp_from: [email protected] smtp_auth_username: [email protected] smtp_auth_password: smtp_require_tls: false smtp_smarthost: 'smtp.qq.com:465' route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: 'email-test' receivers: - name: 'email-test' email_configs: ossiocvhdvirbiad - to: [email protected] send_resolved: true 4.配置繫結的郵箱 登入郵箱→設定→賬戶→IMAP/SMTP服務→開啟 5.啟動alertmanager [root@localhost alertmanager]# ./alertmanager 6.相關配置檔案 [root@prometheus ~]# cd /usr/local/alertmanager [root@prometheus alertmanager]# mkdir alert-config [root@prometheus alertmanager]# cd alert-config/ [root@prometheus alert-config]# mkdir -p alert_rules targets [root@prometheus alert-config]# ls alert_rules targets [root@prometheus alert-config]# cd alert_rules/ [root@prometheus alert_rules]# vim instance_down.yaml groups: - name: AllInstances rules: - alert: InstanceDown # Condition for alerting expr: up == 0 for: 20s # Annotation - additional informational labels to store more information annotations: title: 'Instance down' description: Instance has been down for more than 20 seconds.' # Labels - additional labels to be attached to the alert labels: severity: 'critical' ---- [root@prometheus ~]# cd /usr/local/alertmanager/alert-config/targets/ [root@prometheus targets]# vim alertmanagers.yaml - targets: - 192.168.153.20:9093 labels: app: alertmanager ---- [root@prometheus targets]# vim nodes-linux.yaml - targets: - 192.168.153.10:9100 - 192.168.153.20:9100 - 192.168.153.30:9100 labels: app: node-exporter job: node ---- [root@prometheus targets]# vim prometheus-servers.yaml - targets: - 192.168.153.10:9090 labels: app: prometheus job: prometheus 7、配置prometheus啟動檔案 [root@prometheus ~]# cd /usr/local/alertmanager/alert-config/ [root@prometheus alert-config]# vim prometheus.yml # my global config # Author: MageEdu <[email protected]> # Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/ 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: - file_sd_configs: - files: - "targets/alertmanagers*.yaml" # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: - "rules/*.yaml" - "alert_rules/*.yaml" # 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: file_sd_configs: - files: - targets/prometheus-*.yaml refresh_interval: 2m # All nodes - job_name: 'nodes' file_sd_configs: - files: - targets/nodes-*.yaml refresh_interval: 2m - job_name: 'alertmanagers' file_sd_configs: - files: - targets/alertmanagers*.yaml refresh_interval: 2m 8.指定檔案啟動alertmanager [root@prometheus ~]# cd /usr/local/alertmanager [root@prometheus alertmanager]# ./alertmanager 9.指定檔案啟動prometheus [root@prometheus ~]# cd /usr/local/prometheus-2.27.1.linux-amd64/ [root@prometheus prometheus-0.20.0.linux-amd64]# ./prometheus --config.file=./alert-config/prometheus.yml

希望和悲傷,都是一縷光。總有一天,我們會再相遇。