生产环境上线前的最后一环——可观测性（Observability）与灾难自愈（Disaster Recovery）。--怡心湖

对于 AI 智能体（Agent）私有化部署来说，“能跑”和“能稳”是两回事。

很多时候系统不是被压垮的，是被显存泄漏、日志写满、KV Cache 碎片、慢请求堆积慢慢拖死的。

这一章，我们把 Linux 从“静态配置”升级为“动态免疫系统”。

一、可观测性体系：从“看热闹”到“看门道”

Monitoring Stack: From Vanity Metrics to Actionable Signals

1. 三层黄金指标（Golden Signals for Agents）

不要只盯着 CPU 和内存，Agent 场景必须盯这三个维度：

层级	核心指标	报警阈值建议	说明
GPU 层	GPU Mem Used %	>85% (Warning) >92% (Critical)	防止 OOM 导致推理服务崩溃
	GPU Utilization	<10% (Idle)	检查是否为调度阻塞或输入瓶颈
	Power / Temp	>95°C	温度过高触发降频，推理变慢
推理层	TTFT (首Token延迟)	P99 > 3s	反映 Prefill 阶段拥堵（Prompt 太长/并发太高）
	ITL (Token间隔)	P99 > 150ms	反映 Decode 阶段性能（KV Cache/显存带宽）
	Waiting Queue	> 5 reqs	立刻触发扩容或限流
系统层	Load Average	> CPU核数 * 2	检查是否是 Python GIL 或 IO Wait
	Disk Inode Usage	>80%	模型分片多，inode 容易先爆

2. 日志治理：防止“模型日志”把磁盘淹死

大模型喜欢刷日志（Generating..., Prefill...），一天几十 GB 很常见。

Docker 级别：必须限制，上一章已给过配置，这里强调执行：
```
# 确认生效
docker inspect <container_id> | grep LogConfig
```
应用级别：Agent 框架（LangChain/LangGraph）建议设置日志级别为 WARNING或 ERROR，不要开 DEBUG跑生产。

日志轮转（Logrotate）：

为宿主机日志单独配置：

/var/log/ai-agent/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

二、显存与进程的生命体征监护

GPU Process Watchdog: The Last Line of Defense

1. 显存泄漏自动清理脚本（Watchdog）

这是生产环境必装脚本。很多推理框架在异常请求（超长上下文、畸形 JSON）后会残留显存块，导致可用显存越来越少。

创建一个 gpu_watchdog.sh：

#!/bin/bash
# 监控显存占用，超过阈值且无进程响应时，重启容器

THRESHOLD_MB=85000  # 假设 96GB 显存，设 85GB 警戒线
CONTAINER_NAME="vllm-inference"

while true; do
    # 获取已用显存（单位 MB）
    USED_MEM=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | head -n1)

    if [ "$USED_MEM" -gt "$THRESHOLD_MB" ]; then
        echo "$(date): WARNING - GPU Mem $USED_MEM MB exceeds $THRESHOLD_MB. Restarting container..."
        # 优雅停止 -> 强制停止 -> 重启
        docker stop $CONTAINER_NAME
        sleep 5
        docker start $CONTAINER_NAME
    fi
    sleep 60
done

配合 systemd注册为后台服务，实现无人值守自愈。

2. 僵尸进程清理

Agent 调用外部工具（Shell、Python 脚本）时，如果超时控制不好，容易产生 <defunct>僵尸进程，吃光 PID。

# 定时清理僵尸进程（谨慎使用，仅作兜底）
ps -A -ostat,ppid | awk '/[zZ]/ && $2 != 1 { print $2 }' | xargs -r kill -9

三、网络与 API 网关的熔断机制

Network Resilience: Circuit Breakers

Agent 经常要调用外部 API（搜索、数据库、企业内部接口）。如果下游挂了，Agent 会疯狂重试，把自己拖死。

1. Linux 内核层面的连接保护

确保以下参数已生效（回顾上一章）：

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

这能防止大量 TIME_WAIT连接耗尽端口，导致 Agent 无法调用工具。

2. 应用层：Nginx / API Gateway 限流

在 Agent 入口处（对外 API）一定要加一道闸：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

    server {
        location /v1/chat/completions {
            limit_req zone=one burst=20 nodelay;
            proxy_pass http://backend_inference;
        }
    }
}

目的：防止用户恶意刷接口或前端 Bug 导致瞬间万级请求，直接击穿后端推理服务。

四、备份与回滚：模型的版本控制

Model Versioning & Rollback Strategy

1. 模型权重存储规范

不要把模型直接塞进容器镜像里，也不要随便丢在一个目录。

建议目录结构：

/data/models/
├── llama3-8b/
│   ├── v1.0/  # 初始上线
│   ├── v1.1/  # LoRA 微调后
│   └── current -> v1.1  # 软链接，便于回滚

推理服务启动时挂载 current目录。

2. 回滚脚本（Rollback Plan）

当发现新模型效果差或有 Bug 时，30 秒内切回旧模型：

cd /data/models/llama3-8b
rm current && ln -s v1.0 current
docker restart vllm-inference

五、灾难演练清单（Chaos Engineering Lite）

Pre-Flight Checklist Before Going Live

在上线前，建议你亲自做一次“暴力测试”，验证系统是否真的稳：

拔网线测试：在推理过程中断开 1 张 GPU 的网络（如果是多卡），看服务是否降级而非崩溃。
磁盘满测试：fallocate -l 500G test.img把磁盘写满，看日志是否停止且不导致推理进程退出。
OOM 测试：故意发一个超长 Prompt（10万 tokens），看是否会触发限流，而不是把整个容器炸掉。
重启测试：docker restart后，模型能否在 30 秒内重新加载完毕并恢复服务？

六、总结：从“运维”到“运营”

继续阅读：僵尸进程生产环境上线可观测性 Observability 灾难自愈 Disaster Recovery

此文由怡心湖编辑，若您觉得有益，欢迎分享转发！：首页 > 常识论 » 生产环境上线前的最后一环——可观测性（Observability）与灾难自愈（Disaster Recovery）。