Prometheus告警規(guī)則編寫與Alertmanager通知配置實(shí)戰(zhàn)

一、概述

1.1 背景介紹

監(jiān)控系統(tǒng)搭完了，指標(biāo)也采集上來了，但如果沒有告警，等于白搭。我見過不少團(tuán)隊(duì)Prometheus跑得好好的，Grafana大屏也掛在墻上，結(jié)果凌晨3點(diǎn)數(shù)據(jù)庫磁盤寫滿了，第二天早上用戶投訴才發(fā)現(xiàn)。監(jiān)控不閉環(huán)，就是擺設(shè)。

Prometheus的告警分兩部分：Prometheus Server負(fù)責(zé)根據(jù)PromQL表達(dá)式評估告警規(guī)則，觸發(fā)后把告警推給Alertmanager；Alertmanager負(fù)責(zé)去重、分組、路由、靜默，最終通過郵件、釘釘、企業(yè)微信、Webhook等渠道發(fā)出通知。這個分工設(shè)計(jì)得很合理——Prometheus專注數(shù)據(jù)采集和規(guī)則評估，Alertmanager專注通知管理，各司其職。

我們團(tuán)隊(duì)從2020年開始用這套告警體系，目前管理著600多條告警規(guī)則，覆蓋主機(jī)、容器、中間件、業(yè)務(wù)四個層面，日均觸發(fā)告警200-300條，通過分級策略和收斂機(jī)制，實(shí)際推送到人的不超過30條。

1.2 技術(shù)特點(diǎn)

PromQL驅(qū)動的告警規(guī)則：告警條件用PromQL表達(dá)式定義，能寫出非常靈活的判斷邏輯。比如"CPU使用率連續(xù)5分鐘超過85%"、"磁盤空間按當(dāng)前速率24小時內(nèi)會寫滿"、"HTTP錯誤率突然飆升到正常值的3倍"，這些用PromQL都能精確表達(dá)。

路由樹+分組去重：Alertmanager的路由配置是樹狀結(jié)構(gòu)，根據(jù)label匹配把告警分發(fā)到不同的接收器。同一組的告警會合并成一條通知發(fā)送，避免告警風(fēng)暴。我們線上一次網(wǎng)絡(luò)故障觸發(fā)了80多條告警，經(jīng)過分組后只發(fā)了3條通知。

抑制和靜默機(jī)制：抑制（Inhibition）可以設(shè)置告警之間的依賴關(guān)系，比如節(jié)點(diǎn)宕機(jī)時自動抑制該節(jié)點(diǎn)上所有服務(wù)的告警。靜默（Silence）可以在維護(hù)窗口臨時屏蔽特定告警，避免計(jì)劃內(nèi)變更觸發(fā)誤報。

1.3 適用場景

基礎(chǔ)設(shè)施告警：主機(jī)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)異常檢測，服務(wù)進(jìn)程存活監(jiān)控，硬件故障預(yù)警。這是最基礎(chǔ)的告警需求，覆蓋面廣，規(guī)則相對固定。

應(yīng)用服務(wù)告警：HTTP接口的QPS、延遲、錯誤率監(jiān)控，JVM內(nèi)存和GC監(jiān)控，數(shù)據(jù)庫連接池和慢查詢監(jiān)控。需要和開發(fā)團(tuán)隊(duì)配合定義合理的閾值。

業(yè)務(wù)指標(biāo)告警：訂單量異常波動、支付成功率下降、用戶注冊量驟降。這類告警直接關(guān)聯(lián)業(yè)務(wù)，閾值需要根據(jù)業(yè)務(wù)特征動態(tài)調(diào)整。

1.4 環(huán)境要求

二、詳細(xì)步驟

2.1 準(zhǔn)備工作

2.1.1 Alertmanager安裝

# 創(chuàng)建用戶
sudo useradd --no-create-home --shell /bin/falsealertmanager

# 下載Alertmanager
cd/tmp
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar xzf alertmanager-0.27.0.linux-amd64.tar.gz
cdalertmanager-0.27.0.linux-amd64

# 安裝
sudo cp alertmanager /usr/local/bin/
sudo cp amtool /usr/local/bin/
sudo chown alertmanager:alertmanager /usr/local/bin/alertmanager
sudo chown alertmanager:alertmanager /usr/local/bin/amtool

# 創(chuàng)建配置和數(shù)據(jù)目錄
sudo mkdir -p /etc/alertmanager
sudo mkdir -p /var/lib/alertmanager
sudo chown -R alertmanager:alertmanager /etc/alertmanager
sudo chown -R alertmanager:alertmanager /var/lib/alertmanager

# 驗(yàn)證
alertmanager --version

2.1.2 Systemd服務(wù)配置

sudo tee /etc/systemd/system/alertmanager.service > /dev/null <

	

	參數(shù)說明：

	--data.retention=120h：告警數(shù)據(jù)保留5天，默認(rèn)也是120h。這個數(shù)據(jù)是Alertmanager自己的狀態(tài)數(shù)據(jù)（靜默規(guī)則、通知記錄等），不是Prometheus的監(jiān)控數(shù)據(jù)。

	--cluster.listen-address：集群通信端口，多實(shí)例部署時用。單機(jī)可以設(shè)成空字符串禁用。

	--web.external-url：外部訪問地址，告警通知里的鏈接會用這個地址。設(shè)錯了點(diǎn)告警鏈接會404。

	2.1.3 防火墻配置

	
# Alertmanager Web UI和API
sudo ufw allow 9093/tcp
# Alertmanager集群通信
sudo ufw allow 9094/tcp
sudo ufw allow 9094/udp
sudo ufw reload


	

	2.2 核心配置

	2.2.1 Alertmanager主配置文件

	
# 文件路徑：/etc/alertmanager/alertmanager.yml
global:
resolve_timeout:5m
smtp_from:'alertmanager@example.com'
smtp_smarthost:'smtp.example.com:465'
smtp_auth_username:'alertmanager@example.com'
smtp_auth_password:'your_smtp_password'
smtp_require_tls:false

# 通知模板
templates:
-'/etc/alertmanager/templates/*.tmpl'

# 路由樹配置
route:
# 分組依據(jù)，同一組的告警合并發(fā)送
group_by:['alertname','cluster','service']
# 新告警等待時間，等這么久再發(fā)送，讓同組告警有機(jī)會合并
group_wait:30s
# 同一組告警的發(fā)送間隔
group_interval:5m
# 已發(fā)送告警的重復(fù)發(fā)送間隔
repeat_interval:4h
# 默認(rèn)接收器
receiver:'default-webhook'

routes:
 # P0級別 - 核心服務(wù)宕機(jī)，立刻通知
 -match:
   severity:critical
  receiver:'critical-pager'
  group_wait:10s
  repeat_interval:1h
  continue:false

 # P1級別 - 性能告警，5分鐘內(nèi)通知
 -match:
   severity:warning
  receiver:'warning-dingtalk'
  group_wait:30s
  repeat_interval:4h
  continue:false

 # 數(shù)據(jù)庫相關(guān)告警單獨(dú)路由給DBA
 -match_re:
   job:'(mysql|redis|mongodb).*'
  receiver:'dba-dingtalk'
  group_wait:30s
  repeat_interval:2h
  continue:false

 # 業(yè)務(wù)告警路由給對應(yīng)團(tuán)隊(duì)
 -match:
   team:'order'
  receiver:'order-team-webhook'
  continue:false

 -match:
   team:'payment'
  receiver:'payment-team-webhook'
  continue:false

# 抑制規(guī)則
inhibit_rules:
# 節(jié)點(diǎn)宕機(jī)時，抑制該節(jié)點(diǎn)上所有服務(wù)的告警
-source_match:
  alertname:'NodeDown'
 target_match_re:
  alertname:'.+'
 equal:['instance']

# critical級別告警觸發(fā)時，抑制同指標(biāo)的warning告警
-source_match:
  severity:'critical'
 target_match:
  severity:'warning'
 equal:['alertname','instance']

# 接收器配置
receivers:
# 默認(rèn)接收器 - 企業(yè)微信
-name:'default-webhook'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/ops/send'
   send_resolved:true

# P0告警 - 電話+短信+釘釘
-name:'critical-pager'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/critical/send'
   send_resolved:true
  -url:'http://oncall-api.internal:8080/api/v1/alert'
   send_resolved:true
 email_configs:
  -to:'oncall@example.com'
   send_resolved:true
   headers:
    Subject:'[P0-CRITICAL]{{ .GroupLabels.alertname }}'

# Warning告警 - 釘釘群
-name:'warning-dingtalk'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/warning/send'
   send_resolved:true

# DBA告警
-name:'dba-dingtalk'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/dba/send'
   send_resolved:true

# 訂單團(tuán)隊(duì)
-name:'order-team-webhook'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/order/send'
   send_resolved:true

# 支付團(tuán)隊(duì)
-name:'payment-team-webhook'
 webhook_configs:
  -url:'http://localhost:8060/dingtalk/payment/send'
   send_resolved:true


	

	說明：group_wait設(shè)成30秒是經(jīng)過權(quán)衡的。太短了同一批告警來不及合并，太長了延遲通知。P0級別的critical告警我們設(shè)成10秒，因?yàn)檫@類告警寧可多發(fā)也不能晚發(fā)。repeat_interval設(shè)4小時，避免同一個告警反復(fù)騷擾值班人員，但critical級別設(shè)1小時，確保持續(xù)關(guān)注。

	2.2.2 告警規(guī)則文件 - 主機(jī)監(jiān)控

	
# 文件路徑：/etc/prometheus/rules/node_alerts.yml
groups:
-name:node_alerts
 rules:
  -alert:NodeDown
   expr:up{job="node-exporter"}==0
   for:2m
   labels:
    severity:critical
    team:ops
   annotations:
    summary:"節(jié)點(diǎn){{ $labels.instance }}宕機(jī)"
    description:"節(jié)點(diǎn)已超過2分鐘無響應(yīng)，請立即排查"
    runbook:"https://wiki.internal/runbook/node-down"

  -alert:NodeCPUHigh
   expr:|
     1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0.85
   for:5m
   labels:
    severity:warning
    team:ops
   annotations:
    summary:"{{ $labels.instance }}CPU使用率{{ $value | humanizePercentage }}"
    description:"CPU持續(xù)5分鐘超過85%，檢查是否有異常進(jìn)程"

  -alert:NodeMemoryHigh
   expr:|
     1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes > 0.90
   for:5m
   labels:
    severity:warning
    team:ops
   annotations:
    summary:"{{ $labels.instance }}內(nèi)存使用率{{ $value | humanizePercentage }}"

  -alert:NodeDiskAlmostFull
   expr:|
     1 - node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"}
     / node_filesystem_size_bytes{mountpoint="/",fstype!="tmpfs"} > 0.85
   for:5m
   labels:
    severity:warning
    team:ops
   annotations:
    summary:"{{ $labels.instance }}磁盤使用率{{ $value | humanizePercentage }}"

  -alert:NodeDiskWillFull
   expr:|
     predict_linear(
      node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"}[6h], 24*3600
     ) < 0
? ? ? ??for:10m
? ? ? ??labels:
? ? ? ? ??severity:warning
? ? ? ? ??team:ops
? ? ? ??annotations:
? ? ? ? ??summary:"{{ $labels.instance }}?磁盤預(yù)計(jì)24小時內(nèi)寫滿"
? ? ? ? ??description:"按當(dāng)前寫入速率推算，根分區(qū)將在24小時內(nèi)耗盡"

? ? ??-alert:NodeNetworkErrors
? ? ? ??expr:|
? ? ? ? ? rate(node_network_receive_errs_total[5m]) > 10
     or rate(node_network_transmit_errs_total[5m]) > 10
   for:5m
   labels:
    severity:warning
    team:ops
   annotations:
    summary:"{{ $labels.instance }}網(wǎng)卡{{ $labels.device }}出現(xiàn)錯誤包"

  -alert:NodeLoadHigh
   expr:node_load15/countby(instance)(node_cpu_seconds_total{mode="idle"})>2
   for:10m
   labels:
    severity:warning
    team:ops
   annotations:
    summary:"{{ $labels.instance }}15分鐘負(fù)載過高"
    description:"負(fù)載/CPU核數(shù)比值{{ $value }}，超過2說明系統(tǒng)嚴(yán)重過載"


	

	說明：for參數(shù)很關(guān)鍵，設(shè)太短容易誤報，設(shè)太長又延遲告警。CPU和內(nèi)存設(shè)5分鐘是因?yàn)槎虝旱拿毯艹Ｒ?，持續(xù)5分鐘才說明真有問題。NodeDown設(shè)2分鐘，因?yàn)榫W(wǎng)絡(luò)抖動可能導(dǎo)致一兩次采集失敗，2分鐘（約8次采集）能過濾掉大部分誤報。

	2.2.3 告警規(guī)則文件 - 應(yīng)用服務(wù)監(jiān)控

	
# 文件路徑：/etc/prometheus/rules/app_alerts.yml
groups:
-name:app_alerts
 rules:
  -alert:ServiceDown
   expr:up{job=~"app-.*"}==0
   for:1m
   labels:
    severity:critical
   annotations:
    summary:"服務(wù){(diào){ $labels.job }}實(shí)例{{ $labels.instance }}不可達(dá)"

  -alert:HighErrorRate
   expr:|
     sum by(job) (rate(http_requests_total{status=~"5.."}[5m]))
     / sum by(job) (rate(http_requests_total[5m])) > 0.05
   for:3m
   labels:
    severity:critical
   annotations:
    summary:"{{ $labels.job }}HTTP 5xx錯誤率{{ $value | humanizePercentage }}"
    description:"錯誤率超過5%持續(xù)3分鐘，檢查應(yīng)用日志"

  -alert:HighLatencyP99
   expr:|
     histogram_quantile(0.99,
      sum by(job, le) (rate(http_request_duration_seconds_bucket[5m]))
     ) > 2
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"{{ $labels.job }}P99延遲{{ $value | humanizeDuration }}"

  -alert:QPSDropSudden
   expr:|
     sum by(job) (rate(http_requests_total[5m]))
     < sum by(job) (rate(http_requests_total[1h] offset 1d)) * 0.5
? ? ? ??for:10m
? ? ? ??labels:
? ? ? ? ??severity:warning
? ? ? ??annotations:
? ? ? ? ??summary:"{{ $labels.job }}?QPS較昨日同期下降超過50%"
? ? ? ? ??description:"當(dāng)前QPS?{{ $value }}，可能存在流量異常"

? ? ??-alert:JVMHeapHigh
? ? ? ??expr:|
? ? ? ? ? jvm_memory_used_bytes{area="heap"}
? ? ? ? ? / jvm_memory_max_bytes{area="heap"} > 0.85
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"{{ $labels.instance }}JVM堆內(nèi)存使用率{{ $value | humanizePercentage }}"

  -alert:JVMGCTimeHigh
   expr:|
     rate(jvm_gc_pause_seconds_sum[5m])
     / rate(jvm_gc_pause_seconds_count[5m]) > 0.5
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"{{ $labels.instance }}GC平均耗時超過500ms"


	

	2.2.4 釘釘通知模板配置

	
# 安裝prometheus-webhook-dingtalk
cd/tmp
wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz
tar xzf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz
sudo cp prometheus-webhook-dingtalk-2.1.0.linux-amd64/prometheus-webhook-dingtalk /usr/local/bin/

# 文件路徑：/etc/prometheus-webhook-dingtalk/config.yml
targets:
ops:
 url:https://oapi.dingtalk.com/robot/send?access_token=YOUR_OPS_TOKEN
 secret:SEC_YOUR_OPS_SECRET
 message:
  title:'{{ template "ding.link.title" . }}'
  text:'{{ template "ding.link.content" . }}'
critical:
 url:https://oapi.dingtalk.com/robot/send?access_token=YOUR_CRITICAL_TOKEN
 secret:SEC_YOUR_CRITICAL_SECRET
warning:
 url:https://oapi.dingtalk.com/robot/send?access_token=YOUR_WARNING_TOKEN
 secret:SEC_YOUR_WARNING_SECRET
dba:
 url:https://oapi.dingtalk.com/robot/send?access_token=YOUR_DBA_TOKEN
 secret:SEC_YOUR_DBA_SECRET

# Systemd服務(wù)
sudo tee /etc/systemd/system/dingtalk-webhook.service > /dev/null <

	

	2.3 啟動和驗(yàn)證

	2.3.1 啟動服務(wù)

	
# 檢查Alertmanager配置語法
amtool check-config /etc/alertmanager/alertmanager.yml
# 輸出：Checking '/etc/alertmanager/alertmanager.yml' SUCCESS

# 檢查告警規(guī)則語法
promtool check rules /etc/prometheus/rules/node_alerts.yml
promtool check rules /etc/prometheus/rules/app_alerts.yml

# 啟動Alertmanager
sudo systemctl start alertmanager
sudo systemctlenablealertmanager
sudo systemctl status alertmanager

# 重載Prometheus配置使告警規(guī)則生效
curl -X POST http://localhost:9090/-/reload


	

	2.3.2 功能驗(yàn)證

	
# 驗(yàn)證Alertmanager健康狀態(tài)
curl -s http://localhost:9093/-/healthy
# 輸出：OK

# 查看當(dāng)前告警規(guī)則
curl -s http://localhost:9090/api/v1/rules | python3 -m json.tool | head -40

# 查看活躍告警
curl -s http://localhost:9090/api/v1/alerts | python3 -m json.tool

# 用amtool查看Alertmanager狀態(tài)
amtool --alertmanager.url=http://localhost:9093 config show

# 發(fā)送測試告警驗(yàn)證通知鏈路
curl -X POST http://localhost:9093/api/v2/alerts 
 -H'Content-Type: application/json'
 -d'[{
  "labels": {
   "alertname": "TestAlert",
   "severity": "warning",
   "instance": "test-node:9100"
  },
  "annotations": {
   "summary": "這是一條測試告警，驗(yàn)證通知鏈路"
  },
  "startsAt": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"
 }]'

# 等30秒后檢查釘釘群是否收到通知
# 然后發(fā)送resolve清除測試告警
curl -X POST http://localhost:9093/api/v2/alerts 
 -H'Content-Type: application/json'
 -d'[{
  "labels": {
   "alertname": "TestAlert",
   "severity": "warning",
   "instance": "test-node:9100"
  },
  "endsAt": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"
 }]'


	

	說明：每次改完告警規(guī)則或Alertmanager配置，一定要先用amtool和promtool做語法檢查。我們有一次直接reload了一個有語法錯誤的規(guī)則文件，Prometheus沒報錯但那條規(guī)則靜默失效了，直到出了故障才發(fā)現(xiàn)告警沒觸發(fā)。

	三、示例代碼和配置

	3.1 完整配置示例

	3.1.1 K8s集群告警規(guī)則集

	
# 文件路徑：/etc/prometheus/rules/k8s_alerts.yml
groups:
-name:kubernetes_alerts
 rules:
  -alert:KubePodCrashLooping
   expr:|
     rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"Pod{{ $labels.namespace }}/{{ $labels.pod }}頻繁重啟"
    description:"過去15分鐘重啟次數(shù):{{ $value | humanize }}"

  -alert:KubePodNotReady
   expr:|
     sum by(namespace, pod) (
      max by(namespace, pod) (kube_pod_status_phase{phase=~"Pending|Unknown"}) * on(namespace, pod)
      group_left(owner_kind, owner_name) max by(namespace, pod, owner_kind, owner_name) (kube_pod_owner)
     ) > 0
   for:10m
   labels:
    severity:warning
   annotations:
    summary:"Pod{{ $labels.namespace }}/{{ $labels.pod }}超過10分鐘未就緒"

  -alert:KubeDeploymentReplicasMismatch
   expr:|
     kube_deployment_spec_replicas != kube_deployment_status_ready_replicas
   for:10m
   labels:
    severity:warning
   annotations:
    summary:"Deployment{{ $labels.namespace }}/{{ $labels.deployment }}副本數(shù)不匹配"
    description:"期望{{ $labels.spec_replicas }}，實(shí)際就緒{{ $labels.ready_replicas }}"

  -alert:KubeNodeNotReady
   expr:kube_node_status_condition{condition="Ready",status="true"}==0
   for:5m
   labels:
    severity:critical
   annotations:
    summary:"K8s節(jié)點(diǎn){{ $labels.node }}NotReady"

  -alert:KubeContainerOOMKilled
   expr:|
     kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
   for:0m
   labels:
    severity:warning
   annotations:
    summary:"容器{{ $labels.namespace }}/{{ $labels.pod }}/{{ $labels.container }}被OOM Kill"

  -alert:KubePVCAlmostFull
   expr:|
     kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.85
   for:5m
   labels:
    severity:warning
   annotations:
    summary:"PVC{{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }}使用率超過85%"


	

	3.1.2 中間件告警規(guī)則集

	
# 文件路徑：/etc/prometheus/rules/middleware_alerts.yml
groups:
-name:mysql_alerts
 rules:
  -alert:MySQLDown
   expr:mysql_up==0
   for:1m
   labels:
    severity:critical
    team:dba
   annotations:
    summary:"MySQL{{ $labels.instance }}宕機(jī)"

  -alert:MySQLSlowQueries
   expr:rate(mysql_global_status_slow_queries[5m])>0.1
   for:5m
   labels:
    severity:warning
    team:dba
   annotations:
    summary:"MySQL{{ $labels.instance }}慢查詢增多"
    description:"每秒慢查詢數(shù){{ $value }}"

  -alert:MySQLConnectionsHigh
   expr:|
     mysql_global_status_threads_connected
     / mysql_global_variables_max_connections > 0.8
   for:5m
   labels:
    severity:warning
    team:dba
   annotations:
    summary:"MySQL{{ $labels.instance }}連接數(shù)使用率{{ $value | humanizePercentage }}"

-name:redis_alerts
 rules:
  -alert:RedisDown
   expr:redis_up==0
   for:1m
   labels:
    severity:critical
    team:dba
   annotations:
    summary:"Redis{{ $labels.instance }}宕機(jī)"

  -alert:RedisMemoryHigh
   expr:|
     redis_memory_used_bytes / redis_memory_max_bytes > 0.85
   for:5m
   labels:
    severity:warning
    team:dba
   annotations:
    summary:"Redis{{ $labels.instance }}內(nèi)存使用率{{ $value | humanizePercentage }}"

  -alert:RedisRejectedConnections
   expr:increase(redis_rejected_connections_total[5m])>0
   for:1m
   labels:
    severity:warning
    team:dba
   annotations:
    summary:"Redis{{ $labels.instance }}出現(xiàn)連接拒絕"


	

	3.1.3 自定義釘釘通知模板

	
{{/* 文件路徑：/etc/alertmanager/templates/dingtalk.tmpl */}}
{{ define"ding.link.title"}}
{{ifeq (index .Alerts0).Labels.severity"critical"}}[P0-嚴(yán)重]{{else}}[P1-警告]{{ end }} {{ .GroupLabels.alertname }} ({{ .Alerts |len}}條)
{{ end }}

{{ define"ding.link.content"}}
{{ifeq .Status"firing"}}** 告警觸發(fā)**{{else}}** 告警恢復(fù)**{{ end }}

**告警名稱**: {{ .GroupLabels.alertname }}
**告警級別**: {{ (index .Alerts0).Labels.severity }}
**告警數(shù)量**: {{ .Alerts |len}}條
**觸發(fā)時間**: {{ (.Alerts.Firing | first).StartsAt.Local.Format"2006-01-02 1505"}}

{{range.Alerts }}
---
**實(shí)例**: {{ .Labels.instance }}
**摘要**: {{ .Annotations.summary }}
**詳情**: {{ .Annotations.description }}
{{ end }}

[查看詳情]({{ .ExternalURL }}/#/alerts?receiver={{ .Receiver | urlquery }})
{{ end }}


	

	3.2 實(shí)際應(yīng)用案例

	案例一：告警分級策略落地

	場景描述：我們團(tuán)隊(duì)把告警分成P0-P3四個級別，不同級別走不同通知渠道和響應(yīng)時效。這套分級策略跑了兩年多，告警疲勞問題基本解決了。

	分級標(biāo)準(zhǔn)：

				級別
			

				定義
			

				通知方式
			

				響應(yīng)時效
			

				示例
		

				P0
			

				核心服務(wù)不可用
			

				電話+短信+釘釘
			

				5分鐘內(nèi)響應(yīng)
			

				數(shù)據(jù)庫宕機(jī)、支付服務(wù)掛了
		

				P1
			

				服務(wù)降級但可用
			

				釘釘+郵件
			

				15分鐘內(nèi)響應(yīng)
			

				錯誤率超5%、延遲超2秒
		

				P2
			

				資源預(yù)警
			

				釘釘群
			

				1小時內(nèi)處理
			

				磁盤85%、內(nèi)存90%
		

				P3
			

				信息通知
			

				郵件
			

				下個工作日處理
			

				證書30天后過期
		

	實(shí)現(xiàn)方式：在告警規(guī)則的labels里加severity字段，Alertmanager路由樹根據(jù)severity分發(fā)。

	
# Alertmanager路由配置片段
route:
group_by:['alertname','cluster']
receiver:'default'
routes:
 -match:
   severity:critical
  receiver:'p0-pager'
  group_wait:10s
  repeat_interval:30m
 -match:
   severity:warning
  receiver:'p1-dingtalk'
  group_wait:30s
  repeat_interval:4h
 -match:
   severity:info
  receiver:'p2-dingtalk'
  group_wait:1m
  repeat_interval:12h
 -match:
   severity:none
  receiver:'p3-email'
  repeat_interval:24h


	

	案例二：企業(yè)微信Webhook告警腳本

	場景描述：部分團(tuán)隊(duì)用企業(yè)微信而不是釘釘，Alertmanager原生不支持企微，需要通過Webhook中轉(zhuǎn)。我們寫了個輕量的Python腳本做格式轉(zhuǎn)換。

	實(shí)現(xiàn)代碼：

	
#!/usr/bin/env python3
# 文件名：/opt/scripts/wecom_webhook.py
# 功能：接收Alertmanager Webhook，轉(zhuǎn)發(fā)到企業(yè)微信機(jī)器人
# 啟動：python3 /opt/scripts/wecom_webhook.py

importjson
importrequests
fromflaskimportFlask, request

app = Flask(__name__)

WECOM_WEBHOOK_URL ="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_WECOM_KEY"

@app.route('/webhook', methods=['POST'])
defwebhook():
  data = request.json
  status = data.get('status','unknown')
  alerts = data.get('alerts', [])

 ifstatus =='firing':
    color ="warning"
    title =f"告警觸發(fā) ({len(alerts)}條)"
 else:
    color ="info"
    title =f"告警恢復(fù) ({len(alerts)}條)"

  content_lines = [f"##{title}
"]
 foralertinalerts[:10]: # 最多顯示10條
    labels = alert.get('labels', {})
    annotations = alert.get('annotations', {})
    content_lines.append(f"**{labels.get('alertname','N/A')}**")
    content_lines.append(f"> 實(shí)例:{labels.get('instance','N/A')}")
    content_lines.append(f"> 級別:{labels.get('severity','N/A')}")
    content_lines.append(f"> 摘要:{annotations.get('summary','N/A')}
")

  payload = {
   "msgtype":"markdown",
   "markdown": {
     "content":"
".join(content_lines)
    }
  }

  resp = requests.post(WECOM_WEBHOOK_URL, json=payload, timeout=10)
 returnjson.dumps({"status":"ok","wecom_response": resp.status_code})

if__name__ =='__main__':
  app.run(host='0.0.0.0', port=8065)


	

	運(yùn)行結(jié)果：

	
告警觸發(fā) (2條)

NodeCPUHigh
> 實(shí)例: 10.0.1.12:9100
> 級別: warning
> 摘要: 10.0.1.12:9100 CPU使用率 92.3%

NodeMemoryHigh
> 實(shí)例: 10.0.1.12:9100
> 級別: warning
> 摘要: 10.0.1.12:9100 內(nèi)存使用率 94.1%


	

	四、最佳實(shí)踐和注意事項(xiàng)

	4.1 最佳實(shí)踐

	4.1.1 性能優(yōu)化

	告警規(guī)則分組評估：把相關(guān)的告警規(guī)則放在同一個group里，Prometheus會并行評估不同group。我們把600多條規(guī)則分成了12個group，評估耗時從3.2秒降到了0.8秒。

	
# 查看規(guī)則評估耗時
curl -s'http://localhost:9090/api/v1/query?query=prometheus_rule_group_duration_seconds{quantile="0.99"}'| jq .


	

	避免在告警規(guī)則中使用高開銷PromQL：count()、group_left、label_replace這些操作在大數(shù)據(jù)量下很耗CPU。能用Recording Rules預(yù)聚合的先聚合，告警規(guī)則里直接查預(yù)聚合后的指標(biāo)。

	合理設(shè)置evaluation_interval：默認(rèn)15秒評估一次，600條規(guī)則每次評估都要跑一遍PromQL。如果規(guī)則不需要那么高的時效性，可以在group級別設(shè)置更長的interval。比如磁盤空間告警，60秒評估一次完全夠用。

	Alertmanager通知去重：group_by的選擇直接影響告警合并效果。按['alertname', 'cluster']分組，同一個集群同一類告警會合并成一條通知。別把instance放進(jìn)group_by，不然每臺機(jī)器單獨(dú)發(fā)一條，網(wǎng)絡(luò)故障時釘釘群直接被刷屏。

	4.1.2 安全加固

	Alertmanager開啟Basic Auth：和Prometheus一樣，Alertmanager也支持web.yml配置認(rèn)證。裸奔的Alertmanager任何人都能創(chuàng)建靜默規(guī)則，等于能讓告警失效。

	
# /etc/alertmanager/web.yml
basic_auth_users:
admin:$2a$12$KmR3iR5eJx5Oj5Yl5FpNOuJGQwMOsKOqJ7Mcp7hVQ8sKqGzLkjS6


	

	Webhook地址用內(nèi)網(wǎng)：釘釘/企微的Webhook轉(zhuǎn)發(fā)服務(wù)只監(jiān)聽內(nèi)網(wǎng)地址，不要暴露到公網(wǎng)。Webhook URL里包含access_token，泄露了別人就能往你的群里發(fā)消息。

	告警通知脫敏：告警內(nèi)容里不要包含敏感信息，比如數(shù)據(jù)庫連接串、密碼、內(nèi)網(wǎng)IP段。通過模板控制輸出內(nèi)容，只展示必要的診斷信息。

	靜默規(guī)則審計(jì)：定期檢查Alertmanager的靜默規(guī)則，防止有人創(chuàng)建了永久靜默忘記刪除。我們寫了個腳本每天掃描一次，超過7天的靜默規(guī)則自動告警通知。

	4.1.3 高可用配置

	Alertmanager集群模式：生產(chǎn)環(huán)境至少部署3個Alertmanager實(shí)例，通過gossip協(xié)議同步狀態(tài)。Prometheus配置里寫上所有實(shí)例地址，任何一個掛了不影響告警通知。

	
# 實(shí)例1
alertmanager --cluster.listen-address=0.0.0.0:9094 
 --cluster.peer=10.0.1.51:9094 --cluster.peer=10.0.1.52:9094

# 實(shí)例2
alertmanager --cluster.listen-address=0.0.0.0:9094 
 --cluster.peer=10.0.1.50:9094 --cluster.peer=10.0.1.52:9094

# 實(shí)例3
alertmanager --cluster.listen-address=0.0.0.0:9094 
 --cluster.peer=10.0.1.50:9094 --cluster.peer=10.0.1.51:9094


	

	通知渠道冗余：critical級別的告警至少配兩個通知渠道。我們的做法是釘釘+電話，釘釘掛了電話還能打通。曾經(jīng)釘釘API故障了2小時，全靠電話通知兜底。

	備份策略：Alertmanager的靜默規(guī)則和通知狀態(tài)存在--storage.path目錄下，定期備份這個目錄。

	4.2 注意事項(xiàng)

	4.2.1 配置注意事項(xiàng)

	WARNING：告警配置改錯了可能導(dǎo)致關(guān)鍵告警丟失，后果比監(jiān)控掛了還嚴(yán)重。

	for參數(shù)不要設(shè)成0m，除非你確定這個告警不會有瞬時抖動。我們有個同事把CPU告警的for設(shè)成0，結(jié)果每天收到上百條CPU毛刺告警，一周后整個團(tuán)隊(duì)都對告警通知免疫了。

	continue: true要謹(jǐn)慎使用。設(shè)了continue后告警會繼續(xù)匹配下一條路由，可能導(dǎo)致同一條告警發(fā)到多個渠道。除非你確實(shí)需要多渠道通知，否則別加。

	抑制規(guī)則的equal字段必須精確匹配。如果source和target的label名稱不一致，抑制不會生效，而且不會報錯。

	4.2.2 常見錯誤

				錯誤現(xiàn)象
			

				原因分析
			

				解決方案
		

				告警規(guī)則配了但從不觸發(fā)
			

				PromQL表達(dá)式有誤或for時間太長
			

				在Prometheus UI手動執(zhí)行表達(dá)式驗(yàn)證
		

				同一條告警重復(fù)收到通知
			

				group_by配置不當(dāng)導(dǎo)致分組過細(xì)
			

				檢查group_by字段，減少分組維度
		

				告警恢復(fù)通知沒收到
			

				receiver沒配send_resolved: true
			

				在webhook_configs里加上send_resolved
		

				Alertmanager集群狀態(tài)不同步
			

				gossip端口不通或網(wǎng)絡(luò)分區(qū)
			

				檢查9094端口連通性和防火墻規(guī)則
		

				釘釘通知發(fā)送失敗
			

				access_token過期或IP白名單限制
			

				檢查釘釘機(jī)器人配置和安全設(shè)置
		

	4.2.3 兼容性問題

	版本兼容：Alertmanager 0.27對配置文件格式做了一些調(diào)整，match和match_re在未來版本會被matchers替代。建議新項(xiàng)目直接用matchers語法。

	平臺兼容：釘釘機(jī)器人2023年后強(qiáng)制要求加簽或IP白名單，老的Webhook URL直接用會返回310000錯誤碼。企業(yè)微信機(jī)器人對消息格式有長度限制，markdown內(nèi)容超過4096字節(jié)會被截斷。

	組件依賴：prometheus-webhook-dingtalk 2.x版本要求Go 1.19+編譯，低版本系統(tǒng)可能需要手動編譯。

	五、故障排查和監(jiān)控

	5.1 故障排查

	5.1.1 日志查看

	
# 查看Alertmanager日志
sudo journalctl -u alertmanager -f --no-pager

# 查看最近的錯誤
sudo journalctl -u alertmanager --since"1 hour ago"| grep -i"error|warn"

# 查看釘釘Webhook轉(zhuǎn)發(fā)服務(wù)日志
sudo journalctl -u dingtalk-webhook -f --no-pager


	

	5.1.2 常見問題排查

	問題一：告警規(guī)則配了但不觸發(fā)

	
# 檢查規(guī)則是否被Prometheus加載
curl -s http://localhost:9090/api/v1/rules | jq'.data.groups[].rules[] | select(.name=="NodeCPUHigh")'

# 手動執(zhí)行告警表達(dá)式，看是否有返回值
curl -s'http://localhost:9090/api/v1/query?query=1-avg+by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))>0.85'| jq .

# 檢查for條件是否滿足（pending狀態(tài)說明條件滿足但還沒到for時間）
curl -s http://localhost:9090/api/v1/alerts | jq'.data.alerts[] | select(.labels.alertname=="NodeCPUHigh")'


	

	解決方案：

	先在Prometheus UI的Graph頁面手動執(zhí)行PromQL，確認(rèn)有數(shù)據(jù)返回

	檢查for時間是否太長，臨時改短測試

	檢查label是否匹配，job名、instance格式是否和實(shí)際一致

	問題二：告警觸發(fā)了但通知沒收到

	
# 檢查Alertmanager是否收到了告警
curl -s http://localhost:9093/api/v2/alerts | jq'.[0:5]'

# 檢查路由匹配結(jié)果
amtool --alertmanager.url=http://localhost:9093 config routestest
 severity=warning alertname=NodeCPUHigh

# 檢查是否被靜默規(guī)則屏蔽
amtool --alertmanager.url=http://localhost:9093 silence query

# 檢查是否被抑制
curl -s http://localhost:9093/api/v2/alerts | jq'.[] | select(.status.state=="suppressed")'


	

	解決方案：

	確認(rèn)Prometheus配置了正確的Alertmanager地址

	用amtool測試路由匹配，確認(rèn)告警能匹配到正確的receiver

	檢查靜默規(guī)則和抑制規(guī)則是否誤傷

	問題三：Alertmanager集群腦裂

	
# 查看集群成員狀態(tài)
curl -s http://localhost:9093/api/v2/status | jq'.cluster'

# 檢查gossip端口連通性
nc -zv 10.0.1.51 9094
nc -zv 10.0.1.52 9094

# 查看集群日志中的gossip相關(guān)信息
journalctl -u alertmanager | grep -i"gossip|cluster|peer"


	

	解決方案：

	確認(rèn)9094端口TCP和UDP都放通了，gossip協(xié)議兩個都用

	檢查各實(shí)例的--cluster.peer參數(shù)是否正確

	如果網(wǎng)絡(luò)分區(qū)導(dǎo)致腦裂，恢復(fù)網(wǎng)絡(luò)后集群會自動合并

	5.1.3 調(diào)試模式

	
# Alertmanager開啟debug日志
# 修改systemd服務(wù)，添加 --log.level=debug
sudo systemctl edit alertmanager
# 添加 ExecStart 覆蓋

# 查看告警路由匹配過程
amtool --alertmanager.url=http://localhost:9093 config routes show

# 測試特定告警的路由匹配
amtool --alertmanager.url=http://localhost:9093 config routestest
 alertname=NodeDown severity=critical instance=10.0.1.10:9100


	

	5.2 性能監(jiān)控

	5.2.1 關(guān)鍵指標(biāo)監(jiān)控

	
# Alertmanager通知發(fā)送成功率
curl -s'http://localhost:9093/metrics'| grep alertmanager_notifications_total

# 通知發(fā)送延遲
curl -s'http://localhost:9093/metrics'| grep alertmanager_notification_latency

# 當(dāng)前活躍告警數(shù)
curl -s'http://localhost:9093/api/v2/alerts?active=true'| jq'length'

# Prometheus規(guī)則評估耗時
curl -s'http://localhost:9090/metrics'| grep prometheus_rule_group_duration


	

	5.2.2 監(jiān)控指標(biāo)說明

				指標(biāo)名稱
			

				正常范圍
			

				告警閾值
			

				說明
		

				alertmanager_notifications_failed_total
			

				0
			

				>0
			

				通知發(fā)送失敗計(jì)數(shù)
		

				alertmanager_notification_latency_seconds
			

				<5s
			

				>30s
			

				通知發(fā)送延遲
		

				prometheus_rule_group_duration_seconds
			

				<1s
			

				>5s
			

				規(guī)則組評估耗時
		

				prometheus_rule_evaluation_failures_total
			

				0
			

				>0
			

				規(guī)則評估失敗數(shù)
		

				alertmanager_alerts
			

				根據(jù)規(guī)模定
			

				>500
			

				活躍告警數(shù)量
		

	5.2.3 Alertmanager自監(jiān)控告警規(guī)則

	
# 文件路徑：/etc/prometheus/rules/alertmanager_self_rules.yml
groups:
-name:alertmanager_self
 rules:
  -alert:AlertmanagerDown
   expr:up{job="alertmanager"}==0
   for:1m
   labels:
    severity:critical
   annotations:
    summary:"Alertmanager{{ $labels.instance }}宕機(jī)"

  -alert:AlertmanagerNotificationFailed
   expr:increase(alertmanager_notifications_failed_total[5m])>0
   for:1m
   labels:
    severity:critical
   annotations:
    summary:"Alertmanager通知發(fā)送失敗"
    description:"集成{{ $labels.integration }}發(fā)送失敗"

  -alert:AlertmanagerClusterMemberDown
   expr:alertmanager_cluster_members<3
? ? ? ??for:5m
? ? ? ??labels:
? ? ? ? ??severity:warning
? ? ? ??annotations:
? ? ? ? ??summary:"Alertmanager集群成員數(shù)不足3"


	

	5.3 備份與恢復(fù)

	5.3.1 備份策略

	
#!/bin/bash
# 文件名：/opt/scripts/alertmanager_backup.sh
# 備份Alertmanager配置和狀態(tài)數(shù)據(jù)

BACKUP_DIR="/data/backup/alertmanager"
DATE=$(date +%Y%m%d)

mkdir -p"${BACKUP_DIR}"

# 備份配置文件
tar czf"${BACKUP_DIR}/alertmanager_config_${DATE}.tar.gz"
  /etc/alertmanager/ 
  /etc/prometheus/rules/

# 備份狀態(tài)數(shù)據(jù)（靜默規(guī)則等）
tar czf"${BACKUP_DIR}/alertmanager_data_${DATE}.tar.gz"
  /var/lib/alertmanager/

# 清理30天前的備份
find"${BACKUP_DIR}"-name"*.tar.gz"-mtime +30 -delete


	

	5.3.2 恢復(fù)流程

	停止服務(wù)：sudo systemctl stop alertmanager

	恢復(fù)配置：tar xzf /data/backup/alertmanager/alertmanager_config_20241215.tar.gz -C /

	恢復(fù)數(shù)據(jù)：tar xzf /data/backup/alertmanager/alertmanager_data_20241215.tar.gz -C /

	重啟服務(wù)：sudo systemctl start alertmanager

	六、總結(jié)

	6.1 技術(shù)要點(diǎn)回顧

	告警規(guī)則的for參數(shù)是過濾誤報的關(guān)鍵手段。CPU/內(nèi)存類告警設(shè)5分鐘，服務(wù)宕機(jī)類設(shè)1-2分鐘，磁盤預(yù)測類設(shè)10分鐘，這是我們反復(fù)調(diào)優(yōu)后的經(jīng)驗(yàn)值。

	Alertmanager的路由樹設(shè)計(jì)決定了告警通知的效率。按severity分級路由，配合group_by做告警合并，能把日均300條告警收斂到30條有效通知。

	抑制規(guī)則能大幅減少告警風(fēng)暴。節(jié)點(diǎn)宕機(jī)時自動抑制該節(jié)點(diǎn)上所有服務(wù)告警，一次網(wǎng)絡(luò)故障從80條告警收斂到3條通知。

	告警分級策略（P0-P3）是告警治理的基礎(chǔ)。不同級別走不同通知渠道和響應(yīng)時效，避免所有告警一視同仁導(dǎo)致的告警疲勞。

	通知渠道要做冗余，critical級別至少配兩個渠道。釘釘API故障時電話通知兜底，這個設(shè)計(jì)救過我們好幾次。

	6.2 進(jìn)階學(xué)習(xí)方向

	告警自愈（Auto-Remediation）：告警觸發(fā)后自動執(zhí)行修復(fù)腳本，比如磁盤滿了自動清理日志、服務(wù)掛了自動重啟。可以通過Webhook對接自動化平臺實(shí)現(xiàn)。

	實(shí)踐建議：從簡單的場景開始，比如自動重啟崩潰的服務(wù)，逐步擴(kuò)展到更復(fù)雜的自愈場景

	AIOps智能告警：基于歷史告警數(shù)據(jù)做異常檢測，替代固定閾值。Prometheus的predict_linear是最簡單的預(yù)測函數(shù)，更復(fù)雜的可以對接外部ML模型。

	實(shí)踐建議：先用predict_linear做磁盤和流量預(yù)測，積累經(jīng)驗(yàn)后再考慮引入ML模型

	OnCall輪值管理：配合PagerDuty或自建OnCall系統(tǒng)，實(shí)現(xiàn)告警自動分派和升級。值班人員15分鐘沒響應(yīng)自動升級給主管。

	6.3 參考資料

	Alertmanager官方文檔 - 配置參數(shù)和路由規(guī)則詳解

	Awesome Prometheus Alerts - 社區(qū)告警規(guī)則集合

	prometheus-webhook-dingtalk - 釘釘通知轉(zhuǎn)發(fā)工具

	PromQL備忘單 - 告警表達(dá)式編寫參考

	附錄

	A. 命令速查表

	
# Alertmanager操作
amtool check-config /etc/alertmanager/alertmanager.yml # 檢查配置語法
amtool --alertmanager.url=http://localhost:9093 alert query # 查看活躍告警
amtool --alertmanager.url=http://localhost:9093 silence add 
 alertname=NodeCPUHigh -d 2h -c"計(jì)劃維護(hù)"      # 創(chuàng)建2小時靜默
amtool --alertmanager.url=http://localhost:9093 silence query # 查看靜默規(guī)則
amtool --alertmanager.url=http://localhost:9093 silence expire  # 刪除靜默

# 告警規(guī)則操作
promtool check rules /etc/prometheus/rules/*.yml     # 檢查規(guī)則語法
promtooltestrules test_rules.yml            # 單元測試告警規(guī)則
curl -X POST http://localhost:9090/-/reload       # 熱重載規(guī)則


	

	B. 配置參數(shù)詳解

	Alertmanager路由參數(shù)：

				參數(shù)
			

				默認(rèn)值
			

				說明
		

				group_by
			

				[]
			

				告警分組依據(jù)的label列表
		

				group_wait
			

				30s
			

				新告警組等待合并的時間
		

				group_interval
			

				5m
			

				同組告警發(fā)送間隔
		

				repeat_interval
			

				4h
			

				已發(fā)送告警重復(fù)通知間隔
		

				continue
			

				false
			

				匹配后是否繼續(xù)匹配下一條路由
		

				match
			

				-
			

				精確匹配label
		

				match_re
			

				-
			

				正則匹配label
		

				receiver
			

				-
			

				接收器名稱
		

	C. 術(shù)語表

				術(shù)語
			

				英文
			

				解釋
		

				告警規(guī)則
			

				Alert Rule
			

				基于PromQL表達(dá)式定義的告警條件，由Prometheus評估
		

				路由樹
			

				Route Tree
			

				Alertmanager中告警分發(fā)的樹狀匹配結(jié)構(gòu)
		

				分組
			

				Grouping
			

				將相同label的告警合并為一條通知發(fā)送
		

				抑制
			

				Inhibition
			

				當(dāng)某條告警觸發(fā)時自動屏蔽相關(guān)的其他告警
		

				靜默
			

				Silence
			

				在指定時間窗口內(nèi)屏蔽匹配條件的告警通知
		

				接收器
			

				Receiver
			

				告警通知的目標(biāo)渠道配置（郵件、Webhook等）
		

				去重
			

				Deduplication
			

				Alertmanager集群中避免同一告警被多次通知的機(jī)制
		

				for持續(xù)時間
			

				For Duration
			

				告警條件需要持續(xù)滿足的時間，用于過濾瞬時抖動