故障排查和应急措施 Diagnosis

当线上出现故障时，如何分工和快速排查

一般从网关响应码、服务节点状态和数据库三方面入手

  1. 查看负载均衡流量情况

从 网关日志/ELK/SLB 等监控平台过滤 50x 相关日志，快速定位异常接口和服务

  1. 查看所有容器状态

# 默认namespace: vika-app 
kubectl --kubeconfig  /data/vika/app/config-k8s/kubeconfig get pods -n vika-app

是否都在Running呢？

fusion-server 和room-server出现大量restart 时，是数据库出现连接不上的情况。

  1. 查看CPU、磁盘使用量是否正常.

  2. 查看数据库性能情况

    • MySQL诊断 CPU/内存/磁盘使用率 监控：

    • MySQL10秒查询 错误日志、异常告警：

    • MySQL SQL慢查询：

fusion api 出现 50x 排查

定位 50x 错误（如 500 内部服务器错误、502 网关错误、503 服务不可用、504 网关超时）的根因，范围聚焦 Fusion-Server 服务，通过 “网关日志→K8s 状态→Pod 日志” 三级排查，快速定位问题并推动修复。

步骤 1：从网关日志定位报错接口与精确时间

网关是请求入口，优先通过网关日志筛选 50x 错误对应的接口、请求参数及精确报错时间，为后续 Pod 排查提供依据。

1.1 访问网关日志查询平台

登录日志平台（如 ELK Stack、Grafana Loki），进入 Fusion-Server 对应的网关日志索引（如 gateway-fusion-server-）。

1.2 筛选 50x 错误日志

筛选条件：

错误码：response_code: 50* 匹配 500/502/503/504 等）；

服务标识：service_name: fusion-server（指定目标服务）；

时间范围：设置为 “异常时间段”（如 2025-09-20T14:30:00Z TO 2025-09-20T15:00:00Z）。

1.3 提取关键信息

从查询结果中记录以下信息，用于后续排查：

精确报错时间：@timestamp（如 2025-09-20T14:45:23.123Z）； 报错接口：request_path（如 /api/v1/fusion/task/submit）； 客户端信息（可选）：client_ip、request_id（便于追踪完整请求链路）。

步骤 2：通过 K8s 命令检查 Fusion-Server Pod 重启状态 50x

错误常与 Pod 异常重启（如 OOM 内存溢出、健康检查失败）相关，需确认异常时间段内 Fusion-Server Pod 是否存在重启记录。

2.1 查看 fusion-Server 所有 Pod 状态

执行以下命令，列出当前 Fusion-Server 所属 Namespace（如 fusion-prod）下的所有 Pod：


# 替换 <namespace> 为实际命名空间（如 fusion-prod）

kubectl get pods -n vika-app -l app=fusion-server

输出示例：


NAME                              READY   STATUS    RESTARTS   AGE

fusion-server-7f98d7c6b4-2xqzk   1/1     Running   1          30m

fusion-server-7f98d7c6b4-5m8kp   1/1     Running   0          3d

关键关注 RESTARTS 列：若值 > 0，说明 Pod 存在重启。

2.2 查看 Pod 重启时间，匹配异常时间段
针对 RESTARTS > 0 的 Pod，执行以下命令查看其重启历史，确认是否与 50x 错误时间段重合：

# 替换 <namespace> 和 <pod-name> 为实际信息

kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Last State"

输出示例（包含重启时间）：

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Fri, 20 Sep 2025 14:40:15 +0800
  Finished:     Fri, 20 Sep 2025 14:45:20 +0800

判断标准：若 Finished 时间（重启完成时间）与步骤 1 中 50x 报错时间（如 14:45:23）接近（误差 < 10 分钟），则 Pod 重启极可能是 50x 错误的诱因。

步骤 3：进入 Pod 内部查看 Fusion-Server 日志

根据步骤 2 定位的异常 Pod，进入 Pod 内部查询 error.log（错误日志）和 “重启前日志”，定位具体代码层面的报错（如空指针、数据库连接失败）。

3.1 进入 Fusion-Server Pod 终端

执行以下命令进入目标 Pod 的容器终端（默认取第一个容器，若有多个容器需加 -c <container-name>）：

# 替换 <namespace> 和 <pod-name> 为实际信息
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash

3.2 查看 error.log 错误日志

根据 Fusion-Server 日志目录规范（参考 官方文档），通常 error.log 位于 /app/packages/room-server/logs/FUSION_SERVER/ 目录下。

3.2.1 查看最新错误日志 

# 进入日志目录（若路径不同，需替换为实际路径）
cd /app/packages/room-server/logs/FUSION_SERVER/

# 查看 error.log 最后 500 行，筛选步骤 1 中的报错接口或时间
tail -200f error.log | grep -E "2025-09-20 14:45"

tail -200f 2025-09-20*.log | grep -E "2025-09-20 14:45"

关键排查内容： 异常堆栈：是否有 pm2、exception、ms 等明确错误； 资源报错：是否有 “数据库连接池耗尽”“Redis 连接超时”“内存溢出” 等资源相关错误。

3.2.2 按时间段查询 error.log

若需查看特定时间段的错误日志（如 14:40 - 14:50），可使用 sed 或 grep 结合时间格式筛选：

# 假设日志时间格式为 "2025-09-20 14:45:23"，筛选 14:40-14:50 的日志

sed -n '/2025-09-20 14:40/,/2025-09-20 14:50/p' error.log > error_1440_1450.log
sed -n '/2025-09-20 14:40/,/2025-09-20 14:50/p' 2025-09-20*.log > 2025-09-20_1440_1450.log

# 查看筛选后的日志
cat error_1440_1450.log
cat 2025-09-20_1440_1450.log

3.3 查看 Pod 重启前的日志（关键！）

Pod 重启后，部分运行日志可能未写入 error.log，需通过 K8s 命令查看 Pod 重启前的 “终止日志”（Termination Log），补充重启原因：

# 退出 Pod 终端（执行 exit 命令），在本地执行以下命令
kubectl logs <pod-name> -n <namespace> --previous

  • 适用场景：Pod 因 OOM 重启、健康检查失败（如 liveness/readiness probe 超时），重启前的关键报错（如 JVM /node 内存溢出日志）会通过该命令输出；