n8n模板：Alertmanager告警自动去重、AI定位根因并分级通知

原文要点

这是n8n.io上Oneclick AI Squad发布的免费工作流模板（编号19463）：接收Prometheus Alertmanager的firing/resolved告警webhook，规范指纹、严重级别、来源、受影响服务等字段；resolved立即在Postgres关单并通知Slack。firing先查Postgres去重，冷却窗口内重复告警只累加发生次数、压制告警风暴；再把告警分类为客户端侧或后端侧，由OpenAI工具调用代理做根因分析，可查客户端遥测API、Prometheus指标、近期发布记录和历史事故向量库；输出非法JSON进死信路径；然后按升级策略分流到Slack、邮件、PagerDuty，并在ClickUp建单或评论，最后写健康日志表并返回JSON响应。需配置六类凭据并建三张Postgres表。

这次做成什么

搭一个等效练习流程：webhook收告警→Postgres去重与冷却→分类→AI根因分析→按级别分流通知→建单登记。练习用合成告警payload和本地测试表，不接真实PagerDuty服务。

准备什么

• 可运行的n8n实例，且能暴露公网或内网可达的webhook地址
• 一个Postgres数据库及建表权限，供 incidents、dead_letter_events、workflow_health_log 三表使用
• OpenAI API密钥，用于根因分析代理
• Slack工作区及Bot凭据，有一个测试频道；ClickUp账号及目标List ID
• 练习阶段可暂缓PagerDuty与SMTP，用Slack分支代替验证分流逻辑

具体怎么做

1. 建表并配置webhook入口

   在Postgres执行建表：incidents(fingerprint text primary key, service text, severity text, status text, occurrence_count int, first_seen timestamptz, last_seen timestamptz)；dead_letter_events(id serial, payload jsonb, created_at timestamptz)；workflow_health_log(id serial, run_status text, detail text, created_at timestamptz)。n8n里新建工作流，放Webhook节点，方法POST，路径如/alertmanager；在测试用的Alertmanager配置里把webhook_configs的url指向该地址（无Alertmanager时用下方合成payload手动POST测试）。

2. 规范化、resolved闭环与去重冷却

   接Code节点把payload规范化成{fingerprint, severity, service, status}。接IF按status分流：resolved分支执行Postgres Update把status置为resolved并直接发Slack通知。firing分支先Postgres查询同fingerprint且status=open的记录：存在且last_seen在冷却窗口（如15分钟）内则只执行occurrence_count+1并终止；否则继续走分析。

3. 分类与AI根因分析

   加Code或分类节点按service前缀等规则标记client_side/backend_side。接AI Agent节点，系统提示词要求代理输出严格JSON{summary, probable_cause, confidence, recommended_action}；代理的工具按原模板思路接HTTP查询Prometheus指标与近期发布（练习阶段可用Mock节点返回固定指标数据）。Agent后接JSON校验：解析失败或缺字段就走死信分支，Insert到dead_letter_events并发Slack告警。

4. 分级通知与建单

   接Switch节点按severity分流：info/warning只发Slack；high/critical额外走邮件节点和PagerDuty节点（练习时先用NoOp占位，凭据就绪后替换）。再接ClickUp节点：无已开工单则Create Task（名称含service与summary），有则Add Comment。最后Postgres Insert写workflow_health_log，Respond to Webhook返回{"ok":true}。把工作流自身的Error Workflow设为它自己，使执行失败也落死信。

可直接复制的材料

你是值班运维的根因分析助手。输入是一条已规范化的告警（fingerprint、severity、service、告警文案）以及你可调用工具拿到的遥测与指标数据。

规则：
1. 需要证据时调用工具查询指标或近期发布记录，不要凭空猜测。
2. 最终只输出一个JSON对象，字段必须是：
{"summary": "一句话中文概述", "probable_cause": "最可能根因及依据", "confidence": "high|medium|low", "recommended_action": "值班同学下一步具体操作"}
3. 如果工具返回的数据不足以判断，confidence填low并在probable_cause里说明缺什么证据，禁止编造指标数值。

{"version":"4","status":"firing","alerts":[{"status":"firing","labels":{"alertname":"HighErrorRate","severity":"critical","service":"checkout-api","instance":"10.0.3.17:9090"},"annotations":{"summary":"checkout-api 5xx rate above 5% for 10m"},"startsAt":"2026-09-11T03:12:00Z","fingerprint":"fp-checkout-5xx-001"}]}

输入与输出示例

本站虚构演示，代理输出为示意文本，非真实运行结果。

输入

向/alertmanager连续POST两次上面的合成payload（fingerprint均为fp-checkout-5xx-001，severity=critical，间隔3分钟，冷却窗设15分钟）

对应输出

第一次：incidents插入一行fp-checkout-5xx-001/status=open/occurrence_count=1；RCA代理返回{"summary":"checkout-api错误率持续超阈值","probable_cause":"最近一次发布后数据库连接池耗尽，错误率曲线与发布时间点吻合","confidence":"medium","recommended_action":"回滚v2.31或扩容连接池并观察5分钟"}；因severity=critical走Slack+邮件+PagerDuty分支，ClickUp新建任务。第二次（冷却窗内）：只执行occurrence_count更新为2，不重复通知、不重复建单；workflow_health_log两行run_status均为ok。

做完检查这些

• 同一fingerprint在冷却窗口内重复POST，incidents行数不变且occurrence_count递增，Slack只收到一次告警
• 把payload中status改为resolved重发，incidents对应行status变为resolved且Slack收到恢复通知
• 故意让代理返回非JSON（可在提示词后注入测试），该次执行落入dead_letter_events表并触发Slack死信告警
• critical级别触发Slack、邮件、PagerDuty三个分支，warning级别只触发Slack

容易卡住的地方

• Alertmanager默认会按repeat_interval重复发送告警，没有Postgres去重层就会造成通知轰炸，该层必须最先生效
• 模板要求配置六类凭据（OpenAI、Slack、Postgres、ClickUp、PagerDuty、邮件），任一缺失对应分支会报错；练习时用NoOp占位可逐步替换
• 三张飞Postgres表的列名必须与工作流里insert/update语句映射一致，改名表字段会直接SQL报错
• RCA代理的工具端点（遥测API、Prometheus查询、向量库）在原模板里是占位配置，导入后必须替换成你自己环境的地址，否则代理拿不到证据只能低置信输出
• webhook若暴露公网，务必加鉴权（Header Auth或IP白名单），否则任何人都能伪造告警触发PagerDuty
• OpenAI调用与PagerDuty等SaaS可能产生费用，具体金额取决于用量无法预估