Skip to content

常见故障排查手册

OmniCortex 作为企业级统一 AI 网关,处于上层业务系统与底层异构模型算力之间的核心流量中枢。当生产环境发生模型调用失败、流式输出中断、配额限制阻断或安全防线拦截时,平台提供了标准化的三层定界黄金排障法与完整的诊断工具链。

本手册专为企业 SRE 运维工程师与业务集成开发者设计,采用无干扰的纯技术 Runbook 风格,提供从连通性自检、控制台可视化链路透视,到典型生产故障排查与反向代理调优的全套处置指南。


三层定界排障方法论与诊断工具箱

1. 三层定界核心原则

当调用发生非预期异常时,应遵循自外向内的三层定界法,快速区分责任边界并锁定根因:

  • 第 1 层 · 客户端接入层 (Client Ingress):排查客户端网络连通性、请求端点 URL、HTTP 协议头格式、Bearer 密钥拼写与请求体 JSON 合法性;
  • 第 2 层 · 网关调度与策略层 (Gateway Core):排查虚拟密钥激活状态、团队访问策略集(Access Profile)授权、瞬时 RPM/TPM 计数器、周期预算配额,以及安全围栏(Guardrails)拦截状态;
  • 第 3 层 · 上游模型算力层 (Upstream Providers):排查公有云或私有化引擎(vLLM / Ollama)的网络连通性、DNS 域名解析、TLS 握手证书、凭据池有效性与模型实际负载。

2. 全链路故障分流与排障拓扑

🩺
OmniCortex 三层定界快速排障决策流
基于状态码归因与链路凭证,实现分钟级故障定界与自愈
标准定界 · 链路闭环
1️⃣
接入校验异常 (400 / 401 / 404)
凭证格式错误、密钥不存在/停用、请求模型未在网关目录中注册
核验客户端 Token 与「虚拟密钥」/「模型资产」配置
通过接入校验 ➔ 核验治理与安全规则
2️⃣
治理拦截与流控异常 (403 / 429 / 安全400)
跨团队越权、策略集未放行模型、触发 RPM/TPM 阀门、Prompt 安全阻断
检查「访问策略集」白名单、流控阈值或调阅「安全拦截日志」
通过治理审查 ➔ 调度上游异构算力
3️⃣
算力通信与可用性异常 (502 / 503 / 504)
上游网络中断、首字超时断流、多通道容灾降级链路全部耗尽
通过 X-Request-ID 调阅「调用审计日志」Raw JSON 与路由链

3. 核心排障凭证与自检工具

在排查任何线上故障前,SRE 人员应准备好以下凭证与诊断工具:

  • 全链路追踪凭证 (X-Request-ID / event_id)
    • 客户端发起请求时可自定义请求头 X-Request-ID: <uuid>
    • 若客户端未携带,网关内核会自动生成唯一 UUID,并在 HTTP 响应头与标准错误报文中注入 event_id。所有组件日志、下游报错与可观测性看板均以该 ID 为全局检索索引。
  • 网关就绪探活端点 (GET /health)
    • 网关内置多维深度探活机制,用于 Kubernetes Liveness/Readiness 探针或负载均衡健康巡检。
    • 请求方式:
      bash
      curl -i -X GET http://OMNICORTEX_URL/health
    • 健康状态响应 (200 OK)
      json
      {
        "status": "ok",
        "components": {
          "db_pings": "ok"
        }
      }
    • 组件亚健康响应 (503 Service Unavailable)
      json
      {
        "error": "config store not available"
      }

      WARNING

      探活端点会并行探测配置持久化存储(ConfigStore)、日志检索库(LogsStore)与语义向量库(VectorStore)。若任何一个核心存储不可达,探针将返回 503,防止故障实例接收流量。


控制台可视化排障导览

OmniCortex 控制台提供了高维度的可视化故障追踪能力,使工程师摆脱传统翻查海量文本日志的繁琐流程。

场景一:通过调用审计日志透视失败请求 (Raw JSON 智能高亮)

  • 操作入口:管理控制台 ➔「全景可观测」➔「调用审计日志」(observability/llm-logs)。
  • 排查动线
    1. 在顶部筛选栏输入故障响应中的 X-Request-ID(或按状态码过滤 4xx / 5xx);
    2. 点击异常条目展开日志详情抽屉(LogDetailDrawer);
    3. 智能激活机制:当请求处于失败状态(status === 'error' 或包含 error_details)时,抽屉会自动切换并激活 rawjson 原始报文视图,无需手动点击查找;
    4. 代码编辑器中将完整呈现上游供应商的真实错误 Payload、HTTP 响应头与底层堆栈。
核心排查维度字段 / 视图运维定界价值
责任归因标识is_omnicortex_error秒级责任定界true 说明请求被网关内部策略短路(如虚拟密钥停用、模型白名单限制);false 说明错误直接由上游供应商透传(如账号欠费、供应商机房 500、并发超限)。
路由与降级链路LogRoutingView(概览 Tab)完整复盘网关尝试调用的首选通道与备选通道(Fallback),标明各通道失败原因及权重选择。
执行耗时拆解LogMoreDetails区分网络连接耗时、首字响应延迟(TTFT)与完整生成耗时,准确定位性能瓶颈。

场景二:排查安全围栏误杀与违规拦截 (Hit Forensics)

  • 操作入口:管理控制台 ➔「安全围栏与合规」➔「安全拦截日志」(observability/guardrail-hits)。
  • 排查动线
    1. 根据业务端报错信息中的 event_id,在拦截列表中快速检索对应记录;
    2. 点击流水展开「安全拦截取证抽屉(HitDetailDrawer)」;
    3. 确认核心处置维度:
      • 触发阶段:属于 REQUEST(输入侧违规)还是 RESPONSE(模型输出侧违规);
      • 命中引擎:标明是敏感数据脱敏(PII)、Prompt 注入防御、关键词黑名单还是正则表达式;
      • 高亮实体片段:系统以醒目的黄色高亮标签标记触发规则的具体文本内容;
      • 处置动作:查看是被强制阻断(BLOCK)还是仅替换为掩码(MASK)。

误拦截自愈与调优策略:

  • 正向业务误杀(如代码包含特定敏感关键词):在「防线工作台」中,针对该业务所属的团队策略包,将对应检测规则的动作临时调整为 LOG(仅审计不阻断);
  • PII 敏感数据过度匹配:进入「能力库」,微调对应正则的置信度阈值或增加排除前缀。

生产环境反向代理配置避坑指南 (Reverse Proxy Runbook)

在大模型网关的生产部署中,超过 70% 的流式卡顿、首字延迟异常与偶发断连问题均源于前置反向代理(如 Nginx、Kubernetes Ingress-Nginx、Envoy、Kong)使用了传统的 Web 代理配置。

以下是针对大模型高吞吐、长连接与流式 SSE 场景的标准 Nginx 优化配置:

nginx
# 大模型网关前置反向代理推荐配置模板
upstream omnicortex_backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=10s;
    # 启用长连接保持,降低与网关握手开销
    keepalive 128;
}

server {
    listen 80;
    server_name ai-gateway.internal.example.com;

    # 1. 允许大尺寸多模态 Payload 传输(高分辨率图像 Base64、超长文档上下文)
    client_max_body_size 50m;

    location / {
        proxy_pass http://omnicortex_backend;

        # 2. 核心:强制关闭响应缓冲,保障 SSE (Server-Sent Events) 逐字实时流式吐出
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header X-Accel-Buffering "no";

        # 3. 核心:深度思考模型推理(如 DeepSeek R1 / Claude 3.7 Thinking)长连接超时放宽
        # 避免 Nginx 默认 60s 未接收数据即切断长连接
        proxy_connect_timeout 15s;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;

        # 4. HTTP/1.1 长连接支持与 Header 透传
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # 5. 全链路追踪凭证透传
        proxy_set_header X-Request-ID $http_x_request_id;
    }
}

反向代理常见配置缺陷与表现:

配置项错误配置现象根因分析推荐标准设置
proxy_bufferingSSE 流式输出卡顿几十秒,随后一口气吐出整段回复代理层等待填满缓冲区后才向下游发送 TCP 报文,破坏了流式交互体验显式配置 proxy_buffering off;proxy_set_header X-Accel-Buffering "no";
proxy_read_timeout深度思考或长文本推理在运行 60 秒时连接意外中断代理层默认读超时为 60s,复杂推理或模型生成停顿导致连接被主动关闭将超时放宽至 300s600s
client_max_body_size业务端多模态图像/文档识别报 413 Request Entity Too Large反向代理默认限制客户端请求体尺寸为 1MB~2MB根据多模态业务规格调整为 50m 或更高
proxy_http_version网关侧连接数暴涨,频繁建立与销毁 TCP 连接默认使用 HTTP/1.0 且未清理 Connection 头,无法复用 Keep-Alive 管道配置 proxy_http_version 1.1; 并指定 proxy_set_header Connection "";

高频故障场景 Runbook 与处置矩阵

场景 1:网关启动失败或健康检查报 503

故障现象

网关容器启动后立即退出,或探活接口 GET /health 响应 503 Service Unavailable,返回 {"error":"config store not available"}{"error":"log store not available"}

核心根因

  1. 配置数据库(PostgreSQL / SQLite)网络不通、账号鉴权失败,或 PostgreSQL 达到最大连接数;
  2. 审计日志持久化后端(PostgreSQL / ClickHouse)不可用或写入超时;
  3. 集群节点配置的主加解密密钥(BIFROST_ENCRYPTION_KEY)发生变更,导致无法解密数据库中已存储的供应商密钥凭据。

排查步骤

  1. 查看网关容器启动日志:
    bash
    docker logs --tail 200 omnicortex-gateway
  2. 单独测试网关节点对数据库端口的连通性:
    bash
    nc -zv <db-host> 5432
  3. 检查环境变量中加解密密钥是否一致:
    • 确认各节点使用的 BIFROST_ENCRYPTION_KEY 保持全局统一且不可随意轮转。

解决方案

  • 修复数据库连接串与安全组防火墙放行规则;
  • 若仅为日志库暂时维护,可临时在客户端配置中放宽日志强依赖或启动容灾降级实例。

场景 2:鉴权失败与模型未授权 (401 / 403)

故障现象

客户端调用网关接口时收到:

  • 401 Unauthorized: {"error": {"code": "invalid_api_key", "message": "..."}}
  • 403 Forbidden: {"error": {"code": "model_not_allowed", "message": "..."}}

核心根因

  • 401:请求头中缺失 Authorization: Bearer <key>,或该虚拟密钥已被管理员在控制台手动停用/已过有效期;
  • 403:虚拟密钥虽然合法,但该密钥所属的「访问策略集 (Access Profile)」未包含客户端请求的目标模型。

排查步骤

  1. 在请求体中确认请求头格式无误:
    bash
    curl -i -X POST http://OMNICORTEX_URL/v1/chat/completions \
      -H "Authorization: Bearer sk-your-virtual-key" \
      -H "Content-Type: application/json" \
      -d '{"model":"qwen-max","messages":[{"role":"user","content":"hi"}]}'
  2. 登录控制台,进入「访问治理」→「虚拟密钥」,搜索该密钥状态是否为 Active,查看关联的「访问策略集」名称;
  3. 切换至「访问策略集」,检查模型白名单列表中是否勾选了客户端请求的物理模型或逻辑别名。

解决方案

  • 若密钥过期:在控制台点击延长有效期;
  • 若模型未授权:在关联访问策略集中勾选该模型并保存,网关集群秒级同步生效,无需重启任何服务。

场景 3:供应商连接不可达与跨模型降级耗尽 (502 / 503)

故障现象

客户端收到:

  • 502 Bad Gateway:上游供应商通信失败;
  • 503 Service Unavailable{"error": {"code": "all_fallbacks_exhausted"}}

核心根因

  1. 私有化部署的模型引擎(如本地机房部署的 vLLM、Ollama、TGI)内网 IP 变更或端口不可达;
  2. 公有云模型供应商因机房网络波动、欠费或全局宕机导致连接超时;
  3. 网关配置了 Fallback 容灾降级链,但降级链中所有的备选模型供应商也均处于故障或超限状态,导致兜底耗尽。

排查步骤

  1. 复制该请求的 X-Request-ID,在「调用审计日志」中查看路由详情(LogRoutingView);
  2. 观察首选模型与备选模型分别返回的具体错误码(例如首选返回 500,备选返回 429);
  3. 在管理控制台「模型供应商」中点击该供应商的连通性自检按钮,确认凭据池与网络探活状态。

解决方案

  • 修复底层私有算力容器网络路由;
  • 在「算力资产」→「故障自愈与跨模型容灾」中扩充更多异构备用通道(如同时配置公有云商用模型与私有开源算力作为双活互备)。

场景 4:SSE 流式调用卡顿或长推理中途截断

故障现象

客户端发起 stream: true 请求时:

  • 文字不逐字生成,等待 30~50 秒后一次性吐出;
  • 思考模型(DeepSeek R1、Claude 3.7 Sonnet)在深度思考 60 秒左右突然遭遇连接重置(Connection Reset)。

核心根因

  1. 网关前置的反向代理(Nginx / ALB / Ingress)开启了响应缓冲(proxy_buffering);
  2. 前置网关或客户端网络超时时间过短(低于模型长推理生成时间);
  3. 客户端 HTTP Client 本身设置了激进的 Socket 读超时。

排查步骤

  1. 绕过前置反向代理,直接在网关本地发起流式测试,验证是否逐字返回:
    bash
    curl -i -N -X POST http://127.0.0.1:8080/v1/chat/completions \
      -H "Authorization: Bearer sk-xxxxxxxx" \
      -H "Content-Type: application/json" \
      -d '{"model":"deepseek-r1","stream":true,"messages":[{"role":"user","content":"写一篇复杂的论文提纲"}]}'
  2. 若本地直连正常吐字,而经过域名访问卡顿,则可 100% 判定为反向代理层缓冲所致。

解决方案

  • 参照本文「生产环境反向代理配置避坑指南」,在前置 Nginx/Ingress 显式添加 proxy_buffering off;proxy_set_header X-Accel-Buffering "no"; 以及 proxy_read_timeout 600s;
  • 检查业务客户端代码(如 Python OpenAI SDK),将 timeout 参数显式设置为 600.0 秒。

场景 5:突发流量击穿与配额超限 (429 Too Many Requests)

故障现象

客户端频繁收到 HTTP 429 报错:

  • 错误信息包含 rpm_limit_exceededbudget_quota_exhausted
  • 或者错误信息直接来自上游供应商(Rate limit reached for model...)。

核心根因

  1. 网关层流控拦截:业务端单实例死循环或突发并发激增,超出了所属团队或虚拟密钥配置的滑动窗口 RPM(每分钟请求数)/ TPM(每分钟 Token 计数)阈值;
  2. 上游云厂商限流:上游单一 API Key 的并发配额较低,高并发下被公有云平台退避拒绝。

排查步骤

  1. 观察报错报文中的 is_omnicortex_error 字段:
    • true:说明是网关根据企业管理策略实施的保护性限流;
    • false:说明是上游供应商账号限流。
  2. 若属于网关限流:在控制台「访问治理」→「动态限流」中查看该密钥或团队的实时监控折线与配额消耗水位。

解决方案

  • 网关策略限流处置
    • 针对突发正向业务需求,管理员可在控制台针对该虚拟密钥执行紧急调额(Budget Override),或上调 RPM 阈值;
    • 推动业务端在调用逻辑中增加指数退避重试(Exponential Backoff)。
  • 上游供应商限流处置
    • 在「模型供应商」中为该供应商录入多张物理 API Key,开启加权轮询(Weighted Round-Robin)并发分流;
    • 配置多供应商通道自动故障转移。

场景 6:安全防线正向业务误杀排查

故障现象

业务端提交特定业务文本(如软件错误堆栈、合规合同、患者脱敏病例)时,收到:

  • 400 Bad Request: {"error": {"code": "guardrail_input_blocked", "message": "Input violation detected by guardrails pipeline."}}

核心根因

安全防线中启用了高灵敏度的正则拦截规则库,或 Prompt 对抗性注入引擎将正常业务上下文(如包含“Ignore all instructions”等测试用例说明文字)误判为越狱攻击。

排查步骤

  1. 根据响应中的 event_id 进入控制台「安全围栏」→「安全拦截日志」;
  2. 在搜索栏输入该 event_id,打开「安全拦截取证抽屉」;
  3. 查看黄色高亮显示的命中内容,确认是哪一条规则或引擎触发了误杀。

解决方案

  • 临时放行:在「防线工作台」中,针对该业务对应的特定团队或策略集,暂时将该检测规则的处置动作从 BLOCK 调整为 LOG(仅记录审计日志,不阻断请求);
  • 规则修正:在「能力库」中修改正向匹配正则表达式,增加负向前瞻(Negative Lookahead)或排除特定业务关键词。

故障定界速查与应急自愈清单

故障现象首选排查工具 / 命令判定层级推荐应急自愈方案
启动退出 / 探针 503docker logs / nc -zv <db> 5432基础设施层检查数据库连通性与 BIFROST_ENCRYPTION_KEY 环境变量一致性
请求报 401 密钥失效控制台「虚拟密钥」列表状态筛查访问治理层延长虚拟密钥有效期或重新启用密钥
请求报 403 模型未授权控制台「访问策略集」模型白名单访问治理层在关联策略集中勾选允许访问的目标模型
流式卡顿 / 不逐字生成本地 curl -N 绕过反代直连网关网络代理层在 Nginx/Ingress 增加 proxy_buffering off;X-Accel-Buffering no;
推理 60 秒被掐断检查 Nginx proxy_read_timeout网络代理层将反代读取超时调大至 300s600s
多模态大图报 413检查 Nginx client_max_body_size网络代理层将代理层客户端请求体大小放宽至 50m
偶发 502 / 504 上游不可达「调用审计日志」详情抽屉 Raw JSON算力供应层为核心模型配置多通道负载均衡与 Fallback 跨模型自愈降级
正常业务被 400 误拦截「安全拦截日志」取证抽屉高亮片段安全防线层调优正则关键词,或在工作台中将拦截动作暂时置为 LOG 观察模式