目錄

簡介

必要條件

需求

所需的日誌檔案

分析日誌以獲取初始線索

收集有關UCS設定的資訊

主動監控FI的建議

相關資訊

簡介

本文檔提供調查統一計算系統交換矩陣互聯(FI)崩潰或意外重新啟動故障的步驟。

在高級別上，以下問題可能導致FI重新啟動

- 核心空間進程崩潰（也稱為核心宕機）

- 核心記憶體不足（記憶體不足 — OOM正在終止使用者進程以回收記憶體）

- 使用者空間進程崩潰(例如- netstack、fcoe_mgr、callhome等)

- FI韌體問題(罕見場景，示例 — CSCuq46105)或硬體元件故障（如用於儲存的SSD）

必要條件

需求

思科建議您瞭解以下主題：

思科整合運算系統(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配置指南