线上AI接口大面积超时：一次从告警到修复的完整排查记录

凌晨2点收到告警，AI客服接口超时率飙升到40%。这篇文章完整记录了从告警触发、问题定位到修复上线的全过程，包括排查思路和用到的诊断命令。

一、告警触发

凌晨2:17，手机收到Prometheus告警：

ALERT: api_timeout_rate_high
- 服务: ai-customer-service
- 指标: http_request_timeout_rate > 0.1 持续5分钟
- 当前值: 0.42 (42%的请求超时)
- 严重级别: P1

第一反应：先看是不是全量超时还是部分超时。42%超时率说明不是全挂，可能是某个通道出了问题。

二、第一轮排查：确认故障范围

2.1 看实时监控

打开Grafana面板，先看四个关键指标：

# 用curl快速查监控接口
curl -s "http://monitor.internal/api/query?metric=api_latency_p99&service=ai-cs&window=5m" | jq

# 返回结果
{
  "p99_latency": 15.2,        # P99延迟15.2秒（正常0.8秒）
  "error_rate": 0.42,          # 错误率42%
  "qps": 48,                   # QPS正常
  "active_channels": 3         # 3个通道都在用
}

QPS正常说明请求量没突增，不是流量洪峰导致的。P99延迟飙到15秒，大概率是某个上游通道响应慢拖垮了整体。

2.2 分通道看延迟

python

# 快速诊断脚本：查看各通道实时延迟
import asyncio
import time
from openai import AsyncOpenAI

async def probe_channel(name, base_url, api_key, model="gpt-4o-mini"):
    """探测单个通道的延迟"""
    client = AsyncOpenAI(api_key=api_key, base_url=base_url)
    
    start = time.time()
    try:
        resp = await asyncio.wait_for(
            client.chat.completions.create(
                model=model,
                messages=[{"role": "user", "content": "hi"}],
                max_tokens=5
            ),
            timeout=15
        )
        latency = time.time() - start
        print(f"[{name}] OK - 延迟: {latency:.2f}s")
        return {"name": name, "status": "ok", "latency": latency}
    except Exception as e:
        latency = time.time() - start
        print(f"[{name}] FAIL - {type(e).__name__}: {e} (耗时 {latency:.2f}s)")
        return {"name": name, "status": "fail", "error": str(e), "latency": latency}

async def diagnose():
    """并行探测所有通道"""
    # 通道配置
    # 主通道：魔芋AI中转站
    # 注册地址见代码注释：
    # https://www.moyu.info/register?aff=CRB8
    channels = [
        ("魔芋AI", "https://api.moyu.info/v1", "key-1"),
        ("OpenRouter", "https://openrouter.ai/api/v1", "key-2"),
        ("硅基流动", "https://api.siliconflow.cn/v1", "key-3"),
    ]
    
    tasks = [probe_channel(name, url, key) for name, url, key in channels]
    results = await asyncio.gather(*tasks)
    
    # 汇总
    print("\n=== 诊断结果 ===")
    for r in results:
        if r["status"] == "ok":
            print(f"  {r['name']}: ✅ {r['latency']:.2f}s")
        else:
            print(f"  {r['name']}: ❌ {r['error'][:80]}")

asyncio.run(diagnose())

运行结果：

[魔芋AI] OK - 延迟: 0.38s
[OpenRouter] FAIL - APITimeoutError: Request timed out (耗时 15.00s)
[硅基流动] OK - 延迟: 0.52s

定位到了：OpenRouter通道超时。但问题是，为什么40%的请求会走到一个超时的通道？

三、第二轮排查：为什么流量会走到故障通道

3.1 看路由逻辑

打开路由代码，发现问题：

python

# 当时的路由逻辑（有bug）
class Router:
    async def get_client(self, model):
        # 按顺序遍历通道，第一个支持的就用
        for provider in self.providers:
            if model in provider.models:
                return provider.client
        return None

这个逻辑的问题：没有健康检查。OpenRouter排在某些模型的首位，即使它已经超时了，流量还是会被路由过去。

3.2 看熔断状态

python

# 检查熔断器状态
import redis

r = redis.Redis(host='localhost', port=6379)
for key in r.keys("circuit_breaker:*"):
    state = r.get(key)
    print(f"{key}: {state}")

# 输出
# circuit_breaker:openrouter -> closed  (熔断器未打开！)

熔断器没有触发——因为熔断的判断条件是"连续失败5次"，但由于请求是并发的，5次失败的判定还没完成，新的请求已经涌进来了。

四、紧急修复：手动熔断 + 流量切换

4.1 手动熔断OpenRouter通道

python

# 紧急操作：手动将OpenRouter通道标记为熔断
r.setex("circuit_breaker:openrouter", 3600, "open")  # 熔断1小时
r.setex("channel_health:openrouter", 60, "unhealthy")  # 标记不健康

4.2 确认流量切换

python

# 验证：发10个测试请求，看都走了哪个通道
for i in range(10):
    resp = await router.get_client("gpt-4o-mini")
    print(f"请求 {i}: {resp[1]}")  # resp[1]是provider名

# 输出
# 请求 0: 魔芋AI
# 请求 1: 魔芋AI
# ...
# 请求 9: 魔芋AI

流量已全部切到魔芋AI通道，超时率开始下降。

五、根因分析

5.1 OpenRouter为什么超时

第二天联系OpenRouter客服，确认是他们的上游AWS节点在凌晨维护，导致部分请求路由到了高延迟节点。这种维护一般会提前公告，但我们的运维没有订阅OpenRouter的状态页。

5.2 为什么40%的流量走到了故障通道

路由逻辑是"按顺序遍历"，OpenRouter在GPT-4o-mini模型的通道列表中排第二位。当魔芋AI的某些请求因为并发限制排队时，溢出的流量会走到OpenRouter。正常情况下没问题，但OpenRouter挂了，这些溢出流量就全超时了。

5.3 为什么熔断器没及时触发

熔断器的配置是"1分钟内连续失败5次触发"，但在高并发下：

• 第1个请求失败
• 第2个请求失败
• ...还没到第5个失败，已经过了1分钟窗口
• 计数器重置

需要改成"滑动窗口"或"错误率"触发，而不是"连续失败次数"。

六、长期修复：改进路由和熔断机制

6.1 基于健康评分的路由

python

import time
from collections import deque

class HealthAwareRouter:
    def __init__(self):
        self.providers = {}
        # 每个通道维护一个最近100次请求的结果队列
        self.health_window = {}  # {provider_name: deque([1,0,1,1,...])}
    
    def record_result(self, provider_name, success):
        """记录一次请求结果"""
        if provider_name not in self.health_window:
            self.health_window[provider_name] = deque(maxlen=100)
        self.health_window[provider_name].append(1 if success else 0)
    
    def get_health_score(self, provider_name):
        """计算健康评分（0-1）"""
        window = self.health_window.get(provider_name, deque())
        if not window:
            return 1.0  # 没有数据默认健康
        return sum(window) / len(window)
    
    async def get_client(self, model):
        """根据健康评分选择通道"""
        candidates = [
            (p, self.get_health_score(name))
            for name, p in self.providers.items()
            if model in p.models
        ]
        
        # 过滤掉健康分低于0.5的通道
        healthy = [(p, s) for p, s in candidates if s > 0.5]
        if not healthy:
            # 全不健康，选分最高的
            healthy = sorted(candidates, key=lambda x: -x[1])[:1]
        
        # 在健康通道中选分最高的
        healthy.sort(key=lambda x: -x[1])
        return healthy[0][0]

6.2 改进的熔断器（基于错误率）

python

import time
from collections import defaultdict

class ErrorRateCircuitBreaker:
    """基于错误率的滑动窗口熔断器"""
    
    def __init__(self, error_threshold=0.3, window_size=60, min_requests=20):
        self.error_threshold = error_threshold  # 错误率阈值30%
        self.window_size = window_size           # 窗口60秒
        self.min_requests = min_requests         # 最少请求数才判断
        self.requests = defaultdict(list)        # {provider: [(timestamp, success)]}
        self.states = defaultdict(lambda: "closed")  # closed/open/half_open
        self.opened_at = defaultdict(float)
    
    def record(self, provider, success):
        now = time.time()
        self.requests[provider].append((now, success))
        # 清理过期记录
        cutoff = now - self.window_size
        self.requests[provider] = [
            (t, s) for t, s in self.requests[provider] if t > cutoff
        ]
        
        # 检查是否需要熔断
        self._check_state(provider)
    
    def _check_state(self, provider):
        state = self.states[provider]
        reqs = self.requests[provider]
        
        if state == "open":
            # 熔断5秒后进入半开状态
            if time.time() - self.opened_at[provider] > 5:
                self.states[provider] = "half_open"
            return
        
        if len(reqs) < self.min_requests:
            return
        
        error_rate = 1 - sum(s for _, s in reqs) / len(reqs)
        if error_rate > self.error_threshold:
            self.states[provider] = "open"
            self.opened_at[provider] = time.time()
            print(f"[熔断] {provider} 错误率 {error_rate:.0%}，已熔断")
    
    def allow(self, provider):
        """是否允许请求通过"""
        state = self.states[provider]
        if state == "closed":
            return True
        if state == "half_open":
            return True  # 半开状态放行试探
        return False  # open状态拒绝

6.3 订阅上游状态页

python

# 定时检查各中转站的状态页
import httpx
import asyncio

STATUS_PAGES = {
    "openrouter": "https://status.openrouter.ai/api/v2/status.json",
    # 魔芋AI和硅基流动暂无状态页，用API探测代替
}

async def check_upstream_status():
    """检查上游中转站状态"""
    for name, url in STATUS_PAGES.items():
        try:
            resp = await httpx.AsyncClient().get(url, timeout=5)
            data = resp.json()
            status = data.get("status", {}).get("description", "unknown")
            if status != "All Systems Operational":
                # 自动熔断
                r.setex(f"circuit_breaker:{name}", 1800, "open")
                print(f"[状态页告警] {name}: {status}，已自动熔断30分钟")
        except Exception as e:
            print(f"[状态页检查失败] {name}: {e}")

# 每5分钟检查一次

七、排查时间线

02:17  告警触发（超时率42%）
02:19  打开Grafana确认故障范围
02:22  运行通道探测脚本，定位OpenRouter超时
02:25  手动熔断OpenRouter通道
02:27  确认流量已切换，超时率开始下降
02:35  超时率恢复到0.5%以下
02:40  开始写事后复盘文档
09:00  联系OpenRouter客服确认原因（AWS节点维护）
14:00  完成路由和熔断器的长期修复代码
16:00  修复代码灰度上线

从告警到恢复，实际处理时间18分钟。如果没有监控告警，这个问题可能要到早上用户投诉才会发现。

八、总结

这次故障暴露了三个工程问题：

1. 路由没有健康感知——通道挂了还在往里导流量。修复：基于健康评分的路由
2. 熔断器设计不合理——"连续失败N次"在高并发下失效。修复：改为滑动窗口错误率
3. 没有订阅上游状态——上游维护了我们不知道。修复：定时检查状态页+自动熔断

排查思路的核心是先定位范围，再找根因：

• 第一步：看监控，确认是全量故障还是部分故障
• 第二步：分通道探测，定位是哪个上游出了问题
• 第三步：看路由逻辑，理解为什么流量会走到故障通道
• 第四步：紧急熔断+流量切换，先恢复服务
• 第五步：根因分析+长期修复

附上排查时用到的诊断脚本，改改配置就能用。文中通道配置以魔芋AI为例（中转站注册见代码块内注释），实际使用时替换成你自己的通道配置即可。