Prometheus告警規(guī)則編寫(xiě)與Alertmanager通知配置實(shí)戰(zhàn)
Prometheus告警規(guī)則編寫(xiě)與Alertmanager通知配置實(shí)戰(zhàn)
一、概述
1.1 背景介紹
監(jiān)控系統(tǒng)搭完了，指標(biāo)也采集上來(lái)了，但如果沒(méi)有告警，等于白搭。我見(jiàn)過(guò)不少團(tuán)隊(duì)Prometheus跑得好好的，Grafana大屏也掛在墻上，結(jié)果凌晨3點(diǎn)數(shù)據(jù)庫(kù)磁盤(pán)寫(xiě)滿了，第二天早上用戶投訴才發(fā)現(xiàn)。監(jiān)控不閉環(huán)，就是擺設(shè)。
Prometheus的告警分兩部分：Prometheus Server負(fù)責(zé)根據(jù)PromQL表達(dá)式評(píng)估告警規(guī)則，觸發(fā)后把告警推給Alertmanager；Alertmanager負(fù)責(zé)去重、分組、路由、靜默，最終通過(guò)郵件、釘釘、企業(yè)微信、Webhook等渠道發(fā)出通知。這個(gè)分工設(shè)計(jì)得很合理——Prometheus專注數(shù)據(jù)采集和規(guī)則評(píng)估，Alertmanager專注通知管理，各司其職。
我們團(tuán)隊(duì)從2020年開(kāi)始用這套告警體系，目前管理著600多條告警規(guī)則，覆蓋主機(jī)、容器、中間件、業(yè)務(wù)四個(gè)層面，日均觸發(fā)告警200-300條，通過(guò)分級(jí)策略和收斂機(jī)制，實(shí)際推送到人的不超過(guò)30條。
1.2 技術(shù)特點(diǎn)
PromQL驅(qū)動(dòng)的告警規(guī)則：告警條件用PromQL表達(dá)式定義，能寫(xiě)出非常靈活的判斷邏輯。比如"CPU使用率連續(xù)5分鐘超過(guò)85%"、"磁盤(pán)空間按當(dāng)前速率24小時(shí)內(nèi)會(huì)寫(xiě)滿"、"HTTP錯(cuò)誤率突然飆升到正常值的3倍"，這些用PromQL都能精確表達(dá)。
路由樹(shù)+分組去重：Alertmanager的路由配置是樹(shù)狀結(jié)構(gòu)，根據(jù)label匹配把告警分發(fā)到不同的接收器。同一組的告警會(huì)合并成一條通知發(fā)送，避免告警風(fēng)暴。我們線上一次網(wǎng)絡(luò)故障觸發(fā)了80多條告警，經(jīng)過(guò)分組后只發(fā)了3條通知。
抑制和靜默機(jī)制：抑制（Inhibition）可以設(shè)置告警之間的依賴關(guān)系，比如節(jié)點(diǎn)宕機(jī)時(shí)自動(dòng)抑制該節(jié)點(diǎn)上所有服務(wù)的告警。靜默（Silence）可以在維護(hù)窗口臨時(shí)屏蔽特定告警，避免計(jì)劃內(nèi)變更觸發(fā)誤報(bào)。
1.3 適用場(chǎng)景
基礎(chǔ)設(shè)施告警：主機(jī)CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)異常檢測(cè)，服務(wù)進(jìn)程存活監(jiān)控，硬件故障預(yù)警。這是最基礎(chǔ)的告警需求，覆蓋面廣，規(guī)則相對(duì)固定。
應(yīng)用服務(wù)告警：HTTP接口的QPS、延遲、錯(cuò)誤率監(jiān)控，JVM內(nèi)存和GC監(jiān)控，數(shù)據(jù)庫(kù)連接池和慢查詢監(jiān)控。需要和開(kāi)發(fā)團(tuán)隊(duì)配合定義合理的閾值。
業(yè)務(wù)指標(biāo)告警：訂單量異常波動(dòng)、支付成功率下降、用戶注冊(cè)量驟降。這類告警直接關(guān)聯(lián)業(yè)務(wù)，閾值需要根據(jù)業(yè)務(wù)特征動(dòng)態(tài)調(diào)整。
1.4 環(huán)境要求
| 組件 | 版本要求 | 說(shuō)明 |
|---|---|---|
| Prometheus | 2.45+ | 告警規(guī)則評(píng)估引擎，需要和Alertmanager版本匹配 |
| Alertmanager | 0.27+ | 0.27版本修復(fù)了集群模式下的幾個(gè)關(guān)鍵bug |
| 操作系統(tǒng) | CentOS 7+ / Ubuntu 20.04+ | Alertmanager資源消耗很低，1C1G就夠 |
| 網(wǎng)絡(luò) | 內(nèi)網(wǎng)互通 | Prometheus到Alertmanager需要9093端口，Alertmanager集群間需要9094端口 |
| 通知渠道 | 郵件服務(wù)器/釘釘機(jī)器人/企微機(jī)器人 | 至少配一個(gè)通知渠道，建議配兩個(gè)做冗余 |
二、詳細(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ù)說(shuō)明：
--data.retention=120h：告警數(shù)據(jù)保留5天，默認(rèn)也是120h。這個(gè)數(shù)據(jù)是Alertmanager自己的狀態(tài)數(shù)據(jù)（靜默規(guī)則、通知記錄等），不是Prometheus的監(jiān)控?cái)?shù)據(jù)。
--cluster.listen-address：集群通信端口，多實(shí)例部署時(shí)用。單機(jī)可以設(shè)成空字符串禁用。
--web.external-url：外部訪問(wèn)地址，告警通知里的鏈接會(huì)用這個(gè)地址。設(shè)錯(cuò)了點(diǎn)告警鏈接會(huì)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' # 路由樹(shù)配置 route: # 分組依據(jù)，同一組的告警合并發(fā)送 group_by:['alertname','cluster','service'] # 新告警等待時(shí)間，等這么久再發(fā)送，讓同組告警有機(jī)會(huì)合并 group_wait:30s # 同一組告警的發(fā)送間隔 group_interval:5m # 已發(fā)送告警的重復(fù)發(fā)送間隔 repeat_interval:4h # 默認(rèn)接收器 receiver:'default-webhook' routes: # P0級(jí)別 - 核心服務(wù)宕機(jī)，立刻通知 -match: severity:critical receiver:'critical-pager' group_wait:10s repeat_interval:1h continue:false # P1級(jí)別 - 性能告警，5分鐘內(nèi)通知 -match: severity:warning receiver:'warning-dingtalk' group_wait:30s repeat_interval:4h continue:false # 數(shù)據(jù)庫(kù)相關(guān)告警單獨(dú)路由給DBA -match_re: job:'(mysql|redis|mongodb).*' receiver:'dba-dingtalk' group_wait:30s repeat_interval:2h continue:false # 業(yè)務(wù)告警路由給對(duì)應(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ī)時(shí)，抑制該節(jié)點(diǎn)上所有服務(wù)的告警 -source_match: alertname:'NodeDown' target_match_re: alertname:'.+' equal:['instance'] # critical級(jí)別告警觸發(fā)時(shí)，抑制同指標(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
說(shuō)明：group_wait設(shè)成30秒是經(jīng)過(guò)權(quán)衡的。太短了同一批告警來(lái)不及合并，太長(zhǎng)了延遲通知。P0級(jí)別的critical告警我們?cè)O(shè)成10秒，因?yàn)檫@類告警寧可多發(fā)也不能晚發(fā)。repeat_interval設(shè)4小時(shí)，避免同一個(gè)告警反復(fù)騷擾值班人員，但critical級(jí)別設(shè)1小時(shí)，確保持續(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)已超過(guò)2分鐘無(wú)響應(yīng)，請(qǐ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分鐘超過(guò)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 }}磁盤(pán)使用率{{ $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 }}?磁盤(pán)預(yù)計(jì)24小時(shí)內(nèi)寫(xiě)滿" ? ? ? ? ??description:"按當(dāng)前寫(xiě)入速率推算，根分區(qū)將在24小時(shí)內(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)錯(cuò)誤包" -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ù)載過(guò)高" description:"負(fù)載/CPU核數(shù)比值{{ $value }}，超過(guò)2說(shuō)明系統(tǒng)嚴(yán)重過(guò)載"
說(shuō)明：for參數(shù)很關(guān)鍵，設(shè)太短容易誤報(bào)，設(shè)太長(zhǎng)又延遲告警。CPU和內(nèi)存設(shè)5分鐘是因?yàn)槎虝旱拿毯艹Ｒ?jiàn)，持續(xù)5分鐘才說(shuō)明真有問(wèn)題。NodeDown設(shè)2分鐘，因?yàn)榫W(wǎng)絡(luò)抖動(dòng)可能導(dǎo)致一兩次采集失敗，2分鐘（約8次采集）能過(guò)濾掉大部分誤報(bào)。
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錯(cuò)誤率{{ $value | humanizePercentage }}" description:"錯(cuò)誤率超過(guò)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較昨日同期下降超過(guò)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平均耗時(shí)超過(guò)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 啟動(dòng)和驗(yàn)證
2.3.1 啟動(dòng)服務(wù)
# 檢查Alertmanager配置語(yǔ)法 amtool check-config /etc/alertmanager/alertmanager.yml # 輸出：Checking '/etc/alertmanager/alertmanager.yml' SUCCESS # 檢查告警規(guī)則語(yǔ)法 promtool check rules /etc/prometheus/rules/node_alerts.yml promtool check rules /etc/prometheus/rules/app_alerts.yml # 啟動(dòng)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ā)送測(cè)試告警驗(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": "這是一條測(cè)試告警，驗(yàn)證通知鏈路" }, "startsAt": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'" }]' # 等30秒后檢查釘釘群是否收到通知 # 然后發(fā)送resolve清除測(cè)試告警 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)'" }]'
說(shuō)明：每次改完告警規(guī)則或Alertmanager配置，一定要先用amtool和promtool做語(yǔ)法檢查。我們有一次直接reload了一個(gè)有語(yǔ)法錯(cuò)誤的規(guī)則文件，Prometheus沒(méi)報(bào)錯(cuò)但那條規(guī)則靜默失效了，直到出了故障才發(fā)現(xiàn)告警沒(méi)觸發(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:"過(guò)去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 }}超過(guò)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 }}使用率超過(guò)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 }}慢查詢?cè)龆? 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 }} **告警級(jí)別**: {{ (index .Alerts0).Labels.severity }} **告警數(shù)量**: {{ .Alerts |len}}條 **觸發(fā)時(shí)間**: {{ (.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)用案例
案例一：告警分級(jí)策略落地
場(chǎng)景描述：我們團(tuán)隊(duì)把告警分成P0-P3四個(gè)級(jí)別，不同級(jí)別走不同通知渠道和響應(yīng)時(shí)效。這套分級(jí)策略跑了兩年多，告警疲勞問(wèn)題基本解決了。
分級(jí)標(biāo)準(zhǔn)：
| 級(jí)別 | 定義 | 通知方式 | 響應(yīng)時(shí)效 | 示例 |
|---|---|---|---|---|
| P0 | 核心服務(wù)不可用 | 電話+短信+釘釘 | 5分鐘內(nèi)響應(yīng) | 數(shù)據(jù)庫(kù)宕機(jī)、支付服務(wù)掛了 |
| P1 | 服務(wù)降級(jí)但可用 | 釘釘+郵件 | 15分鐘內(nèi)響應(yīng) | 錯(cuò)誤率超5%、延遲超2秒 |
| P2 | 資源預(yù)警 | 釘釘群 | 1小時(shí)內(nèi)處理 | 磁盤(pán)85%、內(nèi)存90% |
| P3 | 信息通知 | 郵件 | 下個(gè)工作日處理 | 證書(shū)30天后過(guò)期 |
實(shí)現(xiàn)方式：在告警規(guī)則的labels里加severity字段，Alertmanager路由樹(shù)根據(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告警腳本
場(chǎng)景描述：部分團(tuán)隊(duì)用企業(yè)微信而不是釘釘，Alertmanager原生不支持企微，需要通過(guò)Webhook中轉(zhuǎn)。我們寫(xiě)了個(gè)輕量的Python腳本做格式轉(zhuǎn)換。
實(shí)現(xiàn)代碼：
#!/usr/bin/env python3
# 文件名：/opt/scripts/wecom_webhook.py
# 功能：接收Alertmanager Webhook，轉(zhuǎn)發(fā)到企業(yè)微信機(jī)器人
# 啟動(dòng)：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"> 級(jí)別:{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 > 級(jí)別: warning > 摘要: 10.0.1.12:9100 CPU使用率 92.3% NodeMemoryHigh > 實(shí)例: 10.0.1.12:9100 > 級(jí)別: warning > 摘要: 10.0.1.12:9100 內(nèi)存使用率 94.1%
四、最佳實(shí)踐和注意事項(xiàng)
4.1 最佳實(shí)踐
4.1.1 性能優(yōu)化
告警規(guī)則分組評(píng)估：把相關(guān)的告警規(guī)則放在同一個(gè)group里，Prometheus會(huì)并行評(píng)估不同group。我們把600多條規(guī)則分成了12個(gè)group，評(píng)估耗時(shí)從3.2秒降到了0.8秒。
# 查看規(guī)則評(píng)估耗時(shí)
curl -s'http://localhost:9090/api/v1/query?query=prometheus_rule_group_duration_seconds{quantile="0.99"}'| jq .
避免在告警規(guī)則中使用高開(kāi)銷PromQL：count()、group_left、label_replace這些操作在大數(shù)據(jù)量下很耗CPU。能用Recording Rules預(yù)聚合的先聚合，告警規(guī)則里直接查預(yù)聚合后的指標(biāo)。
合理設(shè)置evaluation_interval：默認(rèn)15秒評(píng)估一次，600條規(guī)則每次評(píng)估都要跑一遍PromQL。如果規(guī)則不需要那么高的時(shí)效性，可以在group級(jí)別設(shè)置更長(zhǎng)的interval。比如磁盤(pán)空間告警，60秒評(píng)估一次完全夠用。
Alertmanager通知去重：group_by的選擇直接影響告警合并效果。按['alertname', 'cluster']分組，同一個(gè)集群同一類告警會(huì)合并成一條通知。別把instance放進(jìn)group_by，不然每臺(tái)機(jī)器單獨(dú)發(fā)一條，網(wǎng)絡(luò)故障時(shí)釘釘群直接被刷屏。
4.1.2 安全加固
Alertmanager開(kāi)啟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)聽(tīng)內(nèi)網(wǎng)地址，不要暴露到公網(wǎng)。Webhook URL里包含access_token，泄露了別人就能往你的群里發(fā)消息。
告警通知脫敏：告警內(nèi)容里不要包含敏感信息，比如數(shù)據(jù)庫(kù)連接串、密碼、內(nèi)網(wǎng)IP段。通過(guò)模板控制輸出內(nèi)容，只展示必要的診斷信息。
靜默規(guī)則審計(jì)：定期檢查Alertmanager的靜默規(guī)則，防止有人創(chuàng)建了永久靜默忘記刪除。我們寫(xiě)了個(gè)腳本每天掃描一次，超過(guò)7天的靜默規(guī)則自動(dòng)告警通知。
4.1.3 高可用配置
Alertmanager集群模式：生產(chǎn)環(huán)境至少部署3個(gè)Alertmanager實(shí)例，通過(guò)gossip協(xié)議同步狀態(tài)。Prometheus配置里寫(xiě)上所有實(shí)例地址，任何一個(gè)掛了不影響告警通知。
# 實(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í)別的告警至少配兩個(gè)通知渠道。我們的做法是釘釘+電話，釘釘掛了電話還能打通。曾經(jīng)釘釘API故障了2小時(shí)，全靠電話通知兜底。
備份策略：Alertmanager的靜默規(guī)則和通知狀態(tài)存在--storage.path目錄下，定期備份這個(gè)目錄。
4.2 注意事項(xiàng)
4.2.1 配置注意事項(xiàng)
WARNING：告警配置改錯(cuò)了可能導(dǎo)致關(guān)鍵告警丟失，后果比監(jiān)控掛了還嚴(yán)重。
for參數(shù)不要設(shè)成0m，除非你確定這個(gè)告警不會(huì)有瞬時(shí)抖動(dòng)。我們有個(gè)同事把CPU告警的for設(shè)成0，結(jié)果每天收到上百條CPU毛刺告警，一周后整個(gè)團(tuán)隊(duì)都對(duì)告警通知免疫了。
continue: true要謹(jǐn)慎使用。設(shè)了continue后告警會(huì)繼續(xù)匹配下一條路由，可能導(dǎo)致同一條告警發(fā)到多個(gè)渠道。除非你確實(shí)需要多渠道通知，否則別加。
抑制規(guī)則的equal字段必須精確匹配。如果source和target的label名稱不一致，抑制不會(huì)生效，而且不會(huì)報(bào)錯(cuò)。
4.2.2 常見(jiàn)錯(cuò)誤
| 錯(cuò)誤現(xiàn)象 | 原因分析 | 解決方案 |
|---|---|---|
| 告警規(guī)則配了但從不觸發(fā) | PromQL表達(dá)式有誤或for時(shí)間太長(zhǎng) | 在Prometheus UI手動(dòng)執(zhí)行表達(dá)式驗(yàn)證 |
| 同一條告警重復(fù)收到通知 | group_by配置不當(dāng)導(dǎo)致分組過(guò)細(xì) | 檢查group_by字段，減少分組維度 |
| 告警恢復(fù)通知沒(méi)收到 | receiver沒(méi)配send_resolved: true | 在webhook_configs里加上send_resolved |
| Alertmanager集群狀態(tài)不同步 | gossip端口不通或網(wǎng)絡(luò)分區(qū) | 檢查9094端口連通性和防火墻規(guī)則 |
| 釘釘通知發(fā)送失敗 | access_token過(guò)期或IP白名單限制 | 檢查釘釘機(jī)器人配置和安全設(shè)置 |
4.2.3 兼容性問(wèn)題
版本兼容：Alertmanager 0.27對(duì)配置文件格式做了一些調(diào)整，match和match_re在未來(lái)版本會(huì)被matchers替代。建議新項(xiàng)目直接用matchers語(yǔ)法。
平臺(tái)兼容：釘釘機(jī)器人2023年后強(qiáng)制要求加簽或IP白名單，老的Webhook URL直接用會(huì)返回310000錯(cuò)誤碼。企業(yè)微信機(jī)器人對(duì)消息格式有長(zhǎng)度限制，markdown內(nèi)容超過(guò)4096字節(jié)會(huì)被截?cái)唷?/p>
組件依賴：prometheus-webhook-dingtalk 2.x版本要求Go 1.19+編譯，低版本系統(tǒng)可能需要手動(dòng)編譯。
五、故障排查和監(jiān)控
5.1 故障排查
5.1.1 日志查看
# 查看Alertmanager日志 sudo journalctl -u alertmanager -f --no-pager # 查看最近的錯(cuò)誤 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 常見(jiàn)問(wèn)題排查
問(wèn)題一：告警規(guī)則配了但不觸發(fā)
# 檢查規(guī)則是否被Prometheus加載
curl -s http://localhost:9090/api/v1/rules | jq'.data.groups[].rules[] | select(.name=="NodeCPUHigh")'
# 手動(dòng)執(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)說(shuō)明條件滿足但還沒(méi)到for時(shí)間）
curl -s http://localhost:9090/api/v1/alerts | jq'.data.alerts[] | select(.labels.alertname=="NodeCPUHigh")'
解決方案：
先在Prometheus UI的Graph頁(yè)面手動(dòng)執(zhí)行PromQL，確認(rèn)有數(shù)據(jù)返回
檢查for時(shí)間是否太長(zhǎng)，臨時(shí)改短測(cè)試
檢查label是否匹配，job名、instance格式是否和實(shí)際一致
問(wèn)題二：告警觸發(fā)了但通知沒(méi)收到
# 檢查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測(cè)試路由匹配，確認(rèn)告警能匹配到正確的receiver
檢查靜默規(guī)則和抑制規(guī)則是否誤傷
問(wèn)題三：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é)議兩個(gè)都用
檢查各實(shí)例的--cluster.peer參數(shù)是否正確
如果網(wǎng)絡(luò)分區(qū)導(dǎo)致腦裂，恢復(fù)網(wǎng)絡(luò)后集群會(huì)自動(dòng)合并
5.1.3 調(diào)試模式
# Alertmanager開(kāi)啟debug日志 # 修改systemd服務(wù)，添加 --log.level=debug sudo systemctl edit alertmanager # 添加 ExecStart 覆蓋 # 查看告警路由匹配過(guò)程 amtool --alertmanager.url=http://localhost:9093 config routes show # 測(cè)試特定告警的路由匹配 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ī)則評(píng)估耗時(shí) curl -s'http://localhost:9090/metrics'| grep prometheus_rule_group_duration
5.2.2 監(jiān)控指標(biāo)說(shuō)明
| 指標(biāo)名稱 | 正常范圍 | 告警閾值 | 說(shuō)明 |
|---|---|---|---|
| alertmanager_notifications_failed_total | 0 | >0 | 通知發(fā)送失敗計(jì)數(shù) |
| alertmanager_notification_latency_seconds | <5s | >30s | 通知發(fā)送延遲 |
| prometheus_rule_group_duration_seconds | <1s | >5s | 規(guī)則組評(píng)估耗時(shí) |
| prometheus_rule_evaluation_failures_total | 0 | >0 | 規(guī)則評(píng)估失敗數(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ò)濾誤報(bào)的關(guān)鍵手段。CPU/內(nèi)存類告警設(shè)5分鐘，服務(wù)宕機(jī)類設(shè)1-2分鐘，磁盤(pán)預(yù)測(cè)類設(shè)10分鐘，這是我們反復(fù)調(diào)優(yōu)后的經(jīng)驗(yàn)值。
Alertmanager的路由樹(shù)設(shè)計(jì)決定了告警通知的效率。按severity分級(jí)路由，配合group_by做告警合并，能把日均300條告警收斂到30條有效通知。
抑制規(guī)則能大幅減少告警風(fēng)暴。節(jié)點(diǎn)宕機(jī)時(shí)自動(dòng)抑制該節(jié)點(diǎn)上所有服務(wù)告警，一次網(wǎng)絡(luò)故障從80條告警收斂到3條通知。
告警分級(jí)策略（P0-P3）是告警治理的基礎(chǔ)。不同級(jí)別走不同通知渠道和響應(yīng)時(shí)效，避免所有告警一視同仁導(dǎo)致的告警疲勞。
通知渠道要做冗余，critical級(jí)別至少配兩個(gè)渠道。釘釘API故障時(shí)電話通知兜底，這個(gè)設(shè)計(jì)救過(guò)我們好幾次。
6.2 進(jìn)階學(xué)習(xí)方向
告警自愈（Auto-Remediation）：告警觸發(fā)后自動(dòng)執(zhí)行修復(fù)腳本，比如磁盤(pán)滿了自動(dòng)清理日志、服務(wù)掛了自動(dòng)重啟。可以通過(guò)Webhook對(duì)接自動(dòng)化平臺(tái)實(shí)現(xiàn)。
實(shí)踐建議：從簡(jiǎn)單的場(chǎng)景開(kāi)始，比如自動(dòng)重啟崩潰的服務(wù)，逐步擴(kuò)展到更復(fù)雜的自愈場(chǎng)景
AIOps智能告警：基于歷史告警數(shù)據(jù)做異常檢測(cè)，替代固定閾值。Prometheus的predict_linear是最簡(jiǎn)單的預(yù)測(cè)函數(shù)，更復(fù)雜的可以對(duì)接外部ML模型。
實(shí)踐建議：先用predict_linear做磁盤(pán)和流量預(yù)測(cè)，積累經(jīng)驗(yàn)后再考慮引入ML模型
OnCall輪值管理：配合PagerDuty或自建OnCall系統(tǒng)，實(shí)現(xiàn)告警自動(dòng)分派和升級(jí)。值班人員15分鐘沒(méi)響應(yīng)自動(dòng)升級(jí)給主管。
6.3 參考資料
Alertmanager官方文檔 - 配置參數(shù)和路由規(guī)則詳解
Awesome Prometheus Alerts - 社區(qū)告警規(guī)則集合
prometheus-webhook-dingtalk - 釘釘通知轉(zhuǎn)發(fā)工具
PromQL備忘單 - 告警表達(dá)式編寫(xiě)參考
附錄
A. 命令速查表
# Alertmanager操作 amtool check-config /etc/alertmanager/alertmanager.yml # 檢查配置語(yǔ)法 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小時(shí)靜默 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ī)則語(yǔ)法 promtooltestrules test_rules.yml # 單元測(cè)試告警規(guī)則 curl -X POST http://localhost:9090/-/reload # 熱重載規(guī)則
B. 配置參數(shù)詳解
Alertmanager路由參數(shù)：
| 參數(shù) | 默認(rèn)值 | 說(shuō)明 |
|---|---|---|
| group_by | [] | 告警分組依據(jù)的label列表 |
| group_wait | 30s | 新告警組等待合并的時(shí)間 |
| group_interval | 5m | 同組告警發(fā)送間隔 |
| repeat_interval | 4h | 已發(fā)送告警重復(fù)通知間隔 |
| continue | false | 匹配后是否繼續(xù)匹配下一條路由 |
| match | - | 精確匹配label |
| match_re | - | 正則匹配label |
| receiver | - | 接收器名稱 |
C. 術(shù)語(yǔ)表
| 術(shù)語(yǔ) | 英文 | 解釋 |
|---|---|---|
| 告警規(guī)則 | Alert Rule | 基于PromQL表達(dá)式定義的告警條件，由Prometheus評(píng)估 |
| 路由樹(shù) | Route Tree | Alertmanager中告警分發(fā)的樹(shù)狀匹配結(jié)構(gòu) |
| 分組 | Grouping | 將相同label的告警合并為一條通知發(fā)送 |
| 抑制 | Inhibition | 當(dāng)某條告警觸發(fā)時(shí)自動(dòng)屏蔽相關(guān)的其他告警 |
| 靜默 | Silence | 在指定時(shí)間窗口內(nèi)屏蔽匹配條件的告警通知 |
| 接收器 | Receiver | 告警通知的目標(biāo)渠道配置（郵件、Webhook等） |
| 去重 | Deduplication | Alertmanager集群中避免同一告警被多次通知的機(jī)制 |
| for持續(xù)時(shí)間 | For Duration | 告警條件需要持續(xù)滿足的時(shí)間，用于過(guò)濾瞬時(shí)抖動(dòng) |
-
容器
+關(guān)注
關(guān)注
0文章
535瀏覽量
23020 -
Prometheus
+關(guān)注
關(guān)注
0文章
36瀏覽量
2072
原文標(biāo)題：企業(yè)級(jí)監(jiān)控告警落地：Prometheus 規(guī)則分層與 Alertmanager 通知編排
文章出處：【微信號(hào)：magedu-Linux，微信公眾號(hào)：馬哥Linux運(yùn)維】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
Prometheus的基本原理與開(kāi)發(fā)指南
IR615配置流量告警方法
基于人工智能的網(wǎng)絡(luò)告警關(guān)聯(lián)分析處理方法
prometheus做監(jiān)控服務(wù)的整個(gè)流程介紹
編寫(xiě)PCB設(shè)計(jì)規(guī)則檢查器技巧
編寫(xiě)屬于自己的PCB設(shè)計(jì)規(guī)則檢查器
加權(quán)增量關(guān)聯(lián)規(guī)則挖掘在通信告警預(yù)測(cè)中的應(yīng)用說(shuō)明
可視化操作的告警軟件背景現(xiàn)狀
Prometheus API使用介紹
系統(tǒng)監(jiān)控相關(guān)知識(shí)及釘釘機(jī)器人告警腳本編寫(xiě)
SpringBoot+Prometheus+Grafana實(shí)現(xiàn)自定義監(jiān)控
prometheus下載安裝教程
Prometheus實(shí)戰(zhàn)篇:Exporter知識(shí)概述
工商網(wǎng)監(jiān)
評(píng)論