一、Prometheus告警簡介
告警能⼒在Prometheus的架構中被劃分成兩個獨⽴的部分。如下所示,透過在Prometheus中定義AlertRule(告警規則),Prometheus會週期性的對告警規則進⾏計算,如果滿⾜告警觸發條件就會向Alertmanager傳送告警資訊
Alertmanager作為⼀個獨⽴的元件,負責接收並處理來⾃Prometheus Server(也可以是其它的客戶端程式)的告警資訊。Alertmanager可以對這些告警資訊進⾏進⼀步的處理,⽐如當接收到⼤量重複告警時能夠消除重複的告警資訊,同時對告警資訊進⾏分組並且路由到正確的通知⽅,Prometheus內建了對郵件,Slack等多種通知⽅式的⽀持,同時還⽀持與Webhook的整合,以⽀持更多定製化的場景。例如,⽬前還不⽀持釘釘,那⽤戶完全可以透過Webhook與釘釘機器⼈進⾏整合,從⽽透過釘釘接收告警資訊。同時AlertManager還提供了靜默和告警抑制機制來對告警通知⾏為進⾏最佳化。
1.1 Alertmanager特性
- 分組
分組機制可以將詳細的告警資訊合併成⼀個通知。在某些情況下,⽐如由於系統當機導致⼤量的告警被同時觸發,在這種情況下分組機制可以將這些被觸發的告警合併為⼀個告警通知,避免⼀次性接受⼤量的告警通知,⽽⽆法對問題進⾏快速定位
告警分組,告警時間,以及告警的接受⽅式可以透過Alertmanager的配置⽂件進⾏配置。
- 抑制
抑制是指當某⼀告警發出後,可以停⽌重複傳送由此告警引發的其它告警的機制
例如,當叢集不可訪問時觸發了⼀次告警,透過配置Alertmanager可以忽略與該叢集有關的其它所有告警。這樣可以避免接收到⼤量與實際問題⽆關的告警通知
- 靜默
靜默提供了⼀個簡單的機制可以快速根據標籤對告警進⾏靜默處理。如果接收到的告警符合靜默的配置,Alertmanager則不會傳送告警通知。
靜默設定需要在Alertmanager的Werb⻚⾯上進⾏設定。
二、Alertmanager配置概述
version: '3.3' volumes: prometheus_data: {} grafana_data: {} networks: monitoring: driver: bridge services: prometheus: image: prom/prometheus:v2.37.6 container_name: prometheus restart: always volumes: - /etc/localtime:/etc/localtime:ro - ./prometheus/:/etc/prometheus/ - prometheus_data:/prometheus 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' #熱載入配置 - '--web.enable-lifecycle' #api配置 #- '--web.enable-admin-api' #歷史資料最大保留時間,預設15天 - '--storage.tsdb.retention.time=30d' networks: - monitoring links: - alertmanager - cadvisor - node_exporter expose: - '9090' ports: - 9090:9090 depends_on: - cadvisor alertmanager: image: prom/alertmanager:v0.25.0 container_name: alertmanager restart: always volumes: - /etc/localtime:/etc/localtime:ro - ./alertmanager/:/etc/alertmanager/ command: - '--config.file=/etc/alertmanager/config.yml' - '--storage.path=/alertmanager' networks: - monitoring expose: - '9093' ports: - 9093:9093 cadvisor: image: google/cadvisor:latest container_name: cadvisor restart: always volumes: - /etc/localtime:/etc/localtime:ro - /:/rootfs:ro - /var/run:/var/run:rw - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro networks: - monitoring expose: - '8080' node_exporter: image: prom/node-exporter:v1.5.0 container_name: node-exporter restart: always volumes: - /etc/localtime:/etc/localtime:ro - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - '--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host|etc|rootfs/var/lib/docker)($$|/)' networks: - monitoring ports: - '9100:9100' grafana: image: grafana/grafana:9.4.3 container_name: grafana restart: always volumes: - /etc/localtime:/etc/localtime:ro - grafana_data:/var/lib/grafana - ./grafana/provisioning/:/etc/grafana/provisioning/ env_file: - ./grafana/config.monitoring networks: - monitoring links: - prometheus ports: - 3000:3000 depends_on: - prometheus
Alertmanager主要負責對Prometheus產⽣的告警進⾏統⼀處理,因此在Alertmanager配置中⼀般會包含以下⼏個主要部分:
- 全域性配置(global):⽤於定義⼀些全域性的公共引數,如全域性的SMTP配置,Slack配置等內容
- 模板(templates):⽤於定義告警通知時的模板,如HTML模板,郵件模板等
- 告警路由(route):根據標籤匹配,確定當前告警應該如何處理;
- 接收⼈(receivers):接收⼈是⼀個抽象的概念,它可以是⼀個郵箱也可以是微信,Slack或者Webhook等,接收⼈⼀般配合告警路由使⽤
- 抑制規則(inhibit_rules):合理設定抑制規則可以減少垃圾告警的產⽣
完整配置格式如下: global: [ resolve_timeout: <duration> | default = 5m ] [ smtp_from: <tmpl_string> ] [ smtp_smarthost: <string> ] [ smtp_hello: <string> | default = "localhost" ] [ smtp_auth_username: <string> ] [ smtp_auth_password: <secret> ] [ smtp_auth_identity: <string> ] [ smtp_auth_secret: <secret> ] [ smtp_require_tls: <bool> | default = true ] [ slack_api_url: <secret> ] [ victorops_api_key: <secret> ] [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ] [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ] [ opsgenie_api_key: <secret> ] [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ] [ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ] [ hipchat_auth_token: <secret> ] [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi- bin/" ] [ wechat_api_secret: <secret> ] [ wechat_api_corp_id: <string> ] [ http_config: <http_config> ] templates: [ - <filepath> ... ] route: <route> receivers: - <receiver> ... inhibit_rules: [ - <inhibit_rule> ... ]
在全域性配置中需要注意的是 resolve_timeout ,該引數定義了當Alertmanager持續多⻓時間未接收到告警後標記告警狀態為resolved(已解決)。該引數的定義可能會影響到告警恢復通知的接收時間,預設為5分鐘.
三、Prometheus告警規則
Prometheus中的告警規則允許你基於PromQL表示式定義告警觸發條件,Prometheus後端對這些觸發規則進⾏週期性計算,當滿⾜觸發條件後則會觸發告警通知。預設情況下,⽤戶可以透過Prometheus的Web界⾯檢視這些告警規則以及告警的觸發狀態。當Promthues與Alertmanager關聯之後,可以將告警傳送到外部服務如Alertmanager中並透過Alertmanager可以對這些告警進⾏進⼀步的處理。
- 告警規則是配置在prometheus伺服器
3.1 與Alertmanager關聯
Prometheus把產⽣的告警傳送給Alertmanager進⾏告警處理時,需要在Prometheus使⽤的配置⽂件中新增關聯Alertmanager元件的對應配置內容
(1)編輯prometheus.yml⽂件加⼊關聯Alertmanager元件的訪問地址,示例如下:
# Alertmanager 配置
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']
(2)新增監控Alertmanager,讓Prometheus去收集Alertmanager的監控指標。
- job_name: 'alertmanager'
# 覆蓋全域性預設值,每15秒從該作業中刮取一次目標
scrape_interval: 15s
static_configs:
- targets: ['alertmanager:9093']
配置完成重新載入:
curl -X POST http://localhost:9090/-/reload
3.2 配置告警規則
安裝好node_exporter後
3.2.1 Prometheus新增配置
- job_name: 'node-exporter'
scrape_interval: 15s
static_configs:
- targets: ['node_exporter:9100']
labels:
instance: Prometheus伺服器
- targets: ['192.168.10.100:9100']
labels:
instance: test伺服器
3.2.2 建立告警規則檔案
cd /data/docker-prometheus
vim prometheus/alert.yml
# 告警規則
groups:
- name: Prometheus alert
rules:
# 對任何例項超過30秒無法聯絡的情況發出警報
- alert: 服務告警
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "服務異常,例項:{{ $labels.instance }}"
description: "{{ $labels.job }} 服務已關閉"
在告警規則⽂件中,我們可以將⼀組相關的規則設定定義在⼀個group下。在每⼀個group中我們可以定義多個告警規則(rule)。⼀條告警規則主要由以下⼏部分組成
- alert:告警規則的名稱。
- expr:基於PromQL表示式告警觸發條件,⽤於計算是否有時間序列滿⾜該條件。
- for:評估等待時間,可選引數。⽤於表示只有當觸發條件持續⼀段時間後才傳送告警。在等待期間新產⽣告警的狀態為pending。
- labels:⾃定義標籤,允許⽤戶指定要附加到告警上的⼀組附加標籤。
- annotations:⽤於指定⼀組附加資訊,⽐如⽤於描述告警詳細資訊的⽂字等,annotations的內容在告警產⽣時會⼀同作為引數傳送到Alertmanager。
3.2.3 指定載入告警規則
為了能夠讓Prometheus能夠啟⽤定義的告警規則,我們需要在Prometheus全域性配置⽂件中透過rule_files指定⼀組告警規則⽂件的訪問路徑,Prometheus啟動後會⾃動掃描這些路徑下規則⽂件中定義的內容
,並且根據這些規則計算是否向外部傳送通知:
vim prometheus/prometheus.yml
# 報警(觸發器)配置
rule_files:
- "alert.yml"
- "rules/*.yml"
3.2.3 檢視告警狀態
可以在http://192.168.10.14:9090/alerts?search=上檢視告警規則以及其當前所處的活動狀態
http://192.168.10.14:9093/#/alerts
3.2.4 Promql查詢
promql表示式:
up == 0
四、配置告警
4.1 配置郵箱告警
4.1.1 獲取郵箱授權碼並開啟smtp服務
以163郵箱為例,在設定中POP3/SMTP/IMAP中開啟smtp服務,獲取授權碼
4.1.2 修改alertmanager配置
修改alertmanager配置檔案
#docker安裝修改 cd /data/docker-prometheus vim alertmanager/alertmanager.yml #填入如下內容: global: #163伺服器 smtp_smarthost: 'smtp.163.com:465' #發郵件的郵箱 smtp_from: 'cdring@163.com' #發郵件的郵箱使用者名稱,也就是你的郵箱 smtp_auth_username: 'cdring@163.com' #發郵件的郵箱密碼,郵箱授權碼 smtp_auth_password: 'your-password' #tls驗證配置,false為關閉 smtp_require_tls: false route: group_by: ['alertname'] # 當收到告警的時候,等待group_wait配置的時間10s,看是否還有告警,如果有就一起發出去 group_wait: 10s # 如果上次告警資訊傳送成功,此時又來了一個新的告警資料,則需要等待group_interval配置的時間才可以傳送出去 group_interval: 10s # 如果上次告警資訊傳送成功,且問題沒有解決,則等待 repeat_interval配置的時間再次傳送告警資料 repeat_interval: 4h # 全域性報警組,這個引數是必選的,和下面報警組名要相同 receiver: 'email' receivers: - name: 'email' #收郵件的郵箱 email_configs: - to: 'cdring@163.com' send_resolved: true inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'dev', 'instance']
多個收郵件的郵箱賬號配置
receivers: - name: 'email' #收郵件的郵箱 email_configs: - to: 'user1@example.com' - to: 'user2@example.com' - to: 'user3@example.com'
重新載入配置:
curl -X POST http://localhost:9093/-/reload
檢查status狀態:
http://192.168.10.14:9093/#/status
auth_password: <secret>
訪問告警模組web頁面:
http://192.168.10.14:9090/alerts
- INACTIVE:活躍中,即表示正常無告警產生。
- PENDING:待觸發,表示已經達到預設的閾值,但沒達到預設的時間。
- FIRING:表示達到預設的閾值並超過預設的時間觸發告警
4.1.3 測試
停用一個服務可以看看是否有收到報警郵件
4.1.4 使用模版
看需求--不使用模版預設也行
4.1.4.1 建立模版檔案
cd /data/docker-prometheus #建立存放模版的目錄 mkdir alertmanager/template cat > alertmanager/template/email.tmpl <<"EOF" {{ define "email.html" }} {{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }} <h2>@告警通知</h2> 告警程式: prometheus_alert <br> 告警級別: {{ .Labels.severity }} 級 <br> 告警型別: {{ .Labels.alertname }} <br> 故障主機: {{ .Labels.instance }} <br> 告警主題: {{ .Annotations.summary }} <br> 告警詳情: {{ .Annotations.description }} <br> 觸發時間: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} <br> {{ end }}{{ end -}} {{- if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }} <h2>@告警恢復</h2> 告警程式: prometheus_alert <br> 故障主機: {{ .Labels.instance }}<br> 故障主題: {{ .Annotations.summary }}<br> 告警詳情: {{ .Annotations.description }}<br> 告警時間: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}<br> 恢復時間: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}<br> {{ end }}{{ end -}} {{- end }} EOF
4.1.4.2 修改alertmanager配置
vim alertmanager/config.yml #模版配置 templates: - '/etc/alertmanager/template/*.tmpl' .... receivers: - name: 'email' #收郵件的郵箱 email_configs: - to: 'cdring@163.com' #傳送郵件的內容(呼叫模板檔案中的) html: '{{ template "email.html" .}}'
send_resolved: true
過載配置:
curl -X POST http://localhost:9093/-/reload
檢查:
http://192.168.10.14:9093/#/status
測試:
檢視163報警郵件,修改前和修改後的區別
4.2 釘釘告警
4.2.1 釘釘設定
a.註冊企業釘釘
b.填寫企業資料
c. 新增機器人
因為機器人新增,只能是釘釘電腦版(手機版釘釘不能新增機器人)。“測試釘釘報警“ 這個企業只有我一個人,所以我就把報警訊息發到預設的 ”測試釘釘報警 全員群“ 裡面。實際使用時,請建立個運維群--新增對應的人員進來。
電腦釘釘登陸成功後----點選左下角的。。。---然後再點管理後臺,如下圖:
點選之前建立的企業名稱---點選通訊錄---組織架構---新增子部門,批次管理中可以將 成員調整到部門
再檢視釘釘,可以看到一個“運維”部門,開啟運維部門群設定----機器人---新增機器人----新增機器人---自定義---新增----機器人名字----安全設定(IP地址段:一般為alertmanager伺服器地址)---複製webhook,提取access_token
4.2.2 使用prometheus-webhook-dingtalk實現釘釘報警
https://github.com/timonwong/prometheus-webhook-dingtalk/releases
#安裝二進位制安裝包 wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz #解壓 tar vxf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz ls -l #移動並改名 mv prometheus-webhook-dingtalk-2.1.0.linux-amd64 /opt/prometheus-webhook-dingtalk # 建立配置檔案 cat > /opt/prometheus-webhook-dingtalk/config.yml <<"EOF" targets: webhook1: url: https://oapi.dingtalk.com/robot/send?access_token=修改為自己的TOKEN secret: SEC000000000000000000000 EOF # 建立prometheus使用者 useradd -M -s /usr/sbin/nologin prometheus # 修改使用者資料夾許可權 chown prometheus:prometheus -R /opt/prometheus-webhook-dingtalk # 建立systemd服務 cat > /etc/systemd/system/prometheus-webhook-dingtalk.service << "EOF" [Unit] Description=prometheus-webhook-dingtalk Documentation=https://github.com/timonwong/prometheus-webhook-dingtalk [Service] User=prometheus Group=prometheus Restart=on-failure ExecStart=/opt/prometheus-webhook-dingtalk/prometheus-webhook-dingtalk \ --config.file=/opt/prometheus-webhook-dingtalk/config.yml [Install] WantedBy=multi-user.target EOF # 啟動 prometheus-webhook-dingtalk systemctl daemon-reload systemctl start prometheus-webhook-dingtalk.service systemctl enable prometheus-webhook-dingtalk.service
docker安裝prometheus-webhook-dingtalk
#建立資料目錄 mkdir /data/docker-prometheus/prometheus-webhook-dingtalk/ -p # 建立配置檔案config.yml cat > /data/docker-prometheus/prometheus-webhook-dingtalk/config.yml <<"EOF" #templates: # - /etc/prometheus-webhook-dingtalk/templates/default.tmpl targets: webhook1: url: https://oapi.dingtalk.com/robot/send?access_token=之前複製的TOKEN secret: SEC000000000000000000000 #message: # text: '{{ template "default.content" . }}' EOF
docker-compose.yaml檔案
注:我把prometheus-webhook-dingtalk安裝在prometheus伺服器上,如果安裝在其他機器上也是可以的。
cd /data/docker-prometheus/prometheus-webhook-dingtalk/ cat > docker-compose.yaml << "EOF" version: '3.3' services: webhook: image: timonwong/prometheus-webhook-dingtalk:v2.1.0 container_name: prometheus-webhook-dingtalk restart: "always" ports: - 8060:8060 command: - '--config.file=/etc/prometheus-webhook-dingtalk/config.yml' volumes: - ./config.yml:/etc/prometheus-webhook-dingtalk/config.yml - /etc/localtime:/etc/localtime:ro EOF
docker-compose up -d
訪問:http://192.168.10.14:8060/
4.2.3 alertmanager配置
route: receiver: 'dingtalk' # 修改報警方式,必須修改 receivers: - name: 'email' #收郵件的郵箱 email_configs: - to: 'yangxiongchun@163.com' #當告警恢復後,是否傳送郵件 #send_resolved: true html: '{{ template "email.html" .}}' - name: 'dingtalk' webhook_configs: - url: 'http://192.168.10.14:8060/dingtalk/webhook1/send' send_resolved: true
檢查配置
#docker安裝方式,檢查 docker exec -it alertmanager amtool check-config /etc/alertmanager/config.yml #二進位制安裝方式,檢查 /opt/prometheus/alertmanager/amtool check-config /opt/prometheus/alertmanager/alertmanager.yml
載入:
curl -X POST http://localhost:9093/-/reload
4.2.4 配置觸發器
前面已經配置過了
vim prometheus/alert.yml
root@os:/data/docker-prometheus# cat prometheus/alert.yml groups: - name: Prometheus alert rules: # 對任何例項超過30秒無法聯絡的情況發出警報 - alert: 服務告警 expr: up == 0 for:30s labels: severity: critical annotations: summary: "服務異常,例項:{{ $labels.instance }}" description: "{{ $labels.job }} 服務已關閉" - name: node-exporter rules: - alert: HostOutOfMemory expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10 for: 2m labels: severity: warning annotations: summary: "主機記憶體不足,例項:{{ $labels.instance }}" description: "記憶體可用率<10%,當前值:{{ $value }}" - alert: HostMemoryUnderMemoryPressure expr: rate(node_vmstat_pgmajfault[1m]) > 1000 for: 2m labels: severity: warning annotations: summary: "記憶體壓力不足,例項:{{ $labels.instance }}" description: "節點記憶體壓力大。 重大頁面錯誤率高,當前值為:{{ $value }}" - alert: HostUnusualNetworkThroughputIn expr: sum by (instance) (rate(node_network_receive_bytes_total[2m])) / 1024 / 1024 > 100 for: 5m labels: severity: warning annotations: summary: "異常流入網路吞吐量,例項:{{ $labels.instance }}" description: "網路流入流量 > 100 MB/s,當前值:{{ $value }}" - alert: HostUnusualNetworkThroughputOut expr: sum by (instance) (rate(node_network_transmit_bytes_total[2m])) / 1024 / 1024 > 100 for: 5m labels: severity: warning annotations: summary: "異常流出網路吞吐量,例項:{{ $labels.instance }}" description: "網路流出流量 > 100 MB/s,當前值為:{{ $value }}" - alert: HostUnusualDiskReadRate expr: sum by (instance) (rate(node_disk_read_bytes_total[2m])) / 1024 / 1024 > 50 for: 5m labels: severity: warning annotations: summary: "異常磁碟讀取,例項:{{ $labels.instance }}" description: "磁碟讀取> 50 MB/s,當前值:{{ $value }}" - alert: HostUnusualDiskWriteRate expr: sum by (instance) (rate(node_disk_written_bytes_total[2m])) / 1024 / 1024 > 50 for: 2m labels: severity: warning annotations: summary: "異常磁碟寫入,例項:{{ $labels.instance }}" description: "磁碟寫入> 50 MB/s,當前值:{{ $value }}" - alert: HostOutOfDiskSpace expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 10 and ON (instance, device, mountpoint) node_filesystem_readonly == 0 for: 2m labels: severity: warning annotations: summary: "磁碟空間不足告警,例項:{{ $labels.instance }}" description: "剩餘磁碟空間< 10% ,當前值:{{ $value }}" - alert: HostDiskWillFillIn24Hours expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 10 and ON (instance, device, mountpoint) predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs"}[1h], 24 * 3600) < 0 and ON (instance, device, mountpoint) node_filesystem_readonly == 0 for: 2m labels: severity: warning annotations: summary: "磁碟空間將在24小時內耗盡,例項:{{ $labels.instance }}" description: "以當前寫入速率預計磁碟空間將在 24 小時內耗盡,當前值:{{ $value }}" - alert: HostOutOfInodes expr: node_filesystem_files_free{mountpoint ="/"} / node_filesystem_files{mountpoint="/"} * 100 < 10 and ON (instance, device, mountpoint) node_filesystem_readonly{mountpoint="/"} == 0 for: 2m labels: severity: warning annotations: summary: "磁碟Inodes不足,例項:{{ $labels.instance }}" description: "剩餘磁碟 inodes < 10%,當前值: {{ $value }}" - alert: HostUnusualDiskReadLatency expr: rate(node_disk_read_time_seconds_total[1m]) / rate(node_disk_reads_completed_total[1m]) > 0.1 and rate(node_disk_reads_completed_total[1m]) > 0 for: 2m labels: severity: warning annotations: summary: "異常磁碟讀取延遲,例項:{{ $labels.instance }}" description: "磁碟讀取延遲 > 100ms,當前值:{{ $value }}" - alert: HostUnusualDiskWriteLatency expr: rate(node_disk_write_time_seconds_total[1m]) / rate(node_disk_writes_completed_total[1m]) > 0.1 and rate(node_disk_writes_completed_total[1m]) > 0 for: 2m labels: severity: warning annotations: summary: "異常磁碟寫入延遲,例項:{{ $labels.instance }}" description: "磁碟寫入延遲 > 100ms,當前值:{{ $value }}" - alert: high_load expr: node_load1 > 4 for: 2m labels: severity: page annotations: summary: "CPU1分鐘負載過高,例項:{{ $labels.instance }}" description: "CPU1分鐘負載>4,已經持續2分鐘。當前值為:{{ $value }}" - alert: HostCpuIsUnderUtilized expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80 for: 1m labels: severity: warning annotations: summary: "cpu負載高,例項:{{ $labels.instance }}" description: "cpu負載> 80%,當前值:{{ $value }}" - alert: HostCpuStealNoisyNeighbor expr: avg by(instance) (rate(node_cpu_seconds_total{mode="steal"}[5m])) * 100 > 10 for: 0m labels: severity: warning annotations: summary: "CPU竊取率異常,例項:{{ $labels.instance }}" description: "CPU 竊取率 > 10%。 嘈雜的鄰居正在扼殺 VM 效能,或者 Spot 例項可能失去信用,當前值:{{ $value }}" - alert: HostSwapIsFillingUp expr: (1 - (node_memory_SwapFree_bytes / node_memory_SwapTotal_bytes)) * 100 > 80 for: 2m labels: severity: warning annotations: summary: "磁碟swap空間使用率異常,例項:{{ $labels.instance }}" description: "磁碟swap空間使用率>80%" - alert: HostNetworkReceiveErrors expr: rate(node_network_receive_errs_total[2m]) / rate(node_network_receive_packets_total[2m]) > 0.01 for: 2m labels: severity: warning annotations: summary: "異常網路接收錯誤,例項:{{ $labels.instance }}" description: "網路卡{{ $labels.device }}在過去2分鐘接收錯誤率大於0.01,當前值:{{ $value }}" - alert: HostNetworkTransmitErrors expr: rate(node_network_transmit_errs_total[2m]) / rate(node_network_transmit_packets_total[2m]) > 0.01 for: 2m labels: severity: warning annotations: summary: "異常網路傳輸錯誤,例項:{{ $labels.instance }}" description: "網路卡{{ $labels.device }}在過去2分鐘傳輸錯誤率大於0.01,當前值:{{ $value }}" - alert: HostNetworkInterfaceSaturated expr: (rate(node_network_receive_bytes_total{device!~"^tap.*"}[1m]) + rate(node_network_transmit_bytes_total{device!~"^tap.*"}[1m])) / node_network_speed_bytes{device!~"^tap.*"} > 0.8 < 10000 for: 1m labels: severity: warning annotations: summary: "異常網路介面飽和,例項:{{ $labels.instance }}" description: "網路卡{{ $labels.device }}正在超載,當前值{{ $value }}" - alert: HostConntrackLimit expr: node_nf_conntrack_entries / node_nf_conntrack_entries_limit > 0.8 for: 5m labels: severity: warning annotations: summary: "異常連線數,例項:{{ $labels.instance }}" description: "連線數過大,當前連線數:{{ $value }}" - alert: HostClockSkew expr: (node_timex_offset_seconds > 0.05 and deriv(node_timex_offset_seconds[5m]) >= 0) or (node_timex_offset_seconds < -0.05 and deriv(node_timex_offset_seconds[5m]) <= 0) for: 2m labels: severity: warning annotations: summary: "異常時鐘偏差,例項:{{ $labels.instance }}" description: "檢測到時鐘偏差,時鐘不同步。值為:{{ $value }}" - alert: HostClockNotSynchronising expr: min_over_time(node_timex_sync_status[1m]) == 0 and node_timex_maxerror_seconds >= 16 for: 2m labels: severity: warning annotations: summary: "時鐘不同步,例項:{{ $labels.instance }}" description: "時鐘不同步" - alert: NodeFileDescriptorLimit expr: node_filefd_allocated / node_filefd_maximum * 100 > 80 for: 1m labels: severity: warning annotations: summary: "預計核心將很快耗盡檔案描述符限制" description: "{{ $labels.instance }}}已分配的檔案描述符數超過了限制的80%,當前值為:{{ $value }}" - name: nginx rules: # 對任何例項超過30秒無法聯絡的情況發出警報 - alert: NginxDown expr: nginx_up == 0 for: 30s labels: severity: critical annotations: summary: "nginx異常,例項:{{ $labels.instance }}" description: "{{ $labels.job }} nginx已關閉"
檢視釘釘群報警
4.3 企業微信報警
4.3.1 註冊企業微信
瀏覽器開啟https://work.weixin.qq.com/ 點選註冊,填寫資料
4.3.2 webhook告警(和微信應用報警二選一)
新增群機器人
注:因為我這個是測試企業微信,所以就在”企業全員群“,新建群機器人了。真實一般都是新建立個部門,然後把需要接受報警的人拉到這個部門裡面,然後在這個部門群裡面新建機器人。
二進位制安裝alertmanager-wechatrobot-webhook
cd /opt/prometheus/ #下載程式碼 git clone https://gitee.com/linge365/alertmanager-wechatrobot-webhook.git #進入目錄 cd alertmanager-wechatrobot-webhook #把service服務移動到對應目錄下 mv alertmanager-wechatrobot-webhook.service /etc/systemd/system/ #新增prometheus使用者,如果已存在不需要重複新增 useradd -M -s /usr/sbin/nologin prometheus #授權 chown -R prometheu.prometheus /opt/prometheus systemctl start alertmanager-wechatrobot-webhook # 修改alertmanager配置 vim alertmanager/config.yml #增加如下配置 route: receiver: wechat receivers: - name: "wechat" webhook_configs: - url: 'http://192.168.10.14:8999/webhook?key=之前複製的企業微信webhook的key' send_resolved: true #docker安裝方式,檢查 docker exec -it alertmanager amtool check-config /etc/alertmanager/config.yml #二進位制安裝方式,檢查 /opt/alertmanager/alertmanager amtool check-config /etc/alertmanager/config.yml curl -X POST http://localhost:9093/-/reload
4.3.3 微信應用告警(和webhook告警二選一)
- 企業微信應用需要新增ip白名單才能正常使用
- 需要使用一個域名繫結
瀏覽器開啟企業微信官網登入進去
- 建立應用
點選應用管理---建立應用
- 獲取AgentID和秘鑰
建立應用成功後,複製AgentId,和檢視Secret--會傳送Secret到手機企業微信中。
- 配置IP白名單和可信域名並校驗
- 獲取部門ID
- 獲取corp_id
- 修改alertmanager配置
vim alertmanager/config.yml route: receiver: wechat receivers: - name: 'wechat' wechat_configs: - send_resolved: true #to_user: '@all' #傳送給企業微信使用者的ID,@all是所有人 #to_tag: '1' #企業微信中建立的接收告警的標籤 to_party: '1' #部門id agent_id: '1000002' # 企業微信中建立的應用的ID corp_id: 'ww75c7ff0bc812538c' # 企業微信中企業ID api_secret: '-rg8Xtzchefy6w94O6G_qT5gOMhDZt7MsZmHSELAOZw' # 企業微信中,應用的Secret
檢查配置
#docker安裝方式,檢查 docker exec -it alertmanager amtool check-config /etc/alertmanager/config.yml #二進位制安裝方式,檢查 /opt/alertmanager/alertmanager amtool check-config /etc/alertmanager/config.yml
curl -X POST http://localhost:9093/-/reload
檢視prometheus的alerts: http://192.168.10.14:9090/alerts
檢視alertmanager的alerts:http://192.168.10.14:9093/#/alerts
4.3.4 使用模版
(非必需,僅限微信應用告警)
cd /data/docker-prometheus #建立存放模版的目錄 mkdir alertmanager/template cat > alertmanager/template/wechat.tmpl <<"EOF" {{ define "wechat.html" }} {{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }} @告警通知 告警程式: prometheus_alert 告警級別: {{ .Labels.severity }}級別 告警型別: {{ .Labels.alertname }} 故障主機: {{ .Labels.instance }} 告警主題: {{ .Annotations.summary }} 告警詳情: {{ .Annotations.description }} 觸發時間: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} {{ end }}{{ end -}} {{- if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }} @告警恢復 告警程式: prometheus_alert 故障主機: {{ .Labels.instance }} 故障主題: {{ .Annotations.summary }} 告警詳情: {{ .Annotations.description }} 告警時間: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} 恢復時間: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }} {{ end }}{{ end -}} {{- end }} EOF # 修改alertmanager配置 # 增減message #模版配置 templates: - '/etc/alertmanager/template/*.tmpl' .... receivers: - name: 'wechat' wechat_configs: - send_resolved: true #只增加這行配置 message: '{{ template "wechat.html" . }}' # 重新載入 curl -X POST http://localhost:9093/-/reload http://192.168.10.14:9093/#/status