EKS告警拦截器实战：用大模型把Alertmanager通知翻译成人话

凌晨两点十五分，手机在床头柜上震了第三遍。我眯着眼划开屏幕，一条来自 Alertmanager 的告警赫然写着：

KubePodCrashLooping - payment-svc-687d8f9c7b-xxx - crash loop back-off

这种告警，K8s 管理员和 SRE 应该都不陌生。可问题是，这条消息除了告诉我"有个 Pod 在崩溃重启"，什么都没说。为什么崩溃？影响的是哪个上游调用方？处理到哪一步了？日志里有什么异常？我盯着这条告警，还得再花十分钟去 EKS 控制台、EFK 里翻日志、看监控，才能判断"今晚能不能继续睡"。

我一直在想一个问题：AIOps 的口号喊了这么多年，能不能先把"告警翻译成人话"这种最朴素、最痛苦的需求解决掉？于是就有了这个项目——在 EKS 集群里搭一个智能拦截器，把 EFK 体系产生的各种原始告警截住，用业务语义重新解释，顺带去重、聚合、分级，最后让每条告警像是值班老手帮你分析过一遍再推给你。这篇文章就是整个项目的完整复盘，从架构选型到代码实现，从部署方式到踩坑记录，适合正在做云原生告警治理、受够了告警轰炸的运维和 SRE 同学参考。

1. 项目全貌：EKS 上 EFK 的告警为什么需要"拦截"与"翻译"

1.1 一个足够真实的夜间告警现场

先复盘一下没有拦截器的时候，一条告警从产生到处理要经历什么。我们的监控体系是经典的 Prometheus + Alertmanager，日志链路用的是 EFK 三件套：Elasticsearch 存索引、Fluentd 采集转发、Kibana 做查询和可视化。告警规则一堆，覆盖了 CPU 高水位、内存压力、Pod 重启、PVC 容量、5xx 响应等常规场景。

问题在于，告警通知本身是机器生成的，格式固定、字段稀疏、上下文缺失。像最前面那条KubePodCrashLooping，它在 Alertmanager 里的完整内容大概是这样：

{ "status": "firing", "alerts": [ { "labels": { "alertname": "KubePodCrashLooping", "namespace": "prod-payment", "pod": "payment-svc-687d8f9c7b-xxx", "severity": "critical" }, "annotations": { "description": "Pod prod-payment/payment-svc-687d8f9c7b-xxx has restarted 5 times in the last 15 minutes." }, "startsAt": "2025-01-15T02:03:20.000Z" } ] }

这条 JSON 里没有任何信息能告诉你：这个服务是干嘛的、它依赖哪些下游、5 次重启意味着什么、EFK 里对应的日志有没有 OOM 或致命异常。你只能人肉去查。更何况夜里收到的往往不止一条，而是同一个工作负载的兄弟 Pod 们一起崩溃，群消息瞬间变成覆盖式轰炸。这也是为什么很多团队的 SRE 明明做了告警闭环，还是在群里被拉着通宵——工具链是通的，信息链是断的。

1.2 智能拦截器到底是干什么的

我做的这个"智能拦截器"，名字听着玄乎，本质上是放在 Alertmanager 和通知渠道之间的一层中间服务。它不改动你现有的监控体系和日志链路，只是把发出通知这个环节接管过来，完成四件事：

第一，标准化。把不同告警源（Prometheus、云监控、自定义探针）的数据统一成一张有业务含义的表单，提取命名空间、工作负载、Pod、严重级别、触发时间、对应的日志关键词。第二，上下文补全。收到告警后主动去 EKS API 查工作负载状态，去 EFK 拉最近一段时间的日志摘要，拿到"根因候选"用的素材。第三，智能翻译。把标注化的告警和日志摘要丢给大模型，让它按照预设的提示词模板，输出一条有人话解释、有影响面判断、有根因推测、有建议动作的通知。第四，降噪收敛。在调用大模型之前做去重、聚合、抑制，把 50 条重复告警折叠成 1 条群通知，避免告警风暴连带烧掉 Token 预算。

把它放在"拦截"这个位置还有一层用意：它天然是一个转发代理，可以根据严重级别、服务分组、值班时间把告警分流到钉钉、飞书、Slack 或者工单系统。保留普通告警进群，抠出 critical 级别单独电话或强提醒，这一层逻辑以前写在 Alertmanager 路由规则里，现在可以做得更灵活。

1.3 为什么把第一站放在 EKS

选 EKS 作为 AIOps 落地场景，因为托管 Kubernetes 集群各有各的抽象层和割裂感。EC2 时代你排查问题还有相对固定的链路，上了 EKS 之后，网络、存储、调度、托管组件层层叠加，问题面更分散，但另一方面，EKS 自带的控制面 API、节点组标签、云厂商的 LB、存储卷、日志采集器之间的关系都相对结构化，特别适合做"告警 → 上下文检索 → 知识注入"这套 AIOps 闭环。

对我们来说最直接的原因是痛感最强。我们大概有四十多个命名空间，三百多个工作负载，每天的日志量在 200GB 量级。一旦某个公共组件出问题，告警会跨命名空间串联，一夜之间能攒下几百条。人肉一条条看根本不现实，但跳过告警直接全链路日志分析又太重。在 EKS 上做一层轻量智能拦截器，恰好卡在成本、效果、落地难度三者交界的位置。

2. 智能拦截器架构设计与技术选型

2.1 告警处理的完整链路

整个系统的数据流是单方向的，我梳理成六个环节：

1. Prometheus 的告警规则触发，交给 Alertmanager 做最基础的静默、分组、抑制；
2. Alertmanager 把通知发送到拦截器的 Webhook 端点；
3. 拦截器解析告警，计算去重 key，查询 Redis 做聚合状态比对；
4. 拦截器异步去 EKS API 和 EFK 拉取上下文信息（标签、Pod 状态、最近日志摘要）；
5. 调用大模型生成自然语言通知；
6. 根据预设路由规则，把生成好的通知发送到钉钉群、飞书机器人或工单系统。

链路看起来不复杂，但每个环节都有取舍。比如第 2 步为什么用 Webhook 而不是让拦截器定期去 Alertmanager API 拉？因为 Webhook 是事件驱动的，告警产生即推送，延迟最低，不会因为轮询间隔错过瞬时告警。缺点是 Alertmanager 会重试，所以拦截器必须设计成幂等，同一告警重复收到也不能重复生成通知。

2.2 核心模块划分

代码结构按职责拆成了五个模块，这也是后来维护时觉得比较顺手的划分方式：

• Ingress 模块：负责接收 Alertmanager 和其他来源的告警，统一做 schema 校验、字段映射、签名验证。
• Core 模块：告警的聚合去重引擎，里面有滑动窗口计数器、告警指纹计算、抑制规则匹配。
• Context 模块：调用 EKS API 和 EFK 的客户端，带缓存和超时控制，负责把告警从"一条 JSON"丰富成"一份包含上下文的事故快照"。
• LLM 模块：封装大模型 API 调用，包括提示词模板渲染、请求重试、响应校验、Token 计数。
• Dispatch 模块：通知渠道适配层。钉钉、飞书、Slack、邮件、Webhook 各有一个适配器，统一接口。

模块之间通过事件队列解耦。收到告警后，Ingress 先把原始数据写入队列，Core 做实时处理，Context 和 LLM 都属于耗时操作，放在消费者里异步执行。这样做有一个明显好处：告警到达的瞬间，拦截器可以先立刻回给 Alertmanager 一个 200，告诉它"这条我收了"，避免它重发；真正耗时的上下文补全和翻译在后台慢慢做，不阻塞通知通路。

2.3 技术栈选型：为什么是 Python + FastAPI

整个服务用 Python 3.11 + FastAPI 写的。原因有三。第一，生态最省心：告警解析、Webhook 签名、钉钉飞书 SDK、大模型 SDK，Python 全都有现成组件，不需要像 Go 那样自己去写不常用的适配器。第二，异步支持好：FastAPI 基于 asyncio，Webhook 接收和 LLM 调用都是天然的 IO 密集型操作，协程能把并发撑得很高，而不用引入一堆线程池管理代码。第三，团队维护成本低——我们是运维团队，Python 是大家最熟练的语言，这决定了后续有人能接手。

有人会问，高并发场景用 Go 不是更香吗？但拦截器的瓶颈从来不在 Web 框架本身，而在下游依赖：EKS API 有 QPS 限制，EFK 查询有时间开销，大模型 API 有并发上限。这些 IO 等待让 Python 异步的优势完全够用，实测中单实例 4 核 8G 能扛住每分钟 600 条告警的峰值，对绝大多数团队来说已经足够了。

2.4 大模型接入的二选一方案

大模型部分我们认真对比过两条路线：一是直接调用托管的大模型 API（OpenAI 兼容接口或国内大模型平台的 API），二是私有化部署开源模型，比如在 EKS 里跑一个量化后的 Llama 或 Qwen。

直接调 API 的优势是省事、效果好，尤其是中文表达和推理能力，商业模型比开源小模型强太多。劣势是网络出公网有延迟、有费用、有数据合规的问题，需要做敏感信息脱敏。私有化部署则反过来，数据不出内网，合规压力小，但部署和调优一套推理服务，对运维团队是额外负担，而且 7B 以下量级的模型，想把"告警翻译成人话"做稳定，效果确实要差一些。

我们最后选了混合方案：常规告警走关键词模板和人话模板，只有需要根因推测和影响面分析的高危告警才调用大模型 API。另外在 LLM 调用前做了一层脱敏，把 Pod 名、IP、命名空间里的业务敏感关键词替换成代号，防止日志摘要里的用户信息外泄。这个决定同时控住了成本和合规风险，后面会展开讲。

3. 关键细节与核心逻辑拆解

3.1 告警数据统一模型

拦截器能不能"说人话"，首先取决于内部数据模型是否足够表达"事故快照"。我设计的核心结构是一个 flat 化的告警事件模型，字段分三层：

• 基础层：alertname、namespace、workload、pod、severity、status、startsAt、endsAt、duration。
• 指标层：触发指标名、阈值、当前值、持续时间。这个非常重要，不带上数值的告警等于没告警。
• 上下文层：k8s 工作负载类型、副本数、副本就绪数、镜像版本、节点名；以及从 EFK 拉到的最近 30 条日志摘要。

每个进来的原始告警都先映射到这个模型。字段缺失的规则直接标记为"低质量告警"，在聚合时降权，避免后续大模型被缺字段告警影响判断。

举个具体的字段映射例子。Alertmanager 的告警 label 里通常只有pod，但你很难只靠 pod 名去 EKS 查工作负载。我们在 Ingress 层写了一个解析函数：从 pod 名反推 deployment 名（去掉最后一段随机字符串），再调 EKS API 确认这个 pod 属于哪个 deployment/statefulset，最后把 workload 类型和副本状态写进上下文层。这一手让后面所有逻辑都方便了，给告警分类、做路由、查日志，都是基于 workload 级别的信息，而不是 pod 级别碎片化的信息。

3.2 提示词工程："说人话"的命根子

整个项目里投入产出比最高、也最需要反复调试的，就是提示词模板。第一版我写得很简单，效果惨不忍睹——大模型确实把告警"翻译"得通顺了，但说了一大堆车轱辘话，没有给出任何可操作的建议。

后来我把提示词模板结构化，分成了四个区块，这里直接放出我们验证过效果较好的版本：

你是一名有 10 年经验的 SRE 值班工程师，负责 EKS 生产集群的稳定性。 现在有一条告警需要你转化为面向值班人员的中文通知，要求如下： 1. 用不超过 80 个字的一句话说明"发生了什么"以及"用户可能感知到什么"。 2. 列出最可能的前 3 个根因，每个根因不超过 20 个字，必须结合给定的日志摘要和监控指标，不得编造日志中没有的信息；如果无法判断，写"暂无法定位，需人工查看日志"。 3. 给出下一步处理动作建议，必须是可执行的 SRE 操作，例如"查看此 Pod 的完整日志: kubectl logs ... --tail=200"、“扩容或摘流量: kubectl scale deployment ... --replicas=3”或"回滚上一个镜像版本"中的一个。 4. 如果日志摘要中出现 OOMKilled、Cannot allocate memory、connection refused、EOF 等明确关键词，请在根因中优先解释。 告警数据如下： --- 告警名称: {{alertname}} 命名空间: {{namespace}} 工作负载: {{workload}} 告警级别: {{severity}} 监控指标: {{metric_name}} 当前值 {{current_value}} 阈值 {{threshold}} 关键日志摘要: {{log_snippet_output}} --- 最终输出格式必须是纯文本，不要输出 Markdown 标题，不要输出任何解释性前缀。

这个模板有两个关键设计。第一，给模型限定了一个"SRE 值班工程师"的视角，它输出的措辞就会从"该 Pod 发生故障"变成更贴近实操的话。第二，明确禁止它编造日志里没有的信息。大模型天然有补全倾向，你不勒住它，它就敢给你编一个"疑似内存泄漏导致的 OOM"，哪怕日志摘要里根本没有 OOMKey 字样。

我们还用 few-shot 示例做校准，在模板下方附了两组标准的输入输出对。这招很管用，尤其是对输出长度和格式的稳定性提升明显。后来我算过一笔账：每调用一次大模型大概消耗 800~1200 token，加上 few-shot 示例的固定 token，单条成本在 0.01~0.03 元左右，后面加上缓存和前置规则，整体成本完全可以接受。

3.3 去重、聚合、抑制：在调用大模型之前先省一半钱

大模型调用再便宜，也扛不住告警风暴。我们处理告警风暴靠三招：

• 去重：对每个告警计算指纹，key 由alertname + namespace + workload + 核心label + 触发时间窗口组成。同一个 key 在 30 分钟窗口内只保留第一次触发时生成的上下文，后续重复到达的告警直接递增计数器，不重复调用大模型。
• 聚合：同一工作负载在 10 分钟内产生的多种告警（比如 CrashLoop 和 5xx 同时报），合并成一条"该工作负载当前存在 N 类告警"的总通知，附上各类告警的数量和首个触发时间。
• 抑制：利用 Alertmanager 已有的抑制规则，拦截器里再做一道。规则很简单：如果同一个 workload 已经有 critical 级别告警在 firing，那么后续到达的 warning、info 级别告警就不再生成独立通知，只在聚合通知里追加一条"另有 N 条低级别告警"。

这套机制上线后最直观的变化是：之前一次故障大概触发 120~200 条群消息，现在压缩到 2~6 条，而且每条都是能看懂、能操作的内容。这在心理上是巨大的解脱。

3.4 上下文补全：把 EFK 日志摘要喂给大模型

大模型要"说人话"，光靠告警 label 是不够的，它需要日志里的蛛丝马迹。我们写了 Context Module，收到告警后向 EFK 发起一次查询。

查询逻辑是这样的：先根据告警里的 pod 名拼出索引前缀（比如filebeat-*），然后用 Elasticsearch 的bool query组合三个过滤条件——namespace精确匹配、pod关键字匹配、时间范围设为告警触发前 5 分钟到当前时刻。排序按@timestamp倒序，取前 30 条日志。取回后用正则把堆栈帧、时间戳、IP 地址这类冗长内容截断或剥离，最终生成一个不超过 1500 字的日志摘要文本。

这个摘要不是通用的"日志压缩"，而是带着目的性的提取。我们会额外把出现频次高的单词和错误码挑出来，插入到摘要末尾的"关键词"字段。因为大模型对高频词的敏感度比人工一行行看日志高得多，像OutOfMemoryError、connection reset、deadline exceeded这种词一旦高频出现，根因方向基本就锁定了。

EFK 查询也不是每次都现查。同一个 workload 在五分钟内的重复告警，会直接复用第一次查询结果，给 EFK 和 ES 减负。这里用 Redis 做缓存，key 是workload + 小时级时间戳，避免跨小时把过期上下文带进来。

4. 手把手落地：从代码到 EKS 部署

4.1 拦截器主服务代码骨架

核心服务代码并不复杂，我用 FastAPI 写了一个接收 Webhook 的入口。这里放出关键部分，完整代码逻辑可以在我们自己仓库里看，但主要思路下面就是全貌。

import hashlib import json import asyncio from fastapi import FastAPI, Request, HTTPException from pydantic import BaseModel app = FastAPI(title="alert-interceptor") class AlertmanagerPayload(BaseModel): status: str alerts: list[dict] class Interceptor: def __init__(self): self.redis = None # 实际用 redis.asyncio 初始化 def fingerprint(self, alert: dict) -> str: labels = alert.get("labels", {}) core = ( labels.get("alertname", ""), labels.get("namespace", ""), labels.get("workload", ""), labels.get("severity", "") ) return hashlib.sha256(json.dumps(core).encode()).hexdigest() async def should_generate(self, fp: str) -> bool: # 滑动窗口计数，防止同一指纹在窗口内重复生成 count = await self.redis.get(fp) return count is None interceptor = Interceptor() @app.post("/webhook/alertmanager") async def receive_alert(payload: AlertmanagerPayload): if payload.status != "firing": return {"ok": True, "skipped": "resolved"} for alert in payload.alerts: fp = interceptor.fingerprint(alert) if await interceptor.should_generate(fp): # 异步执行上下文查询 + LLM + 通知发送 asyncio.create_task(process_alert(alert)) return {"ok": True} async def process_alert(alert: dict): # 1. 查询 EKS 获取 workload 状态 # 2. 查询 EFK 获取日志摘要 # 3. 组装请求数据 # 4. 调用大模型接口，生成自然语言通知 # 5. 根据 severity 路由到对应渠道 pass

这个骨架有几个细节值得注意。第一，收到告警后立即返回{"ok": true}，不管后面的慢操作是否完成，这样 Alertmanager 不会因为超时就重试。第二，用asyncio.create_task把耗时操作丢到后台，Webhook 接口本身始终保持极快响应。但这里一定要配合信号量（asyncio.Semaphore）做并发限制，不然告警风暴时后台任务会瞬间堆积几千个协程，把 8G 内存打满。我们最终的并发上限是 50。

LLM 调用的部分，我们对 OpenAI 兼容接口做了一层封装，超时设置 30 秒，失败自动重试两次，重试使用指数退避。

async def call_llm(messages: list[dict]) -> str: async with semaphore: for attempt in range(3): try: resp = await client.chat.completions.create( model="gpt-4o-mini", # 根据成本和效果选择 messages=messages, temperature=0.2, # 低温度降低随机性 max_tokens=512, timeout=30 ) return resp.choices[0].message.content except Exception as e: await asyncio.sleep(2 ** attempt) # 最后一次失败则降级为模板通知 return render_template_notification(alert)

这里非常重要的是temperature=0.2。告警翻译这种任务是确定性优先，不是创意写作，把随机性压得越低越好。另外必须有一个降级路径：大模型 API 挂了，不能连告警通知都跟着挂，必须回退到静态模板。这个降级我们专门用混沌演练验证过，确保 LLM 模块宕机不影响告警基本通知能力。

4.2 Alertmanager Webhook 配置

拦截器上线后，需要让 Alertmanager 把它当成一个 receiver。Alertmanager 的配置是 YAML 格式，核心是加一个 webhook 类型的 receiver，然后路由到对应的告警规则。

route: receiver: "ai-interceptor" group_by: ["alertname", "namespace", "workload"] group_wait: 30s group_interval: 5m repeat_interval: 4h receivers: - name: "ai-interceptor" webhook_configs: - url: "https://interceptor.internal.svc.cluster.local/webhook/alertmanager" send_resolved: true

这里有一个容易被忽略的配置，group_wait: 30s。它的意思是 Alertmanager 收到一批同组告警后，会等 30 秒再发送，把该窗口内到达的同类告警打包成一个请求。这个参数对我们的成本控制帮助非常大——相当于在进入拦截器之前，Alertmanager 已经帮我们做了一层初级聚合。

send_resolved: true这个选项，是让告警恢复时也向拦截器发一条 resolved 消息。不要以为恢复消息是噪音，它其实非常重要。有了恢复消息，我们可以在群里发一条"故障已恢复，持续时长 45 分钟"，真正做到告警闭环。这一条不加，值班人员看到故障结束还得自己去确认。

4.3 EKS 上的部署清单

拦截器本身是一个无状态服务，部署在 EKS 里非常简单。我们用一个 Deployment + Service 承载，主要清单如下：

apiVersion: apps/v1 kind: Deployment metadata: name: alert-interceptor namespace: ops spec: replicas: 2 selector: matchLabels: app: alert-interceptor template: metadata: labels: app: alert-interceptor spec: containers: - name: interceptor image: registry.internal/ops/alert-interceptor:1.4.2 ports: - containerPort: 8000 name: http env: - name: REDIS_URL valueFrom: secretKeyRef: name: ops-redis key: url - name: LLM_API_KEY valueFrom: secretKeyRef: name: llm-secret key: api_key resources: requests: cpu: 500m memory: 512Mi limits: cpu: "2" memory: 2Gi readinessProbe: httpGet: path: /healthz port: http livenessProbe: httpGet: path: /healthz port: http --- apiVersion: v1 kind: Service metadata: name: alert-interceptor namespace: ops spec: selector: app: alert-interceptor ports: - port: 80 targetPort: 8000

有个细节很值得说一下：Service 我们用的是普通的 ClusterIP，而不是 LoadBalancer。因为 Alertmanager 是集群内服务，通过http://alert-interceptor.ops.svc.cluster.local访问即可，完全不需要暴露到公网，安全性和网络延迟都更优。

如果要接入 EKS 的云上监控，直接在 service 上加一个prometheus.io/scrape: "true"注解，就能把这个拦截器自身也纳入监控。这是我们自己特别看重的一点——做告警治理的工具，必须先把自己管理好。每个告警处理耗时、LLM 调用延迟、Token 消耗量、上游 EFK 查询失败率都打了指标，后续能看到这个拦截器本身是不是在稳定工作。

4.4 成本与性能参数实测

上线运行两个月后，我拉了几组数据，可以给打算复刻的同学一个参考基准。

• 单实例 4 核 8G 的配置，日常 CPU 使用率不到 10%，峰值约 55%；
• 日均处理原始告警约 3000~8000 条，经过去重聚合后，实际发送到群里的通知日均 30~120 条；
• 大模型 API 的日均消耗约 2 万~6 万 token，月度成本不到一百元，相比人工排查省下的时间完全划算；
• 单条告警从 Alertmanager 发出到群内收到通知，平均延迟 2~4 秒，主要开销在 EFK 查询和大模型生成上。

这个性能是在没有做过多预计算的情况下达到的。如果你现在才要开始做，建议直接按这个配置起步，不需要一次性把机器开到很大。AIOps 工具最重要的不是算力，而是数据质量和逻辑设计——先把告警拦好、合并好，大模型才有用武之地。

5. 实战中的坑与排查技巧

5.1 网络联调：告警没到达拦截器

上线第一天，我们遇到的最典型问题就是 Alertmanager 的 Webhook 请求没到拦截器。检查思路按链路一步一步来：先看 Alertmanager 日志里有没有Error sending webhook；再看拦截器接入日志有没有收到请求；然后确认两个服务之间的网络策略。

EKS 环境里最容易被忽略的是 NetworkPolicy。如果集群启用了网络策略，默认拒绝所有跨命名空间流量，那么ops命名空间里的拦截器根本收不到来自monitoring命名空间 Alertmanager 的请求。排查时先在拦截器 Pod 里手动 curl 一下自己的/healthz，再从一个测试 Pod 里 curl 拦截器的 ClusterIP，逐步缩小范围。最终我们放行了monitoring到ops的 80 端口流量，问题解决。

另外一个小问题是 webhook URL 的路径写错。有人会习惯性写成/webhook，但我们定义了/webhook/alertmanager，路径不匹配时 Alertmanager 会收到 404，然后按失败处理无限重试。这种低级错误几乎每个人都会犯一次，建议在拦截器里做一个请求日志中间件，把每次进来的 URL 和 header 全打出来，联调时一目了然。

5.2 告警风暴时 Token 被打爆

最惨烈的一次事故发生在某核心服务批量重启。Prometheus 一次性产生了 300 多条 firing 告警，Alertmanager 虽然做了分组，但拦截器这边还没扛住——那批告警几乎同一秒涌入，asyncio.create_task因为没限流，瞬间创建了上千个后台任务，每个任务都要查 EFK、调大模型。结果 EFK 先被打到查询超时，紧接着大模型 API 返回 429 限流，很多任务都走了降级模板，然后 Redis 连接池也爆了，整个服务 OOM 重启。

这次事故给我最大的教训是：所有外部依赖的并发量都必须显式控制，不能指望应用自己扛。后来我们做了三处修改：给后台任务加上asyncio.Semaphore(50)；给 EFK 查询增加一个进程内令牌桶，每秒最多 30 次查询；给大模型调用单独限 10 并发。同时，在告警入口处加了一个最简单的漏斗：如果一分钟内收到的告警数量超过 500 条，后面进来的告警直接合并进一条"当前存在大规模告警风暴，请查看 Prometheus 面板"的通知，不再逐条处理。

5.3 大模型开始编造根因

大模型提示词里明明写了"不得编造日志中没有的信息"，但我们还是遇到过它一本正经地编根因的情况。最典型的一次，一条 CPU 高负载告警，日志摘要里什么都没有，它却在根因里写"疑似存在死循环代码逻辑，建议排查应用层锁竞争"——这个结论完全没有任何数据支撑。

原因有两个：一是 few-shot 示例给得太具体，模型学会了模仿那种"给出准确根因"的结构，却没学会判断"信息不足时怎么办"；二是我们日志摘要给得太短，它没有足够材料时就会自行脑补。解决办法是对提示词做了一次大的修订：单独加了一个判断分支，明确写"如果日志摘要为空或没有明显异常关键词，根因列表只输出'暂无法定位，需人工查看日志'，禁止使用'可能''疑似'之外的推测性词汇"。另外把日志摘要的最低长度提到 500 字，宁可截取更长时间范围的日志，也不让它拿到过于稀疏的上下文。

这里我再提醒一点，大模型生成内容需要加一道"外挂校验"。我们会用正则先扫一遍生成结果，如果里面出现"OOM"但日志摘要里根本没有 OOM 字样，就强制降级为模板通知，不信任它的推理。宁可让人工查，也不能让它用编造的结论误导值班判断。

5.4 Elasticsearch 查询超时

EFK 查询超时也是一个高频坑。出问题的场景是：告警来了，拦截器去 ES 查日志，但查询的时间范围太宽（5 分钟），索引前缀太宽，ES 在大量分片上做扫描，耗时会超过我们设定的 3 秒超时。这直接导致上下文为空，大模型拿不到日志素材。

后来我们优化了查询方式。第一，把索引按天拆分（filebeat-2025.01.15），精确命中当天索引，避免跨索引扫描。第二，加了一个超时上限 2 秒，宁可在高峰期用较短的日志摘要，也不能阻塞告警处理链路。第三，把原本"取最近 30 条日志"改成了"先按错误级别过滤再取 30 条"，这样在日志量很大的情况下，拿到的 30 条更有信息密度。

还要注意 ES 的max_result_window默认是 10000，如果你用from + size方式分页会踩坑，但我们只取前 30 条，不会碰到这个限制。真正麻烦的是聚合查询，比如你要统计某个错误码在 5 分钟内的出现次数，需要合理的bucket_size，这块我建议直接做成一个可配置项，不同工作负载的日志密度差异极大，用一个默认值肯定不合适。

5.5 常见问题速查表

故障现象	可能原因	排查步骤	解决方案
Alertmanager 日志显示发送失败	网络策略阻断 / 路径错误	检查 Alertmanager 日志中的 HTTP 状态码，curl 测试目标地址	放通对应端口流量，修正 webhook 路径
群里没有通知但有告警	拦截器服务 OOM / LLM 接口降级	查看拦截器 Pod 的LAST STATE和日志	调整内存 limit，优化并发控制
大量重复告警	group_by 配置过细 / 去重窗口过短	查看 Alertmanager 的发送日志	调整group_wait和拦截器去重窗口
大模型生成内容与事实不符	日志摘要不足 / 提示词缺少约束	打印模型输入，检查摘要长度和关键词	增加摘要内容，增加"禁止编造"约束，加正则校验
延迟超过 10 秒	EFK 查询超时 / LLM 串行调用	看拦截器链路中的各阶段耗时	调整 EFK 查询超时，LLM 并发拉高，加缓存
大模型 API 费用暴涨	告警风暴 / 缺少缓存与聚合	查看 Token 消耗和告警数量趋势	显式限制并发，增加缓存命中率，前置规则过滤
恢复告警没有通知	send_resolved未开启	检查 Alertmanager 配置	加上send_resolved: true

这套东西做下来，我个人在实际操作中最深的体会是：AIOps 不是装个模型就完事，真正的功夫全在告警进到模型之前和出来之后的那些工程细节上。告警标准化、上下文补全、去重聚合、降级兜底，这些看起来没那么"AI"的环节，恰恰决定了最终体验是"存客观感"还是"花架子"。如果你也在做类似的事情，我的建议是先把中间件拆小、把链路指标打好，再谈模型效果。

最后再分享一个小技巧：给拦截器的每个出站通知都加一个原始告警的 source URL，比如 Prometheus 的 generatorURL 或者 Kibana 的 Discover 深度链接。这样即使大模型翻译得再好，值班同事也能一键跳回原始监控画面核实，大家才会真正信任这套系统。这个细节，比再好的提示词都能解决问题。