簡介
本文檔提供調查統一計算系統交換矩陣互聯(FI)崩潰或意外重新啟動故障的步驟。
在高級別上，以下問題可能導致FI重新啟動
- 核心空間進程崩潰（也稱為核心宕機）
- 核心記憶體不足（記憶體不足 — OOM正在終止使用者進程以回收記憶體）
- 使用者空間進程崩潰(例如- netstack、fcoe_mgr、callhome等)
- FI韌體問題(罕見場景，示例 — CSCuq46105)或硬體元件故障（如用於儲存的SSD）
必要條件
需求
思科建議您瞭解以下主題：
思科整合運算系統(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配置指南
意見