Protokolle, die für das TAC erfasst werden, wenn beim CUCM Probleme mit hoher CPU oder Speicher festgestellt werden

Einführung

In diesem Dokument wird beschrieben, wie Sie die richtigen Protokolle für Probleme mit hoher CPU/Arbeitsspeicher auf dem CUCM sammeln und sie für das TAC freigeben. Durch die proaktive Erfassung und das Hochladen der Protokolle kann das Team des technischen Supports von Cisco mit der Analyse Ihrer Serviceanfrage schnell und effizient beginnen. 

Problem

Legt fest, welche Protokolle für das TAC erfasst werden sollen, wenn beim Öffnen eines Tickets beim CUCM eine hohe CPU-Auslastung oder Speichernutzung festgestellt wurde.

Zu erfassende Informationen

Grundlegende Informationen

• Was waren die Symptome des Problems? (z. B. : RTMT-Warnung? Leichte Reaktion von der GUI? Delayed Dialton)
• War zum Zeitpunkt des Problems eine Aktivität geplant? (z. B. LDAP Sync oder DRF Backup oder VM-Wartung auf der zugrunde liegenden HW)
• Wird auf dem betroffenen CUCM VM-Snapshot verwendet?
• Ein anderer Server im Cluster zeigt dasselbe Verhalten?
• Alle kürzlich vorgenommenen Änderungen am Cluster oder Netzwerk
• dass andere UC-Komponenten mit CUCM interagieren, z. B. Unity, UCCX, UCCE, Recording usw.

Die CLI-Ausgabe wird erfasst, wenn das Problem in Echtzeit auftritt.

• Anzeigeprozess mit dem meisten CPU/Arbeitsspeicher 
• Anzeige der Prozesslast  
• utils diagnose test 
• Anzeigestatus  

Vom RTMT (Real-Time Monitoring Tool) zu erfassende Protokolle

• Serviceprotokolle von Prozessen, die auf der Ausgabe von "show process load cpu/memory" basieren (d. h. wenn Sie CCM in der Ausgabe bemerken, dann CCM-Protokolle, wenn Tomcat bemerkt wird, dann Tomcat-Protokolle)
  
• Ereignisanzeige-Anwendungsprotokolle 
• Ereignisanzeige-Systemprotokolle 
• RIS perfmon

Für RCA eines Ereignisses, das bereits aufgetreten ist

Bitte sammeln Sie alle unten aufgeführten Spuren für einen bestimmten Zeitraum, bevor das Problem auftrat, bis das Problem behoben war.  Wenn wir beispielsweise anfingen, eine hohe CPU- oder Arbeitsspeicherauslastung um 16 Uhr zu beobachten.  und das Problem ging um 17.00 Uhr weg, dann sammelten wir Spuren für einen Zeitraum von 15.30 Uhr bis 17:30 Uhr Dieses Zeitintervall kann von einem Problem zum anderen variieren und hängt auch von der Einrichtung des Kunden ab.

• Detaillierte Cisco Call Manager-Ablaufverfolgung.
• Ereignisanzeige - Anwendungs- und Ereignisanzeige - Systemprotokolle.
• Cisco RISDC- und Perfmon-Protokolle
• Cisco AMC-Service.
• Cisco Tomcat- und Tomcat-Sicherheitsprotokolle.
• Ausgänge aus der CLI: 'show status', 'show process using-most cpu/memory', 'show process load'.
• Ausgabe von 'utils diagnose test'.

Zugehörige Informationen

1. Häufige CUCM-Probleme auf der UCS-Plattform: Core, hohe CPU - E/A, Hung State: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118702-technote-cucm-00.html
2. So sammeln Sie Traces für CUCM 9.x oder höher: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200787-How-to-Collect-Traces-for-CUCM-9-x-10-x.html