Erforderliche Protokolle und Informationen bei einem QPS-Systemausfall

Einführung

In diesem Dokument werden die Schritte beschrieben, die ausgeführt werden müssen, um Informationen zu erfassen, wenn ein Fehler oder ein Absturz eines QPS-Systems (Quantum Policy Suite) auftritt. Wenn die Hardware-, Software- und virtuellen Systemanforderungen erfüllt werden, ist ein Absturz des QPS unwahrscheinlich.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• QPS Version 5.5 und höher

Hinweis: Einige Protokolle werden in QPS-Versionen, die älter als QPS Release 5.5 sind, nicht angezeigt.

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.

Erfassung von Informationen

Wenn ein QPS-Systemfehler auftritt, sammeln Sie folgende Informationen:

Diagnose- und Fehlerprotokolle

1. Melden Sie sich beim virtuellen System für Policy and Charging Rules Function (PCRF)-Client (z. B. pcrfclient01) an, und sammeln Sie Diagnoseinformationen (z. B. /opt/broadhop/installer/diag/diagnostics.sh).
2. Melden Sie sich beim virtuellen PCRF-Client-System an, und sammeln Sie Debugging-Informationen. Zu den Debug-Informationen gehören konsolidierte QNS-Protokolle, SVN-Repo und QNS-Konfigurationsdetails. Stellen Sie sicher, dass die konsolidierten Protokolle die Zeit des Systemausfalls abdecken und dass der Debugging-Level in der Datei "logback.xml" festgelegt ist. 
3. Erfassen Sie diese Ausgabe von Ihrem QPS (z. B. Ausführen von /opt/broadhop/installer/diag/zip_debug_info.sh und die Ausgabe wird in /var/tmp/debug_info<date>.zip gespeichert).

QPS-Lizenzinformationen

1. Melden Sie sich beim virtuellen PCRF-Client-System an, und sammeln Sie QPS-Lizenzinformationen. Ein QPS wird normalerweise für eine bestimmte Funktion lizenziert und unterstützt eine maximale Anzahl gleichzeitiger Sitzungen. Das QPS hat auch ein Ablaufdatum für diese Funktion.
2. Navigieren Sie zu diesem Verzeichnis: /etc/brehop/license und capture the output of the license (LIC) file. (z. B. Cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Systemstatistiken

1. Erfassen der Systemstatistiken (Beispiel: CPU, Arbeitsspeicher, Festplattenauslastung).
2. Melden Sie sich beim virtuellen PCRF-Client-System an, und sammeln Sie die Ausgabe. Beispiel: /opt/broadhop/control/top_qps.sh
3. Melden Sie sich bei dem virtuellen System an, das (z. B. pcrfclient0x, lb0x, qns0x) entspricht, und erfassen Sie diese Systemstatistiken:

   cat/proc/meminfo > Zugewiesene Speicherinformationen
   free -s 60 > Arbeitsspeicherstatistiken für jede Minute
   vmstat 1 > CPU-Status für jede Minute
   ps-aux | Kopf -10 > Top 10 Prozessdetails, die den Großteil der CPU-Auslastung ausmachen
   swapon -s > Nutzungsübersicht für den Austausch pro Gerät
   . las | sort -n -r | Head -n 10 > Top 10 Dateien/Verzeichnisse mit mehr Speicherplatz

4. Melden Sie sich bei der virtuellen Maschine sessionmgr an, und sammeln Sie die Ausgaben mongostat und mongotop, was helfen wird, zu beheben, ob das Problem mit der Datenbank zusammenhängt oder nicht.

Threadkonfiguration in Policy Builder

Melden Sie sich beim Policy Builder an, und navigieren Sie zu Reference Data > System-1 > Plugin Configurations > Threading Configuration. 

Die Anzahl der Threads kann bei TPS zwischen 40 und 50 liegen, aber weniger als 1.000. Die maximale Anzahl der Threads, die Sie konfigurieren können, beträgt 50. Wenn Sie die Anzahl der Threads erhöhen, wirkt sich dies auf die Systemleistung aus. 

Schwerwiegendes Fehlerprotokoll

Wenn ein Systemfehler auftritt, generiert das QPS ein schwerwiegendes Fehlerprotokoll, das den Status des Prozesses zum Zeitpunkt des schwerwiegenden Fehlers enthält. Schwerwiegende Fehler oder schwerwiegende Ausnahmefehler führen dazu, dass das Programm abbricht.

Das Fehlerprotokoll enthält folgende Informationen:

• Die Betriebsausnahme oder das Signal, die den schwerwiegenden Fehler verursacht hat
• Version- und Konfigurationsinformationen
• Details zum Thread, der den schwerwiegenden Fehler und die Stapelüberwachung des Threads ausgelöst hat
• Die Liste der ausgeführten Threads und deren Status
• Zusammenfassende Informationen zum Heap
• Liste der geladenen systemeigenen Bibliotheken
• Befehlszeilenargumente
• Umgebungsvariablen
• Details zum Betriebssystem (OS) und zur zentralen Verarbeitungseinheit (CPU)

Der Standard-Protokolldateiname folgt folgendem Format: hs_err_pid<pid>.log und wird im Arbeitsverzeichnis generiert, in dem die entsprechenden Java-Prozesse gestartet wurden. Beispiel: das Arbeitsverzeichnis des Benutzers, als der Benutzer den QNS-Prozess gestartet hat.

Wenn Sie das Arbeitsverzeichnis nicht kennen, suchen Sie das System nach der Datei mit dem Namen hs_err_pid*.log und überprüfen Sie die Datei für eine Zeit, die dem Zeitpunkt entspricht, an dem der Fehler aufgetreten ist.

Gehen Sie wie folgt vor, um den Speicherort für den schwerwiegenden Fehler anzugeben:

1. Melden Sie sich beim virtuellen System pcrfclient01 an.
2. Öffnen Sie jvm.conf (z. B.vi /etc/broadhop/pcrf/jvm.conf).
3. Fügen Sie die Option -XX:ErrorFile=<directory>/<file-name>%p.log der Liste hinzu, und stellen Sie sicher, dass der angegebene Verzeichnispfad vorhanden ist und dass der Benutzer QNS volle Berechtigung für dieses Verzeichnis besitzt. Beispiel: -X:ErrorFile=/home/qns/fatal_error%p.log
4. Der Befehl "syncconfig.sh" kann viele Probleme verursachen, wenn die conf-Dateien in pcrfclient01:/etc/grohop nicht mit den conf-Dateien in /etc/brehop auf den VMs synchronisiert werden, die den QNS-Dienst ausführen. Die syncconfig.sh nimmt die pcrfclient01:/etc/Broadhop conf-Dateien und überschreibt die conf-Dateien in /etc/brehop auf den VMs, die QNS ausführen. 

   Warnung: Der Befehl synconfig.sh übernimmt die Dateien pcrfclient01:/etc/Broadhop conf und überschreibt alle conf Dateien in /etc/Broadhop auf den virtuellen Systemen, auf denen der QNS-Dienst ausgeführt wird (z. B. iomgr01, iomgr02, qns01, qns02 usw. )

5. Starten Sie die QNS-Anwendung neu, und geben Sie den Befehl restartall.sh ein.