📚 课程目录第3章 NX-OS系统级故障诊断

3. NX-OS系统级故障诊断

当 Nexus 交换机的故障从“某个接口不通”上升到“整机行为异常”时，问题往往已经脱离单个协议或单条链路，进入 NX-OS 系统级范畴。典型表现包括：管理面响应迟缓、SSH 登录超时、SNMP 轮询中断、路由协议邻居批量抖动、控制平面进程反复重启，甚至整机 reload。此时若仍按接口、VLAN、路由逐层排查，效率极低。正确的切入点是先判断系统资源与进程健康状态，再结合系统日志和核心转储定位根因。

一、先分清四类系统级故障的边界

NX-OS 的系统级故障通常可归为四类，它们的现象相似但根因和处理路径不同：

进程崩溃（Process Crash）：某个守护进程异常退出，可能触发进程重启或 supervisor 切换。表现为日志中出现 %SYSMGR-2-SERVICE_CRASHED、%SYSMGR-2-SERVICE_EXITED，并可能生成 core 文件。
内存泄漏（Memory Leak）：进程持续申请内存但不释放，表现为该进程 RSS 随时间单调上升，最终触发 OOM 或进程被杀。
CPU 过载：某进程或内核线程长时间占用 CPU，导致其他进程调度延迟，控制平面收敛变慢。
内存过载：整机物理内存或某分区（如 supervisor 内存）被耗尽，系统进入降级状态。

这四类问题经常互为因果：内存泄漏会引发内存过载，内存过载会触发进程崩溃，进程崩溃又可能造成 CPU 瞬时冲高。因此诊断顺序应是“先看资源、再看进程、最后看日志与 core”。

二、资源与进程的快速体检命令

登录到出现异常的 supervisor，按以下顺序采集基线数据：

show system resources
show processes cpu sort | head 20
show processes memory sort | head 20
show process cpu history
show process memory history
show logging logfile | tail 200
show cores
dir core://

其中 show system resources 给出整机 CPU 利用率、内存总量/已用/空闲、load average；show processes cpu sort 与 show processes memory sort 按占用排序，能快速锁定异常进程。注意 NX-OS 中进程名通常带 % 前缀，例如 %KERNEL、%LIBPTHREAD、%NTP、%ARP、%L3VM、%OSPF 等，这些是内核线程或系统服务，不能简单等同于用户态进程。

建议在故障发生前就建立“健康基线”：记录正常状态下 CPU 空闲率、内存空闲量、关键进程 RSS 和 CPU 占用。没有基线，很难判断当前数值是否异常。

三、进程崩溃与核心转储分析

进程崩溃后，NX-OS 的 system manager 会记录事件并尝试重启该进程。若配置了 core 转储，会在 core:// 或 bootflash://core 生成 core 文件。诊断流程如下：

用 show cores 查看是否有 core 记录，确认崩溃进程名、PID、时间戳。
用 show logging logfile 找到崩溃前后的日志，关注 %SYSMGR-2-SERVICE_CRASHED 及其携带的 signal 编号（如 SIGSEGV=11、SIGABRT=6）。
用 show tech-support details 采集完整技术支撑信息，包含进程状态、内存、日志、core 列表。
将 core 文件导出到外部 TFTP/SCP 服务器，交由 Cisco TAC 用符号表解析调用栈。

常见崩溃信号含义：SIGSEGV 表示非法内存访问，多与空指针或越界有关；SIGABRT 表示进程主动 abort，常由断言失败触发；SIGBUS 表示总线错误，可能与硬件或对齐访问有关。仅凭信号不能定论，必须结合 core 调用栈和崩溃前日志。

四、内存泄漏的识别与验证

内存泄漏的典型特征是“进程 RSS 单调上升，且不随业务量回落”。识别方法：

show processes memory sort | head 20
show process memory history | include <进程名>
show system resources | include Memory

若某进程 RSS 在数小时内从 200MB 升至 1.5GB，且业务流量平稳，则高度怀疑泄漏。进一步可用 show process memory history 观察趋势曲线。NX-OS 中部分进程有内存阈值告警，日志会出现 %MMON-2-MEMORY_THRESHOLD_EXCEEDED 或 %MMON-3-MEMORY_LEAK_DETECTED。确认泄漏后，通常需要升级到修复版本或重启对应进程（如 restart <进程名>），但重启前应评估对业务的影响。

五、CPU 过载的定位

CPU 过载分“用户态进程占用高”和“内核态占用高”两类。用 show processes cpu sort 看用户态，用 show system resources 看整体。若 %KERNEL 或 %LIBPTHREAD 占用高，往往是中断风暴、内存压力或底层驱动问题。常见诱因包括：ARP 表剧烈变化、MAC 地址漂移、路由震荡、SNMP 轮询过频、镜像流量过大。定位时结合 show process cpu history 看历史趋势，并对照日志中的协议事件。

六、系统日志与核心转储的联合判读

系统日志是串联所有线索的主线。建议按时间轴阅读：先定位第一个异常日志，再向后看连锁反应。NX-OS 日志级别从 0（emergency）到 7（debugging），重点关注 0–3 级。常用命令：

show logging logfile
show logging logfile | include %SYSMGR
show logging logfile | include %MMON
show logging logfile | include %KERNEL
show logging server

下图给出系统级故障从资源异常到日志与 core 的联合判读路径，帮助建立整体诊断视角。

七、诊断闭环与注意事项

系统级诊断的闭环可以概括为：采集基线 → 定位异常进程 → 关联日志事件 → 分析 core → 验证修复。每一步都要留下证据，避免凭经验猜测。几个容易踩的坑：

不要只重启进程了事。重启会清除现场，core 和日志可能丢失，应先采集 show tech-support details。
不要忽略时间同步。日志时间戳若与 NTP 不同步，跨设备关联会错乱。
不要混淆“进程重启”和“进程崩溃”。前者可能是正常 HA 切换，后者才有 core。
不要在高 CPU 时执行大量 show 命令，可能加重负载，应优先用 show process cpu history 等轻量命令。

最后，建议把本节命令整理成一份可执行的检查清单，在故障窗口内按序执行，既能保证采集完整，也能为后续 TAC 分析提供高质量输入。