LLMOps告警：向量库宕机、Embedding接口失败

当收到编号204的LLMOps告警时，通常不是单个服务故障，而是向量数据库、Embedding模型接口和Agent执行链路被同时触发。
本文按故障传播顺序给出一套可执行的排查流程，帮你从日志定位源头，逐步恢复服务，并避免只重启不治本的问题。

先看清故障链路：三种告警的因果关系

向量库负责存储和检索知识切片，Embedding接口负责把文本转成向量，Agent在工作时先调用Embedding处理用户问题，再去向量库召回内容，最后交给模型生成回复或调用工具。

如果向量库宕机，Embedding接口的结果虽然能生成，但写入或查询会失败，Agent随后会报出大量超时和工具调用错误。
反过来，Embedding接口失败也会让Agent拿不到向量，导致后续链路全部报错。

所以出现三种告警并存时，优先查最底层的依赖服务，顺序建议是：向量库 → Embedding接口 → Agent进程。

向量库宕机：先看状态、再查日志、最后重启

以常见的 Milvus 或 Qdrant 为例，先用系统命令确认进程是否还活着。

systemctl status milvus
# 或者查 Docker 容器状态
sudo docker ps -a | grep qdrant

如果进程已退出，查看日志文件，确认是磁盘满、内存不足还是数据损坏。
日志位置一般在 /var/log/milvus/ 或用 docker logs 查看。

sudo journalctl -u milvus -n 200 --no-pager
sudo docker logs --tail 200 qdrant

常见原因是磁盘写满，执行 df -h 确认。
清理日志或扩容后，再启动服务：

sudo systemctl start milvus
sudo docker start qdrant

启动后不要急着告警恢复，先验证向量库端口是否监听。

ss -lntp | grep 19530   # Milvus 默认端口
curl -s http://127.0.0.1:6333/healthz  # Qdrant 健康检查

如果端口正常但仍报错，可能是连接池和客户端缓存出现问题，需要重启调用方服务。

Embedding接口失败：从超时、鉴权和模型服务三处下手

Embedding 接口失败先看两方面：一是模型服务本身是否可用，二是调用方的 API 地址和密钥是否还生效。

如果你用的是本地部署的 Embedding 服务，比如 OpenAI 兼容接口，可以直接用 curl 测通：

curl -s -X POST http://127.0.0.1:8000/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"model": "text-embedding-model", "input": "测试"}'

如果返回 401 或 403，检查 API Key 是否轮换或过期。
如果返回超时，重点看模型服务所在主机的 CPU、内存和 GPU 占用，输入输出队列过长时也会大量失败。

另外，很多 LLMOps 平台会配置 Embedding 超时时间，默认 5 秒，如果模型响应经常超过这个值，接口就会报错。
可以适当调到 10 秒或 15 秒，但也要同步排查模型推理变慢的原因。

Agent大量报错的排错方向

确认向量库和 Embedding 接口恢复正常后，再处理 Agent 本身。
Agent 报错通常分为两类：一类是依赖服务未恢复时的连锁错误，另一类是 Agent 配置或上下文过长导致的问题。

先看 Agent 服务日志中的错误码：

sudo journalctl -u agent-service -n 300 --no-pager
grep -i "error\|timeout\|fail" /var/log/agent/agent.log | tail -50

如果日志中大量出现 connection refused 或 context deadline exceeded，说明前面的服务还有问题，继续回头排查。
如果错误是 token limit exceeded，则需要减少单次传给模型的内容，或者调大模型上下文窗口限制。

在 Agent 代码或配置中，建议把向量库连接和 Embedding 调用都加上重试机制，并设置熔断，避免源头故障时日志直接被刷爆。

避坑要点和最终验证清单

处理这组告警时最容易踩的坑有三个：

• 不按依赖顺序排查，直接重启 Agent，结果上游不稳定导致告警反复出现。
• 忽略磁盘和网络瓶颈，向量库进程明明活着，但因为 IO 延迟高导致读写超时，表面上像宕机。
• 重启后不做回归验证，只看到告警消失就结束，实际上业务侧写入仍然失败。

建议按下面的清单逐项确认：

1. df -h 检查所有相关节点磁盘剩余空间。
2. 向量库健康检查接口返回正常，查询和写入各测一次。
3. 用 curl 验证 Embedding 接口能返回向量数据。
4. Agent 日志中不再出现新的超时或连接报错。
5. 观察 5-10 分钟，确认告警没有再次触发。

如果你正在处理 204.LLMOps告警：向量库宕机、Embedding接口失败、Agent大量报错，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
恢复后可以把告警规则里增加依赖检查项，下次就能更快定位源头。