Linux生产环境AIGC服务排查手册:日志分析进程管理网络诊断实战

AIGC服务（大模型推理、向量检索、图片生成等）在生产环境中往往涉及多个微服务、GPU集群和海量日志。当服务出现异常时，如何快速定位问题？本文从日志分析、进程管理、网络诊断三个维度，结合大量实战命令，提供一套完整的Linux排查方法论。

一、AIGC服务典型架构与故障场景

1.1 常见架构

用户请求 → Nginx负载均衡 → API网关(Spring Boot) → 服务编排层
                                            ├─ LLM推理服务(Python/FastAPI, GPU)
                                            ├─ 向量数据库(Redis/Milvus)
                                            ├─ 文件存储(MinIO/S3)
                                            └─ 消息队列(Kafka/RabbitMQ)

1.2 高频故障场景

二、日志分析实战

2.1 日志定位与关键字搜索

AIGC服务的日志通常分布在多个位置：

# 查看系统日志
sudo journalctl -u aigc-api.service --since "1 hour ago" --no-pager

# 查看Docker容器日志
docker logs --since 30m aigc-llm-service -f

# 查看Kubernetes Pod日志
kubectl logs -f aigc-llm-deployment-abc123 --tail=200 -n production

# 按时间范围筛选
journalctl -u aigc-api.service -S "2025-07-06 10:00:00" -U "2025-07-06 12:00:00"

关键字搜索实战：

# 搜索错误级别日志
grep -rn "ERROR\|FATAL\|Exception" /var/log/aigc/ --include="*.log" | head -50

# 搜索特定请求ID（追踪一次请求的全链路）
grep "req-id: abc-123-def" /var/log/aigc/api-gateway.log

# 搜索超时和OOM相关日志
grep -rn "timeout\|OOM\|OutOfMemory\|Killed" /var/log/aigc/

# 统计错误类型分布
grep -oP '"level":"\K[^"]+' /var/log/aigc/app.json.log | sort | uniq -c | sort -rn

# 按小时统计错误数量（定位故障时间段）
grep "ERROR" /var/log/aigc/app.log | awk '{print substr($1,1,13)}' | sort | uniq -c

2.2 结构化日志分析（JSON格式）

现代AIGC服务多采用JSON结构化日志，使用 jq 分析：

# 提取所有ERROR级别的日志
cat /var/log/aigc/app.json.log | jq 'select(.level=="ERROR")' | head -20

# 统计某个接口的平均响应时间
cat /var/log/aigc/access.json.log | jq -r 'select(.endpoint=="/api/v1/chat") | .response_time_ms' | awk '{sum+=$1; count++} END {print "avg:", sum/count, "ms, total:", count}'

# 找出响应时间超过5秒的请求
cat /var/log/aigc/access.json.log | jq 'select(.response_time_ms > 5000)'

# 按IP统计请求量（排查恶意刷接口）
cat /var/log/aigc/access.json.log | jq -r '.client_ip' | sort | uniq -c | sort -rn | head -20

2.3 日志轮转与磁盘清理

日志暴涨是AIGC服务的常见坑：

# 检查日志文件大小
du -sh /var/log/aigc/* | sort -rh | head -10

# 检查磁盘使用率
df -h

# 查看日志轮转配置（logrotate）
cat /etc/logrotate.d/aigc-api

# 手动触发日志轮转
sudo logrotate -f /etc/logrotate.d/aigc-api

# 清理过期日志（保留最近7天）
find /var/log/aigc/ -name "*.log.*" -mtime +7 -delete

# 临时释放被删除但仍被进程占用的磁盘空间
# 先找到占用文件的进程
lsof | grep deleted | grep log
# 然后截断文件释放空间
sudo truncate -s 0 /proc/$(pgrep -f aigc-api)/fd/$(lsof -p $(pgrep -f aigc-api) | grep log | awk '{print $9}' | head -1)

2.4 日志聚合与实时监控

生产环境建议使用ELK或Loki：

# Loki配置示例 (promtail)
server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: aigc-logs
    static_configs:
      - targets:
          - localhost
        labels:
          job: aigc-api
          __path__: /var/log/aigc/*.log

Grafana中的日志查询语法：

# 查询aigc-api服务的ERROR日志
{job="aigc-api"} |= "ERROR"

# 查询包含特定异常的日志
{job="aigc-llm"} |= "CUDA_ERROR_OUT_OF_MEMORY"

# 按时间窗口聚合
{job="aigc-api"} |~ "(ERROR|WARN)" | line_format "{{.message}}"

三、进程管理实战

3.1 进程状态诊断

# 查看AIGC相关进程
ps aux | grep -E "aigc|python|fastapi|uvicorn|java|spring" | grep -v grep

# 查看进程资源占用TOP 10
ps aux --sort=-%mem | head -11
ps aux --sort=-%cpu | head -11

# 查看进程打开的文件数（排查文件描述符泄漏）
ls /proc/$(pgrep -f uvicorn)/fd | wc -l

# 查看进程树关系
pstree -p -s $(pgrep -f aigc-api)

# 查看进程的线程数（高并发服务线程过多可能有问题）
ps -T -p $(pgrep -f aigc-api) | wc -l

3.2 CPU飙高排查

# 步骤1: 找到CPU占用最高的进程
top -bn1 | head -20

# 步骤2: 切换到PID视图，按CPU排序
top -H -p $(pgrep -f aigc-llm)

# 步骤3: 找到具体线程ID
printf '%x\n' <thread_id>

# 步骤4: 导出堆栈信息
jstack $(pgrep -f java) > /tmp/jstack-$(date +%s).txt    # Java服务
gdb -p $(pgrep -f uvicorn) -batch -ex "thread apply all bt" > /tmp/gdb-$(date +%s).txt  # Python C扩展

# 步骤5: 使用perf采样分析热点
sudo perf top -p $(pgrep -f aigc-llm)
sudo perf record -g -p $(pgrep -f aigc-llm) -- sleep 30
sudo perf report

Python CPU分析工具：

# cprofile_profiler.py - 性能剖析脚本
import cProfile
import pstats
from pstats import SortKey

def profile_service():
    """包裹你的服务入口函数"""
    profiler = cProfile.Profile()
    profiler.enable()
    
    # 这里放你的服务启动代码
    # 例如: app.run() 或 main()
    
    profiler.disable()
    stats = pstats.Stats(profiler)
    stats.sort_stats(SortKey.TIME)
    stats.print_stats(30)  # 打印耗时最多的30个函数
    stats.dump_stats('/tmp/profile.prof')

if __name__ == "__main__":
    profile_service()

# 使用snakeviz可视化性能分析结果
pip install snakeviz
snakeviz /tmp/profile.prof

3.3 内存泄漏排查

# 监控进程内存趋势
watch -n 5 "ps -o pid,rss,vsz,cmd -p $(pgrep -f aigc-llm) 2>/dev/null"

# 使用valgrind检测内存泄漏（开发/测试环境）
valgrind --leak-check=full --show-leak-kinds=all python app.py

# Python内存分析工具
pip install tracemalloc memory-profiler

# memory_profiler使用示例
# 在函数上加 @profile 装饰器
"""
@profile
def generate_embedding(texts):
    embeddings = model.encode(texts)
    return embeddings.tolist()
"""
python -m memory_profiler your_script.py

Python GC调试：

import gc
import sys

# 强制垃圾回收并查看结果
gc.collect()
for obj in gc.get_objects():
    if isinstance(obj, dict) and len(obj) > 10000:
        print(f"Large dict found: {len(obj)} keys")

# 查看对象数量趋势
print(sys.getsizeof(gc.get_objects()))

3.4 文件描述符与连接数限制

# 查看当前系统文件描述符限制
cat /proc/sys/fs/file-max

# 查看当前已使用的文件描述符数量
cat /proc/sys/fs/file-nr

# 查看单个用户的文件描述符限制
ulimit -n

# 查看进程打开的文件描述符
ls -la /proc/$(pgrep -f aigc-llm)/fd | wc -l

# 查看网络连接状态（排查TIME_WAIT堆积）
ss -s
ss -tan | awk 'NR>1 {++s[$1]} END {for(k in s) print k, s[k]}'

# TIME_WAIT过多的处理
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

3.5 服务启停与守护管理

# systemd管理服务
sudo systemctl status aigc-llm
sudo systemctl restart aigc-llm
sudo systemctl enable aigc-llm  # 开机自启

# 查看服务启动日志
sudo journalctl -u aigc-llm -f

# 设置资源限制（Systemd方式）
sudo tee /etc/systemd/system/aigc-llm.service.d/override.conf <<EOF
[Service]
LimitNOFILE=65535
LimitMEMLOCK=infinity
MemoryMax=32G
CPUQuota=200%
EOF
sudo systemctl daemon-reload
sudo systemctl restart aigc-llm

# Docker容器管理
docker ps -a | grep aigc
docker restart aigc-llm
docker inspect aigc-llm | jq '.[0].HostConfig.Memory'  # 查看内存限制

# Kubernetes优雅重启
kubectl rollout restart deployment/aigc-llm -n production
kubectl rollout status deployment/aigc-llm -n production

四、网络诊断实战

4.1 连通性与端口检查

# 检查端口是否在监听
ss -tlnp | grep -E "8080|5000|8000"
netstat -tlnp | grep -E "8080|5000|8000"

# 测试本地端口连通性
curl -v http://localhost:8080/health
curl -v http://localhost:5000/chat

# 检查防火墙规则
sudo iptables -L -n -v
sudo firewall-cmd --list-all    # CentOS/RHEL

# 测试到下游服务的连通性
nc -zv python-ai-service 5000
telnet milvus-vector 19530

# 检查DNS解析
dig python-ai-service.default.svc.cluster.local
nslookup milvus-vector

4.2 网络延迟与丢包诊断

# ping检测基础连通性
ping -c 10 python-ai-service

# traceroute追踪路由（定位网络瓶颈节点）
traceroute python-ai-service

# mtr综合诊断（ping + traceroute，持续监控）
mtr -c 100 -r python-ai-service

# 使用tcping检测TCP端口延迟
sudo apt install tcping
tcping python-ai-service 5000

# 检查网络接口错误包
cat /proc/net/dev
cat /proc/net/snmp | grep TcpExt

4.3 带宽与流量监控

# 实时查看网卡流量
iftop -i eth0
nethogs eth0

# 使用sar监控历史网络数据
sar -n DEV 1 10          # 每秒采样10次
sar -n TCP,ETCP 1 10     # TCP连接统计

# 安装sysstat获取sar
sudo apt install sysstat

# 查看网络吞吐TOP进程
sudo apt install nethogs
sudo nethogs eth0

# 使用tc进行流量整形和限速
sudo tc qdisc add dev eth0 root tbf rate 1gbps burst 32kbit latency 400ms

4.4 连接池与HTTP诊断

# 查看TCP连接状态分布
ss -s

# 详细输出
# Total: 12345 (kernel 15000)
# TCP:   8900 (estab 3200, closed 1800, orphaned 50, synrecv 0, timewait 1800/0), ports 0
# 
# Transmitted  5600000(4200GB) recv packets  4800000(3800GB)
# Resends      1200 (0.02%)  重建连接数少说明网络稳定

# 查看ESTABLISHED连接详情
ss -tn state established '( sport = :8080 or dport = :8080 )'

# 查看TIME_WAIT堆积
ss -tan | grep TIME-WAIT | wc -l

# 使用ab压测API接口
ab -n 1000 -c 50 http://localhost:8080/api/chat

# 使用wrpress（更精确的HTTP压测）
wrk -t4 -c100 -d30s http://localhost:8080/api/chat

# 抓包分析（定位协议层面问题）
sudo tcpdump -i eth0 -nn -s 0 -w /tmp/aigc-debug.pcap port 8080
sudo tcpdump -i eth0 'tcp port 5000 and host 10.0.0.5' -nn -A | head -100

4.5 负载均衡与健康检查

# 检查Nginx上游健康状态
curl http://localhost/nginx_status

# 查看Nginx错误日志
tail -100 /var/log/nginx/error.log | grep -E "upstream|connect|timeout"

# Nginx上游响应时间分析
grep "upstream_response_time" /var/log/nginx/access.log | awk '{print $NF}' | sort -n | tail -20

# 检查负载均衡策略下的连接分发
curl -s http://localhost/health | jq '.'
# 多次请求观察返回的instance_id，确认是否均匀分发

五、GPU专项排查

5.1 GPU状态监控

# 查看GPU基本信息
nvidia-smi

# 实时刷新GPU状态（每2秒）
watch -n 2 nvidia-smi

# 查看GPU温度、功耗、利用率
nvidia-smi --query-gpu=index,name,temperature.gpu,utilization.gpu,memory.used,memory.total,power.draw --format=csv

# 查看GPU进程级资源占用
nvidia-smi pmon -c 1

# 查看GPU ECC错误（硬件故障信号）
nvidia-smi ecc -i 0 --errors

# 查看GPU持久模式状态
nvidia-smi -q | grep "Persistence Mode"

5.2 GPU OOM排查

# 查看CUDA错误日志
dmesg | grep -i "cuda\|nvidia\|gpu"

# 查看内核OOM Killer是否杀掉了GPU进程
dmesg | grep -i "Out of memory"
grep -i "oom" /var/log/kern.log

# Python端捕获CUDA错误
python -c "
import torch
try:
    x = torch.randn(10000, 10000, device='cuda')
except RuntimeError as e:
    print(f'CUDA Error: {e}')
    torch.cuda.empty_cache()  # 强制清理缓存
"

# 检查GPU显存碎片化
nvidia-smi --query-gpu=memory.used,memory.free --format=csv

5.3 GPU驱动与容器

# 检查NVIDIA驱动版本
nvidia-smi --driver-version

# 检查CUDA版本
nvcc --version

# 检查NVIDIA Container Toolkit
docker run --rm --gpus all nvidia/cuda:12.1-base nvidia-smi

# 查看GPU设备文件权限
ls -la /dev/nvidia*

# 重启GPU驱动（紧急恢复，会中断所有GPU进程）
sudo rmmod nvidia_uvm
sudo rmmod nvidia_drm
sudo rmmod nvidia
sudo modprobe nvidia

六、排查工具箱速查表

# ==================== 一键排查脚本 ====================
#!/bin/bash
# diagnose-aigc.sh - AIGC服务快速诊断脚本

echo "===== 系统信息 ====="
uname -a
uptime
free -h
df -h

echo ""
echo "===== 相关进程 ====="
ps aux | grep -E "aigc|uvicorn|fastapi" | grep -v grep

echo ""
echo "===== 端口监听 ====="
ss -tlnp | grep -E "8080|5000|8000"

echo ""
echo "===== 网络连接 ====="
ss -s

echo ""
echo "===== GPU状态 ====="
nvidia-smi --query-gpu=name,temperature.gpu,utilization.gpu,memory.used,memory.free --format=csv

echo ""
echo "===== 最近错误日志 ====="
journalctl -u aigc-api --since "1 hour ago" -p err --no-pager | tail -20

echo ""
echo "===== 磁盘IO ====="
iostat -x 1 3

echo ""
echo "===== 排查完成 ====="

七、总结

AIGC服务生产排查的核心思路：

1. 日志先行：先看日志定位错误类型和时间窗口
2. 进程为基：确认服务进程存活、资源占用正常
3. 网络为辅：排除连接、延迟、丢包等网络层问题
4. GPU特查：显存、温度、驱动单独监控

掌握这套排查方法论后，面对90%以上的AIGC生产故障都能做到5分钟内定位根因。

💡 经验之谈：建立完善的监控告警体系（Prometheus + Grafana + AlertManager）比事后排查更重要。让系统在问题发生时就主动通知你，才是最高效的运维方式。