简介
本文档提供了调查统一计算系统交换矩阵互联(FI)崩溃或意外重启故障的步骤。
在高级别上，以下问题可能导致FI重新启动
- 内核空间进程崩溃（又称内核死机）
- 内核内存不足（内存不足 — OOM终止用户进程以回收内存）
- 用户空间进程崩溃(例如- netstack、fcoe_mgr、callhome等
- FI固件问题(罕见场景，示例 — CSCuq46105)或硬件组件故障（如用于存储的SSD）
先决条件
要求
Cisco 建议您了解以下主题：
思科统一计算系统(UCS)管理器
思科统一计算系统(UCS)管理器命令行界面(CLI)
所需的日志文件
当FI意外重新启动时，收集以下日志并将其上传到TAC服务请求。
您可以通过CLI或GUI检查核心转储文件
UCS-FI #范围监控
UCS-FI /monitoring # scope sysdebug
UCS-FI /monitoring/sysdebug # show cores detail
- 如果FI已配置为将日志导出到系统日志服务器，请从系统日志服务器为在重新启动时间戳之前提供7天历史记录的设备收集日志消息。
分析日志以查找初始线索
1)检查Nexus操作系统(NX-OS)" show version "命令输出中的重新启动原因和时间戳
2)在重新启动时间戳之前，检查日志消息的“ show logging nvram”命令输出
3)检查系统日志服务器上存储的日志消息，以获取其他线索
4)如果重新启动是由用户空间进程崩溃触发的，请检查与进程名称匹配的核心转储和重新启动时间戳。
6)如果出现内核死机，请检查名为" sw_kernel_trace_log "的文件中的内核堆栈跟踪输出
从UCSM 2.2.1b中，此文件包含UCSM show techsupport套件。
对于2.2.1b之前的UCSM版本，请收集以下命令的输出
connect nxos
show logging onboard kernel-trace | no-more
show logging onboard obfl-history | no-more
show logging onboard stack-trace | no-more
show logging onboard internal kernel | no-more
show logging onboard internal kernel-big | no-more
show logging onboard internal platform | no-more
show logging onboard internal reset-reason | no-more
7)" topout.log "每两秒包含" top "命令的输出。在重新启动之前，UCSM将旧日志集保存为/opt/sam_logs.tgz文件。它可以提供有关内存、利用率或进程的信息。
8)如果您注意到“内存不足(OOM)”等消息导致进程中断，且进程崩溃可能触发FI重新启动，并会作为重置原因列出。在这些情况下，该进程很可能是内存不足的牺牲品，并且可能不是崩溃或内存泄漏的原因。
收集有关UCS设置的信息
回答以下问题有助于更好地了解系统设置及其重新启动前的状态。
1)此问题以前是否发生过？
2)重新启动前后是否有任何特定用户活动？
3)对FI最近进行的任何软件/硬件/配置更改？
4)Fi是否由任何外部应用(通过SNMP、XML API)进行监控？
5)如果是，应用轮询FI以获取数据的频率如何？ 这些应用程序会定期轮询哪些信息？（例如SNMP查询）
6)是否有流量风暴流向FI管理端口？
7)此比例设置是否为？（机箱、刀片、虚拟接口数）
主动监控FI的建议
1)配置UCSM以将日志导出到系统日志服务器
2)定期从本地管理收集“ show processes ”的输出，以监控CPU和内存的趋势
进程的使用。如果FI已由外部应用监控，则不需要此设置。
相关信息
Cisco UCS Manager配置指南
反馈