目录

简介

先决条件

要求

所需的日志文件

分析日志以查找初始线索

收集有关UCS设置的信息

主动监控FI的建议

相关信息

简介

本文档提供了调查统一计算系统交换矩阵互联(FI)崩溃或意外重启故障的步骤。

在高级别上，以下问题可能导致FI重新启动

- 内核空间进程崩溃（又称内核死机）

- 内核内存不足（内存不足 — OOM终止用户进程以回收内存）

- 用户空间进程崩溃(例如- netstack、fcoe_mgr、callhome等

- FI固件问题(罕见场景，示例 — CSCuq46105)或硬件组件故障（如用于存储的SSD）

先决条件

要求

Cisco 建议您了解以下主题：

思科统一计算系统(UCS)管理器

思科统一计算系统(UCS)管理器命令行界面(CLI)

所需的日志文件

当FI意外重新启动时，收集以下日志并将其上传到TAC服务请求。

- UCSM技术支持日志套件

- 检查是否在重新启动事件期间创建了核心转储文件。

您可以通过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配置指南