DevOps全链路实战 | 第 13 天：告警规则与 Alertmanager 钉钉/邮件通知渠道配置

第 13/19 天

引言

在前两天的内容中，我们已经完成了 Prometheus 指标采集和 Grafana 可视化看板的搭建。监控数据再丰富，如果没有人去看，也只是一堆沉睡的数字。真正的”可观测性”闭环，必须包含告警这一关键环节——当系统出现异常时，能够第一时间将信息推送到运维人员的眼前。

今天我们要解决的核心问题是：如何定义有价值的告警规则，以及如何通过 Alertmanager 将告警路由到钉钉机器人和邮件双通道，确保关键告警不遗漏、噪音告警不打扰。

核心概念：Prometheus 告警架构

告警的两段式机制

Prometheus 的告警机制分为两个阶段：

Prometheus Server 负责”判定”——根据 PrometheusRule 中定义的 PromQL 表达式，周期性评估指标是否触发阈值。触发后生成一条”firing”状态的告警，发送给 Alertmanager。
Alertmanager 负责”路由与去重”——接收来自 Prometheus 的告警，按标签进行分组、抑制、静默处理，最终通过配置的接收器（receiver）发送到钉钉、邮件、Slack 等渠道。

这种分离设计的好处是：Prometheus 只管”发现异常”，Alertmanager 专管”通知策略”，两者各司其职，便于独立扩展。

Alertmanager 的四个关键能力

分组（Grouping）：将同类告警合并为一条通知，避免告警风暴。例如某个节点宕机引发十几个 Pod 告警，合并成一条消息。
**抑制（Inhibition）：当高级别告警已触发时，自动屏蔽低级别告警。例如节点不可用时，屏蔽该节点上所有 Pod 的告警。
静默（Silence）：运维人员手动设置一段时间内的告警静默，适合维护窗口期间使用。
路由（Routing）：根据告警的标签（severity、team 等）将告警分发到不同的接收器。

实战步骤：配置告警规则与通知渠道

一、部署 Alertmanager

在 Day 11 安装 kube-prometheus-stack 时，Alertmanager 已经作为子组件自动部署。我们先确认其运行状态：

💻 代码示例

# 查看 Alertmanager Pod 状态

kubectl get pods -n monitoring -l app.kubernetes.io/name=alertmanager

# 查看 Alertmanager Service

kubectl get svc -n monitoring -l app.kubernetes.io/name=alertmanager

# 端口转发到本地查看 Web UI

kubectl port-forward -n monitoring svc/prometheus-k8s-alertmanager 9093:9093

浏览器访问 http://localhost:9093 即可看到 Alertmanager 的告警状态页面。

二、定义 PrometheusRule 告警规则

kube-prometheus-stack 自带了丰富的默认告警规则（如节点 CPU 过高、Pod 重启等），但我们需要补充业务相关的自定义规则。通过 PrometheusRule CRD 创建：

💻 代码示例

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

namespace: monitoring

labels:

prometheus: k8s

role: alert-rules

spec:

groups:

– name: k8s-resource-alerts

rules:

# Pod CPU 使用率超过 80% 持续 5 分钟

– alert: PodCpuUsageHigh

expr: |

sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (namespace, pod)

/ sum(kube_pod_container_resource_limits{resource="cpu"}) by (namespace, pod)

> 0.8

for: 5m

labels:

severity: warning

team: devops

annotations:

summary: "Pod CPU 使用率过高 {{ $labels.namespace }}/{{ $labels.pod }}"

description: "CPU 使用率已达 {{ $value | humanizePercentage }}，超过 80% 阈值"

# Pod 内存使用率超过 90%

– alert: PodMemoryUsageHigh

expr: |

sum(container_memory_working_set_bytes{container!=""}) by (namespace, pod)

/ sum(kube_pod_container_resource_limits{resource="memory"}) by (namespace, pod)

> 0.9

for: 5m

labels:

severity: critical

team: devops

annotations:

summary: "Pod 内存使用率过高 {{ $labels.namespace }}/{{ $labels.pod }}"

description: "内存使用率已达 {{ $value | humanizePercentage }}，超过 90% 阈值，可能 OOM"

# PVC 存储使用率超过 85%

– alert: PVCUsageHigh

expr: |

1 – kubelet_volume_stats_available_bytes / kubelet_volume_stats_capacity_bytes > 0.85

for: 10m

labels:

severity: warning

team: devops

annotations:

summary: "PVC 存储空间不足 {{ $labels.persistentvolumeclaim }}"

description: "PVC 使用率 {{ $value | humanizePercentage }}，建议扩容"

应用上述规则：

💻 代码示例

kubectl apply -f custom-alerts-rule.yaml

# 验证规则已被 Prometheus 加载

kubectl exec -n monitoring prometheus-k8s-0 —

wget -qO- http://localhost:9090/api/v1/rules | jq '.data.groups[].rules[].name' | head -20

三、配置钉钉通知渠道

Alertmanager 原生不支持钉钉 Webhook，需要借助 prometheus-alertmanager-dingtalk 适配器（也称为 dingtalk-alert）。我们以 K8s Deployment 方式部署：

💻 代码示例

apiVersion: apps/v1

kind: Deployment

metadata:

namespace: monitoring

spec:

replicas: 1

selector:

matchLabels:

app: dingtalk-webhook

template:

metadata:

labels:

app: dingtalk-webhook

spec:

containers:

– name: dingtalk-webhook

image: timonwong/prometheus-webhook-dingtalk:v2.1.0

args:

– –config.file=/etc/prometheus-webhook-dingtalk/config.yml

ports:

– containerPort: 8060

volumeMounts:

– name: config

mountPath: /etc/prometheus-webhook-dingtalk

volumes:

– name: config

configMap:

—

apiVersion: v1

kind: ConfigMap

metadata:

namespace: monitoring

data:

config.yml: |

targets:

devops_dingtalk:

url: https://oapi.dingtalk.com/robot/send?access_token=YOUR_DINGTALK_TOKEN

secret: YOUR_DINGTALK_SECRET

message:

title: '【{{ .Status | toUpper }}】告警通知'

text: |

### 告警状态: {{ .Status | toUpper }}

**告警名称**: {{ .Labels.alertname }}

**严重级别**: {{ .Labels.severity }}

**命名空间**: {{ .Labels.namespace }}

**实例**: {{ .Labels.pod }}

**触发时间**: {{ .StartsAt }}

**描述**: {{ .Annotations.description }}

—

apiVersion: v1

kind: Service

metadata:

namespace: monitoring

spec:

selector:

app: dingtalk-webhook

ports:

– port: 8060

targetPort: 8060

注意：钉钉机器人的 access_token 和加签 secret 需要在钉钉群设置中创建”自定义机器人”后获取。建议启用加签验证以防泄露。

四、配置 Alertmanager 路由规则

编辑 kube-prometheus-stack 的 values 配置，将 Alertmanager 的路由规则更新为钉钉 + 邮件双通道：

💻 代码示例

alertmanager:

config:

route:

group_by: ['alertname', 'namespace', 'severity']

group_wait: 30s

group_interval: 5m

repeat_interval: 4h

receiver: devops-dingtalk

routes:

# critical 级别同时发钉钉和邮件

– matchers:

– severity = critical

receiver: critical-notify

continue: true

# warning 级别仅发钉钉

– matchers:

– severity = warning

receiver: devops-dingtalk

receivers:

– name: devops-dingtalk

webhook_configs:

– url: http://dingtalk-webhook.monitoring.svc:8060/dingtalk/devops_dingtalk/send

send_resolved: true

– name: critical-notify

webhook_configs:

– url: http://dingtalk-webhook.monitoring.svc:8060/dingtalk/devops_dingtalk/send

send_resolved: true

email_configs:

– to: devops-team@stellardata.top

from: alert@stellardata.top

smarthost: smtp.stellardata.top:587

auth_username: alert@stellardata.top

auth_password: SMTP_PASSWORD_HERE

require_tls: true

headers:

Subject: '【CRITICAL】{{ .CommonLabels.alertname }}'

send_resolved: true

inhibit_rules:

# 节点宕机时屏蔽该节点上所有 Pod 告警

– source_matchers:

– alertname = NodeNotReady

target_matchers:

– alertname =~ "Pod.*"

equal: ['node']

使用 Helm 升级配置：

💻 代码示例

helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack

-n monitoring

-f alertmanager-values.yaml

–version 55.5.0

# 确认 Alertmanager 重载了新配置

kubectl port-forward -n monitoring svc/prometheus-k8s-alertmanager 9093:9093

# 访问 http://localhost:9093/#/status 查看 Status 页面确认配置已加载

五、验证告警链路

我们可以手动触发一条告警来验证整条链路是否通畅：

💻 代码示例

# 使用 promtool 测试告警规则

cat > /tmp/test-alert.yaml << 'EOF'

groups:

– name: test

rules:

– alert: TestAlert

expr: vector(1)

for: 0s

labels:

severity: critical

team: devops

namespace: default

annotations:

summary: "这是一条测试告警"

description: "验证 Alertmanager → 钉钉/邮件通知链路"

EOF

# 临时 Pod 内运行 promtool 发送测试告警

kubectl run promtool-test –rm -it –image=quay.io/prometheus/prometheus:v2.48.0

–restart=Never –command — sh -c

'echo "测试: 请在 Alertmanager UI 查看是否收到 TestAlert"'

正常情况下，钉钉群会收到一条包含告警名称、级别、命名空间的结构化 Markdown 消息，critical 级别还会同时收到邮件。

常见问题

Q1: 告警一直处于 pending 状态不转为 firing？

Prometheus 告警需要满足 for 字段定义的持续时间才会从 pending 转为 firing。例如 for: 5m 表示表达式必须连续 5 分钟满足条件。如果指标波动较大，建议适当延长 for 时间或使用 avg_over_time() 平滑指标。

Q2: 钉钉机器人收到报错 “keyword not in content”？

钉钉自定义机器人有三种安全设置：自定义关键词、加签、IP 白名单。如果选了关键词模式，告警消息内容必须包含设定的关键词（如”告警”）。建议使用加签模式更可靠。

Q3: 邮件通知一直收不到？

检查要点：SMTP 端口是否被集群网络策略阻挡（587/465）、auth_password 是否使用了应用专用密码（Gmail/QQ 邮箱需生成授权码）、require_tls 是否与 SMTP 端口匹配（587 用 true，465 用 false）。

Q4: repeat_interval 设太短导致告警风暴？

repeat_interval 控制同一告警重复发送的间隔。生产环境建议 critical 设为 4h、warning 设为 12h。配合 group_interval 和 inhibit_rules，可以在保证关键告警及时通知的同时避免噪音。

总结

今天我们完成了 DevOps 监控体系中”告警通知”这一关键闭环：

告警规则设计——基于 PrometheusRule CRD 定义了 CPU、内存、存储三类资源告警，使用 for 持续时间过滤瞬时抖动，通过 severity 标签区分告警级别。
钉钉通知渠道——部署 prometheus-webhook-dingtalk 适配器，将 Alertmanager 的标准 Webhook 转换为钉钉机器人 Markdown 消息，启用加签验证保障安全。
邮件通知渠道——针对 critical 级别告警叠加邮件通知，确保最严重的告警通过多通道触达。
路由与抑制——利用 Alertmanager 的分组、路由、抑制三大能力，实现”高级别告警屏蔽低级别告警”的智能降噪。

至此，从指标采集（Day 11）→ 可视化看板（Day 12）→ 告警通知（Day 13）的可观测性三件套已经完整就绪。系统异常可以被发现、被看到、被通知到——这就是可观测性的完整闭环。