告警进来，AI先查日志和发布记录再定级

原文要点

该免费模板接收Prometheus Alertmanager的POST告警（路径/alertmanager-incident），用告警指纹派生会话ID让后续告警并入同一调查；GPT-4.1代理带会话记忆，可多次调用日志接口和CI/CD发布接口，返回结构化根因分析JSON（根因、置信度、证据、可疑发布、严重级别、建议动作），写入Postgres的incident_analyses表，再建ClickUp任务、发Slack摘要，critical时触发PagerDuty呼叫值班。

这次做成什么

在本站练习环境中搭一条“告警→AI排查→定级→通知”的链路：用合成告警和自建的模拟日志/发布接口跑通代理调查流程，产出一份带证据的结构化根因分析，并按级别分支到留档、建单和呼叫。

准备什么

• 一个n8n实例（自托管或云端均可），能开放外部POST webhook
• OpenAI凭据，聊天模型按原模板设为gpt-4.1（费用由OpenAI收取）
• 可写库：Postgres及建表权限；练习时可用本地测试库
• ClickUp、Slack凭据；PagerDuty仅critical分支需要，练习可跳过
• 两个供代理查询的HTTP接口：日志查询和发布记录查询；练习时用自建的Mock接口替代Loki/ELK/CI系统

具体怎么做

1. 建表并接告警入口

   在Postgres执行材料中的DDL建public.incident_analyses表。在n8n加一个Webhook节点，方法POST，路径填alertmanager-incident，先点Listen for test event，用下方材料里的合成Alertmanager负载curl发一次，确认能收到alerts数组。

2. 归一化字段并生成会话ID

   在Webhook后加Code节点，从alerts[0]提取alertname、severity、service、description、startsAt，并把fingerprint字段原样作为sessionId输出，保证同一告警的后续通知进入同一调查上下文。字段映射：labels.alertname→alertName、labels.severity→severity、labels.service→affectedService、annotations.description→description、startsAt→startTime、fingerprint→sessionId。

3. 配置带记忆和工具的AI代理

   添加AI Agent节点，聊天模型接OpenAI凭据并选gpt-4.1；Memory接Simple Memory并以sessionId为会话键；挂两个HTTP Request工具：一个查日志、一个查最近发布。练习时这两个工具指向你自己起的Mock服务（如n8n里另开的两个webhook返回固定JSON），生产再换成Loki/ELK/CloudWatch和CI/CD接口并加鉴权。系统提示词用下方材料。

4. 解析结果并落库

   代理输出要求为纯JSON，在其后加Code节点JSON.parse并校验必需字段（rootCause、confidence、evidence、likelyDeployment、severity、recommendedActions），解析失败走人工分支。然后接Postgres节点，把各字段插入incident_analyses对应列留档。

5. 按级别分支通知

   接Switch节点按severity分流：所有级别都建ClickUp任务（选目标List）并向Slack频道发含任务链接的摘要；仅critical再走PagerDuty节点建事件呼叫值班。最后用Respond to Webhook节点把调查结论JSON返回给调用方。练习时PagerDuty分支可只接一个NoOp并人工核对条件。

可直接复制的材料

你是值班事故调查员。你会收到一条Prometheus告警，包含告警名、级别、受影响服务、描述和开始时间。你可以调用两个工具：query_logs（按服务名和时间范围查日志）、query_deployments（按服务名查最近发布记录）。排查要求：1）先查告警开始时间前后30分钟的日志，找错误模式和首个异常时间点；2）再查告警前24小时内该服务的发布记录，判断是否有时间吻合的变更；3）如证据不足可再次缩小时间窗调用工具。最后只输出一个JSON对象，不要输出其他文字，字段：rootCause（根因描述）、confidence（0到1的置信度数值）、evidence（证据数组，每条注明来自日志还是发布记录）、likelyDeployment（最可疑发布的id或null）、severity（critical或warning或info）、recommendedActions（建议动作数组）

{"receiver":"ai-incident","status":"firing","alerts":[{"status":"firing","labels":{"alertname":"HighErrorRate","severity":"critical","service":"checkout-api"},"annotations":{"description":"5xx错误率超过5%持续3分钟"},"startsAt":"2026-09-08T10:15:00Z","fingerprint":"fp-test-0001"}],"groupKey":"test-group"}

CREATE TABLE public.incident_analyses (
  id BIGSERIAL PRIMARY KEY,
  alert_fingerprint TEXT NOT NULL,
  alert_name TEXT,
  affected_service TEXT,
  root_cause TEXT,
  confidence NUMERIC,
  evidence JSONB,
  likely_deployment TEXT,
  severity TEXT,
  recommended_actions JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

输入与输出示例

本站虚构演示，未实际运行；字段为本站约定命名，接入原模板时以模板实际输出字段为准

输入

发送上方合成负载：HighErrorRate、critical、checkout-api、startsAt为2026-09-08T10:15:00Z、fingerprint为fp-test-0001；Mock日志接口返回10:16起出现大量payment gateway timeout错误，Mock发布接口返回10:10有一次deploy-id为dep-4821的支付SDK升级。

对应输出

代理返回{"rootCause":"支付SDK升级后调用超时导致5xx激增","confidence":0.82,"evidence":["日志：10:16起payment gateway timeout每分钟约120条","发布：dep-4821于10:10上线，时间上先于错误出现"],"likelyDeployment":"dep-4821","severity":"critical","recommendedActions":["回滚dep-4821","临时调高超时阈值并观察"]}，随即severity=critical分支会同时建ClickUp任务、发Slack摘要并触发PagerDuty。

做完检查这些

• 用同一fingerprint连续发两次告警，第二次调查能引用第一次的会话上下文，而不是从零开始
• 代理最终输出能被JSON.parse直接解析，且六个必需字段齐全、confidence为0到1之间数值
• Postgres中每次分析新增一行，alert_fingerprint与告警指纹一致，created_at自动写入
• 把severity改成warning重发，Slack和ClickUp仍执行但PagerDuty分支不触发
• 故意让Mock日志接口返回500，流程走到失败/人工分支而不是把空证据写成根因

容易卡住的地方

• 会话记忆依赖fingerprint稳定：Alertmanager的group_by或路由改动可能让同类告警产生不同指纹，导致调查被拆散
• 代理可多轮调用工具，日志接口慢会直接拉长整个webhook响应，建议Alertmanager侧不要求同步等待结论
• confidence是模型自评，不代表真实准确率；低置信度时应在提示词里要求降级severity并转人工
• 日志和发布接口若无鉴权暴露在内网之外，等于把系统日志开放给任何调用方
• 原文说代理会‘多次’查询接口，但未给轮次上限，练习时应自行限制避免token费用失控