In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden Warnungen des Cisco Real-Time Monitoring Tool (RTMT) behandelt und die Fehlerbehebung für einige häufig verwendete Warnungen erläutert.
Cisco empfiehlt, über Kenntnisse der Cisco Call Manager-Webadministration zu verfügen.
Die Informationen in diesem Dokument basieren auf Cisco CallManager Server 11.0.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Das RTMT, das als clientseitige Anwendung ausgeführt wird, verwendet HTTPS und TCP, um die Systemleistung, den Gerätestatus, die Geräteerkennung, Computer Telefony Integration (CTI)-Anwendungen und Voice Messaging-Ports zu überwachen. RTMT kann verwendet werden, um Warnungen für den von ihm überwachten Cluster zu konfigurieren.
Das System generiert Warnmeldungen, um den Administrator zu benachrichtigen, wenn eine vordefinierte Bedingung erfüllt ist, z. B. wenn ein aktivierter Dienst deaktiviert wird. Das System kann Warnungen als E-Mail/E-Mail senden.
RTMT unterstützt das Definieren, Festlegen und Anzeigen von Warnmeldungen und enthält vorkonfigurierte und benutzerdefinierte Warnungen. Obwohl Sie Konfigurationsaufgaben für beide Typen durchführen können, können Sie vorkonfigurierte Warnungen nicht löschen.
Das Unified RTMT zeigt sowohl vorkonfigurierte Warnungen als auch benutzerdefinierte Warnungen in Alert Central an, wie im Bild gezeigt.
Sie können auch auf Alert Central zugreifen, indem Sie im Systembereich in der Hierarchiestruktur auf das Symbol Alert Central klicken.
Das Unified RTMT organisiert die Warnungen unter den entsprechenden Registerkarten: System, CallManager, Cisco Unity Connection und Custom.
Sie können vorkonfigurierte und benutzerdefinierte Warnungen in Alert Central aktivieren oder deaktivieren. Sie können jedoch vorkonfigurierte Warnungen nicht löschen.
Warnungen in RTMT werden wie folgt klassifiziert:
Diese Liste enthält vorkonfigurierte Systemwarnungen:
Authentifizierung fehlgeschlagen
CiscoDRFleise
CoreDumpFileFound
CPU-Pegging
CriticalAuditEventGenerated
CriticalServiceDown
Hardware-Fehler
LogFileSearchStringFound
LogPartitionHighWaterMarkExceeded
LogPartitionLowWaterMarkExceeded
LowActivePartitionAvailableDiskSpace
Gering verfügbarer virtueller Arbeitsspeicher
LowInactivePartitionAvailableDiskSpace
LowSwapPartitionAvailableDiskSpace
ServerDown (gilt für Unified Communications Manager (CUCM)-Cluster)
SparePartitionHighWaterMarkExceeded
SparePartitionLowWaterMarkExceeded
SyslogSeverityMatchFound
SyslogStringMatchFound
SystemVersionMismatch
TotalProcessesAndThreadsOverceededThreshold
Diese Liste enthält die vorkonfigurierten CallManager-Warnungen.
Linux-Server neigen dazu, die Auslastung des virtuellen Speichers über einen bestimmten Zeitraum zu "unklar" zu machen, und es hat sich gezeigt, dass sich diese Warnungen häufen und daher auch diese Warnmeldungen.
Linux arbeitet etwas anders als ein Betriebssystem.
Nachdem der Speicher einem Prozess zugewiesen wurde, wird er vom Prozessor nur dann zurückgenommen, wenn ein anderer Prozess mehr Speicher als den verfügbaren Speicher anfordert.
Dies verursacht einen hohen virtuellen Speicher.
Ein Antrag auf Erhöhung des Schwellenwerts für den Alarm in den höheren Versionen des Call Managers ist im Fehler dokumentiert: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq75767/?reffering_site=dumpcr
Bei Swap-Partitionen zeigt diese Warnung an, dass die Swap-Partition nicht über genügend Speicherplatz verfügt und vom System stark genutzt wird. Die Swap-Partition wird normalerweise verwendet, um die physische RAM-Kapazität bei Bedarf zu erweitern. Wenn der RAM ausreichend ist, sollte unter normalen Bedingungen der Austausch nicht zu viel verwendet werden.
Diese können auch RTMT-Warnungen auslösen, die durch das Erstellen von Temp-Dateien verursacht werden. Es wird empfohlen, den Server neu zu starten, um unnötige Temp-Dateien zu löschen.
Beim Ausführen des Anzeigestatus auf der CLI eines CUCM-Servers wird ein Wert angezeigt, der den besetzten und freien Prozentsatz der Protokollierungspartition im CUCM-Festplattenspeicher angibt. Diese Werte werden auch als gemeinsame Partition bezeichnet und geben den Speicherplatz an, der von den Protokollen/Ablaufverfolgungen und den CDR-Dateien im Server belegt ist. Diese Dateien sind zwar harmlos, können aber aufgrund des zeitlichen Speichermangels Probleme bei der Installation/Aktualisierung verursachen. Diese Warnmeldungen dienen als Warnung an den Administrator, die Protokolle zu löschen, die im Laufe der Zeit möglicherweise im Cluster/Server angesammelt wurden.
LogPartitionLowWaterMarkExceeded: Diese Warnung wird generiert, wenn der gefüllte Speicherplatz die für die Warnung konfigurierten Schwellenwerte erreicht. Diese Warnung dient als Vorabkontrollanzeige für die Festplattennutzung.
LogPartitionHighWaterMarkExceeded: Diese Warnung wird generiert, wenn der gefüllte Speicherplatz die für die Warnung konfigurierten Schwellenwerte erreicht. Sobald die Warnmeldung generiert wurde, löscht der Server automatisch die ältesten Protokolle, um den Speicherplatz auf Werte herabzusetzen, die dem HighWaterMark-Schwellenwert entsprechen.
Als Best Practice sollten die Protokolle manuell gelöscht werden, sobald die LogPartitionLowWaterMarkExceeded-Warnung empfangen wird.
Dies sind die folgenden Schritte:
Schritt 1: Starten Sie RTMT.
Schritt 2: Wählen Sie Alert Central aus, und führen Sie dann die folgenden Aufgaben aus:
Wählen Sie LogPartitionHighWaterMarkExceeded aus, notieren Sie den Wert und ändern Sie den Schwellenwert auf 60 %.
Wählen Sie LogPartitionLowWaterMarkExceeded aus, notieren Sie den Wert und ändern Sie den Schwellenwert auf 50 %.
Das Polling findet alle 5 Minuten statt. Warten Sie also 5-10 Minuten, und überprüfen Sie dann, ob der erforderliche Speicherplatz verfügbar ist. Wenn Sie mehr Speicherplatz in der gemeinsamen Partition freigeben möchten, ändern Sie die LogPartitionHighWaterMarkExceeded-Threadwerte und die LogPartitionLowWaterMarkExceeded-Werte wieder in niedrigere Werte (z. B. 30 % und 20 %).
Geben Sie ihm 15 bis 20 Minuten, um den Speicherplatz in der gemeinsamen Partition freizugeben. Sie können die Verringerung der Festplattenauslastung mit dem Befehl show status from CLI überwachen.
Das würde die gemeinsame Teilung zum Erliegen bringen.
Der CpuPegging-Alarm überwacht die CPU-Auslastung anhand des konfigurierten Grenzwerts.
Wenn die CPU-Pegging-Warnung empfangen wird, kann der Prozess, der die höchste CPU belegt, über die Systemablage links, d. h. Prozess, ausgeführt werden.
Aus der CLI des betreffenden Servers ergeben sich daraus einige Einblicke.
Es wird empfohlen zu beobachten, ob der CPU-Spitzenwert zu einem bestimmten Zeitpunkt oder zufällig auftritt. Wenn es willkürlich vorkommt, werden die erforderlichen detaillierten CUCM-Traces sowie RisDC-Parmon-Protokolle ausgeführt, um zu überprüfen, was die Spitze in der CPU auslöst. Wenn die Warnungen zu einer bestimmten Tageszeit erfolgen, könnte dies auf geplante Aktivitäten wie Disaster Recovery System (DRS) Backup, CDR Load usw. zurückzuführen sein.
Darüber hinaus werden anhand von Informationen darüber, welcher Prozess die meisten CPUs belegt, spezifische Protokolle für weitere Untersuchungen herangezogen. Beispiel: Wenn der Schuldige Tomcat ist, werden die Tomcat-bezogenen Protokolle benötigt.
In diesem Abschnitt überprüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Wenn die Warnungen nicht gelöscht werden, nachdem Sie die hier vorgeschlagenen Problemumgehungen befolgt haben oder die Warnungen unmittelbare Auswirkungen auf den Service zu haben scheinen, wenden Sie sich an das Cisco TAC mit den erforderlichen Details über die Version des Anrufmanagers, die Anzahl der Knoten im Cluster, die Zeit und die Dauer der Warnung sowie die erforderliche Prozessverengung bei CPU-Pegging.
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.