Journaux et informations requis en cas de défaillance du système QPS

Introduction

Ce document décrit les étapes à suivre pour capturer des informations en cas de panne ou de panne système de Quantum Policy Suite (QPS). Si les exigences matérielles, logicielles et de machines virtuelles sont satisfaites, il est peu probable que le QPS se plante.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• QPS version 5.5 et ultérieure.

Note: Certains journaux n'apparaîtront pas dans les versions de QPS antérieures à la version 5.5 de QPS.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Capturer les informations

En cas de défaillance du système QPS, collectez ces informations :

Diagnostics et journaux de débogage

1. Connectez-vous à la machine virtuelle du client PCRF (Policy and Charging Rules Function) (par exemple, pcrfclient01) et collectez des informations de diagnostic (par exemple, /opt/broadhop/installer/diag/diagnostics.sh).
2. Connectez-vous à la machine virtuelle du client PCRF et collectez les informations de débogage. Les informations de débogage incluent le journal QNS consolidé, le repo svn et les détails de configuration QNS. Assurez-vous que les journaux consolidés couvrent l'heure de la défaillance du système et que le niveau de débogage est défini dans le fichier logback.xml. 
3. Collectez cette sortie à partir de votre QPS (par exemple, Exécutez /opt/broadhop/installer/diag/zip_debug_info.sh et la sortie est stockée dans /var/tmp/debug_info<date>.zip).

Informations de licence QPS

1. Connectez-vous à la machine virtuelle du client PCRF et collectez les informations de licence QPS. Un QPS est généralement autorisé pour une fonction spécifique et il y a un nombre maximal de sessions simultanées qu'il prend en charge. Le QPS a également une date d'expiration pour cette fonctionnalité.
2. Accédez à ce répertoire : /etc/broadhop/license et capture le résultat du fichier de licence (.lic). (par exemple, cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Statistiques système

1. Capturez les statistiques système (Exemple : CPU, mémoire, utilisation du disque).
2. Connectez-vous à la machine virtuelle du client PCRF et collectez le résultat. Exemple : /opt/broadhop/control/top_qps.sh
3. Connectez-vous à la machine virtuelle qui correspond (par exemple, pcrfclient0x, lb0x, qns0x) et capturez les statistiques système suivantes :

   cat /proc/meminfo > Informations de mémoire allouée
   free -s 60 > Statistiques de mémoire pour chaque minute
   vmstat 1 > état du processeur pour chaque minute
   ps-aux | head -10 > Top 10 des détails de processus qui consomment la plus grande partie de l'utilisation du CPU
   swapon -s > résumé de l'utilisation des swap par périphérique
   . du -a | tri -n -r | head -n 10 > Top 10 des fichiers / répertoires consommant plus d'espace

4. Connectez-vous à la machine virtuelle sessionmgr et collectez les sorties mongostat et mongotop, ce qui vous aidera à déterminer si le problème est lié à la base de données ou non.

Configuration du thread dans Policy Builder

Connectez-vous au générateur de stratégies et accédez à Référence Data > System-1 > Plugin Configurations > Threading Configuration. 

Le nombre de threads peut être compris entre 40 et 50 pour TPS, mais il est inférieur à 1 000. Le nombre maximal de threads que vous pouvez configurer est de 50. Si vous augmentez le nombre de threads, cela affecte les performances du système. 

Journal des erreurs fatales

Lorsqu'une panne système se produit, le QPS génère un journal des erreurs fatales, qui contient l'état du processus au moment où l'erreur fatale s'est produite. Une erreur fatale ou des erreurs d'exception fatales provoquent l'abandon du programme.

Le journal des erreurs fatales inclut ces informations :

• Exception ou signal de fonctionnement ayant provoqué l'erreur fatale
• Informations de version et de configuration
• Détails sur le thread qui a provoqué l'erreur fatale et la trace de la pile du thread
• La liste des threads en cours d'exécution et leur état
• Informations récapitulatives sur le tas
• Liste des bibliothèques natives chargée
• Arguments de ligne de commande
• Variables d'environnement
• Informations détaillées sur le système d'exploitation (SE) et l'unité centrale de traitement (UC)

Le nom du fichier journal par défaut suit ce format : hs_err_pid<pid>.log et est généré dans le répertoire de travail où les processus Java correspondants ont démarré. Exemple : le répertoire de travail de l'utilisateur au démarrage du processus QNS.

Si vous ne connaissez pas le répertoire de travail, recherchez dans le système le fichier portant le nom hs_err_pid*.log et examinez le fichier pour une durée qui correspond lorsque l'erreur s'est produite.

Complétez ces étapes afin de spécifier l'emplacement de l'erreur fatale :

1. Connectez-vous à la machine virtuelle pcrfclient01
2. Ouvrez jvm.conf (par exemple, vi /etc/broadhop/pcrf/jvm.conf).
3. Ajoutez l'option : -XX : ErrorFile=<répertoire>/<nom-fichier>%p.log à la liste et assurez-vous que le chemin d'accès au répertoire spécifié existe et que l'utilisateur QNS dispose d'une autorisation complète sur ce répertoire. Exemple : -X : ErrorFile=/home/qns/fatal_error%p.log
4. La commande “ syncconfig.sh ” peut causer beaucoup de problèmes si les fichiers conf dans pcrfclient01:/etc/broadhop ne sont pas synchronisés avec les fichiers conf dans /etc/broadhop sur les machines virtuelles exécutant le service QNS. Le fichier syncconfig.sh prendra les fichiers de conf pcrfclient01:/etc/broadhop et remplacera les fichiers conf dans /etc/broadhop sur les machines virtuelles exécutant le QNS. 

   Avertissement : La commande synconfig.sh prend les fichiers conf pcrfclient01:/etc/broadhop et remplace tous les fichiers conf dans /etc/broadhop sur les machines virtuelles exécutant le service QNS (iomgr01, iomgr02, qns01, qns02, etc. .)

5. Redémarrez l'application QNS et entrez la commande restartall.sh