Alerts和通知：PagerDuty, Opsgenie

Alerts和通知： PagerDuty, Opsgenie

1）为什么需要一个单独的Alert平台

目标是立即向合适的人/团队发出相关信号，并启动事件过程：承认（ack），升级，沟通，验尸。PagerDuty和Opsgenie给出：

按服务/标记/环境路由。
升级和时间表（职责，追随太阳）。
重复数据消除/事件相关性。
安静的窗户（维护/freeze）和薄荷规则。
与监控，CI/CD和ChatOps集成。

支持：SLO阈值→ alert →人/自动机→ runbook →回滚/假→验尸。

2）信号模型和严重性（severity）

建议的量表：

critical （page）-SLO违规行为/现金路径错误（存款/退款）,可用性下降,burn-rate。
高度（page/tiket）是没有明显的SLO击穿的显着降解。
medium （tiket）-容量、后退降解、后退。
low （inform）-趋势,警告。

规则：页面仅通过SLO或显式业务触发。

3）路由架构

1.源（Prometheus/Alertmanager，Grafana，云监视，专有的webhooks）。

2.Шлюз (PagerDuty/Opsgenie service/integration).

3.策略：按标签（'service'，'env'，'region'），severity，payload的路线。
4.升级：服务级别的顺序（L1→L2→menedzher）。

5.通讯： ChatOps频道,状态页面,邮件.

关键标签示例（标准化）

"service"，"env"，"region"，"version"，"runbook"，"release_id"，"route"，"tenant"（如果B2V/多重特南特）。

4）呼叫和升级时间表

Schedules: primary/secondary, роли (SRE, DBRE, Sec).

Rotations：白天/夜间，追随太阳，周末。
Overrides：休假/生病。
升级：ack-taymaut 5-10分钟→下一层。按工作时间-到专业部门；在场外打电话。

提示：在夜间保持简短的升级步骤（减少疲劳）和白天更长（有上下文）。

5）与Alertmanager的集成（基本模式）

yaml receivers:
- name: pagerduty pagerduty_configs:
- routing_key: ${PAGERDUTY_ROUTING_KEY}
severity: '{{ if eq. Labels. severity "critical" }}critical{{ else }}error{{ end }}'
class: '{{.Labels. service }}'
component: '{{.Labels. env }}'
group: '{{.Labels. region }}'
description: '{{.Annotations. summary }}'
details:
service: '{{.Labels. service }}'
env: '{{.Labels. env }}'
runbook: '{{.Annotations. runbook }}'
release: '{{.Annotations. release }}'
route:
receiver: pagerduty group_by: ["service","env","region"]
group_wait: 30s group_interval: 5m repeat_interval: 2h

Opsgenie (webhook)

yaml receivers:
- name: opsgenie opsgenie_configs:
- api_key: ${OPSGENIE_API_KEY}
responders:
- name: "SRE Primary"
type: team priority: '{{ if eq. Labels. severity "critical" }}P1{{ else }}P3{{ end }}'
details:
trace: '{{.Labels. trace_id }}'
runbook: '{{.Annotations. runbook }}'

6）噪音，祖父与相关性

Dedup密钥：使用稳定的指纹（例如,service+route+code）。
分组："group_by"通过服务/环境,以便5xx级联不会产生数十页。
Mutes/安静的窗口：在迁移/发布/负载测试期间。
原因是：如果"api-gateway@prod"的P1事件已经发生，请抑制子P2/P3。

反模式：CPU/Memory上的页面没有确认对SLO的影响。

7）与发布和自动操作的联系

在金丝雀除尘器中，PagerDuty/Opsgenie从CI/CD → pause/rollback（Argo Rollouts/Helm）中的SLO门→ webhook获得警报。
Alert包含："release_id"，"image。标题,链接到管线和回滚步骤运行手册。

注释中的链接示例runbook


runbook: https://runbooks. company/rollback/api-gateway#canary

8） ChatOps和通信

在Slack/Teams中自动创建事件通道，绑定到tiket。

Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.

状态页面：P1/P2时自动更新。

9）事件生命周期（最低）

1.触发器（来自SLO/传感器的警报器）。

2.Page (primary on-call).

3.Ack（确认，TTA）。
4.Communicate（频道/状态）。
5.Mitigate（rollback/feature-flag/隔离）。

6.Resolve (TTR).

7.Postmortem（时间线，原因，行动，课程，任务所有者）。

Role-kit: IC (incident commander), Ops lead, Comms, Scribe.

10）有用的payload字段（normalize）

json
{
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"severity": "critical",
"event_class": "slo_burn",
"summary": "Withdraw 5xx > 0. 5% for 10m",
"runbook": "https://runbooks/payments/withdraw-5xx",
"release_id": "rel-2025-11-03-14-20",
"image": "ghcr. io/org/payments:1. 14. 2",
"trace_id": "8a4f0c2e9b1f42d7",
"annotations": { "canary": "25%" }
}

11）信号源集成

Prometheus/Alertmanager是SLO/RED的主要来源。
Grafana Alerting-更容易用于行车记录仪/业务指标。
OpenTelemetry/SpanMetrics是路由上的后端/错误。
K8s事件-群集事故（控制平面,PDB违规）。
DB/队列-lag/locks/replication。
应用的Webhooks是域信号（PSP错误，指纹激增）。

12）政策与合规性

RBAC用于创建/更改策略，时间表，mutes。
审计：谁承认/任命/更改了状态，时间表。
PII最小化为payloads（ID ticket代替用户电子邮件/电话）。
DR计划：在PagerDuty/Opsgenie （fallback频道）不可用时会做什么。

13）实践示例（PagerDuty vs Opsgenie）

一个机会	PagerDuty	Opsgenie
升级/日程安排	成熟、灵活	成熟、灵活
事件角色/模板	强大的事件工作流	Incident Templates/Stakeholders
自动频道/通用	良好的集成	Deep Slack/MS团队
定价/许可证	通常更昂贵，很多地狱	通常在开始时便宜
按标签进行路由	强大（服务目录）	强大（路由规则）
两个平台都关闭了95％的相同脚本；按成本、UX和堆栈集成进行选择。

14）安静的窗户和霜冻

Freeze：禁止在计划发布窗口中分页,只剩下P1。
标记为："env=stage"，"region=dr"，"service=batch"。
时间静音：在数据库迁移/负载测试时-具有明确的所有者。

15）效率度量（SRE/DORA for alerts）

MTTA/MTTR（命令/服务/轮班部分）。
具有运行簿的Alert的百分比（目标≥ 95％）。
SLO的页值份额（目标≥ 90％）。
Ratio有用/嘈杂（目标≥ 3：1）。
%自动辅助功能（pause/rollback via webhook）-生长。
Burn-down postmortem action items 14/30天。

16）反模式

通过"铁"（CPU，磁盘）分页而不会影响用户。
没有"grupp_by" → "storm" alerts。
没有安静的窗口-版本将所有内容涂成红色。
没有"服务/env/runbook"的payloads-无法路由/操作。
没有单一的severity量表和规则（每个来源都是以自己的方式）。
没有人提出的"永恒"警告（警报职责）。

17）实施清单（0-45天）

0-10天

调和severity量表并标准化标签/注释。
在PagerDuty/Opsgenie中创建服务,自定义schedules和基本升级。
绑定Alertmanager/Grafana，包括"group_by"和dedup。

11-25天

键入SLO-alerta（多窗口燃烧）,添加链接运行手册。
自定义ChatOps： autocanals、ack/assign命令。
在发布/迁移中启用安静的窗口。

26-45天

集成加那利群岛的自动pause/rollback（webhooks）。
引入MTTA/MTTR报告和allert卫生（噪音清洁）。
标准化验后和控制行动项目。

18）现成的嗅探

Grafana Alerting → PagerDuty（JSON身体模具）

json
{
"routing_key": "${PAGERDUTY_ROUTING_KEY}",
"event_action": "trigger",
"payload": {
"summary": "{{.RuleName }}: {{ index. Labels \"service\" }}",
"severity": "{{ if eq (index. Labels \"severity\") \"critical\" }}critical{{ else }}error{{ end }}",
"source": "grafana",
"component": "{{ index. Labels \"env\" }}",
"group": "{{ index. Labels \"region\" }}"
},
"links": [
{ "href": "{{.DashboardURL }}", "text": "Dashboard" },
{ "href": "{{ index. Labels \"runbook\" }}", "text": "Runbook" }
]
}

🚨 Check Alert的Webhook → Argo Rollouts pause

bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'

Opsgenie-路由规则（伪）

yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]

19）结论

Alert的强环路是+学科的过程：SLO为中心的分层，可读的路由和升级，单个标签和payloads，安静的窗口，ChatOps和自动动作（pause/rollback）。在预算和UX上选择PagerDuty或Opsgenie，但要遵守相同的噪音、职责和责任规则--那么佩奇将是罕见、准确和有用的，事件是短暂和可管理的。

Alerts和通知：PagerDuty, Opsgenie

Opsgenie (webhook)

注释中的链接示例runbook

11-25天

26-45天

Opsgenie-路由规则（伪）

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目