Sans fil : Cisco Policy Suite for BNG

Logs et informations requises en cas d'une défaillance du système QPS

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit les étapes qui doivent être terminées afin de saisir les informations quand une défaillance du système ou un crash de la suite de stratégie de Quantum (QPS) se produit. Si le matériel, le logiciel, et les exigences de virtual machine sont répondus, il est peu probable que le QPS tombera en panne.

Contribué par Aravindhan Balasubramian, Pina élégant, et Vinodkumar Tiwari, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

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

Composants utilisés

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

  • Version 5.5 et ultérieures QPS.

Remarque: Certains logs n'apparaîtront pas dans des versions QPS plus anciennes que la version 5.5 QPS.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Les informations de capture

Si une défaillance du système QPS se produit, collectez ces informations :

Diagnostics et logs de debug

  1. La procédure de connexion à la stratégie et au remplissage ordonne le virtual machine de client de la fonction (PCRF) (par exemplepcrfclient01) et collecte les informations de diagnostic (par exemple, /opt/broadhop/installer/diag/diagnostics.sh).
  2. Ouvrez une session au virtual machine de client PCRF et collectez mettent au point les informations. Les informations de debug des détails incluent le log consolidé QNS, le repo de svn, et QNS configuration. Assurez-vous que les logs consolidés couvrent la période de la défaillance du système et que le niveau de débogage est placé dans le fichier logback.xml. 
  3. Collectez cette sortie de votre QPS (par exemple, exécutez /opt/broadhop/installer/diag/zip_debug_info.sh et la sortie est enregistrée dans /var/tmp/debug_info <date>.zip).
  4. Ouvrez une session à l'exemple de virtual machine QPS où la défaillance du système s'est produite. (par exemple, pcrfclient0x, lb0x, qns0x, portal0x). Collectez les logs QNS et assurez-vous que le log QNS inclut la période de la défaillance du système. (par exemple, cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Données de licence QPS

  1. Ouvrez une session au virtual machine de client PCRF et collectez les données de licence QPS. Un QPS est habituellement autorisé pour une caractéristique spécifique et il y a un nombre maximal de sessions simultanées qu'il le prend en charge. Le QPS a également une date d'expiration pour cette caractéristique.
  2. Naviguez vers ce répertoire : /etc/broadhop/license et saisissent la sortie du fichier du permis (.lic). (par exemple, cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Statistiques de système

  1. Capturez les statistiques de système (exemple : CPU, mémoire, utilisation de disque).
  2. Ouvrez une session au virtual machine de client PCRF et collectez la sortie. Exemple : /opt/broadhop/control/top_qps.sh
  3. Ouvrez une session au virtual machine qui correspond (par exemple, pcrfclient0x, lb0x, qns0x) et capturez ces les statistiques de système :

    cat /proc/meminfo > les informations allouées de mémoire
    libérez - s 60 > des statistiques de mémoire pour la minute chaque
    vmstat 1 > état CPU pour la minute chaque
    picoseconde - aux. | dirigez -10 > des détails du processus du principal 10 qui consomme la majeure partie d'utilisation du processeur
    swapon - s > résumé d'utilisation d'échange par périphérique
    . du - a | tri - n - r | tête - n 10 > fichiers/répertoires du principal 10 consommant plus l'espace

  4. Ouvrez une session au virtual machine de sessionmgr et collectez le mongostat et le mongotop de sorties, qui aideront afin de dépanner, que la question soit liée à la base de données ou pas.

Configuration de thread dans le builder de stratégie

Ouvrez une session au builder de stratégie et naviguez vers des données de référence > System-1 > des configurations embrochables > en filetant la configuration. 

Le nombre de thread pourrait s'étendre de 40 à 50 pour TPS, mais est moins de 1,000. Le nombre maximal de thread que vous pouvez configurer est 50. Si vous augmentez le nombre de thread, ceci affecte la performance du système. 

Log d'erreur fatale

Quand une défaillance du système se produit, le QPS génère un log d'erreur fatale, qui contient l'état du processus alors que l'erreur fatale s'est produit. L'erreur fatale ou les erreurs mortelles d'exception font abandonner le programme.

Le log d'erreur fatale inclut ces informations :

  • L'exception de fonctionnement ou signalent que provoqué l'erreur fatale
  • Version et informations de configuration
  • Détails dans le thread qui a provoqué l'erreur fatale et le suivi de pile du thread
  • La liste de thread courants et de leur état
  • Informations récapitulatives sur le segment de mémoire
  • La liste de bibliothèques indigènes chargées
  • Arguments de la ligne de commande
  • Variables d'environnement
  • Détails au sujet du système d'exploitation (SYSTÈME D'EXPLOITATION) et de l'unité centrale (CPU)

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

Si vous ne connaissez pas le répertoire de travail, recherchez le système pour le fichier avec le le nom hs_err_pid*.log et l'examinez le fichier pendant un certain temps ce s'assortit quand l'erreur s'est produite.

Terminez-vous ces étapes afin de spécifier l'emplacement pour l'erreur fatale :

  1. Procédure de connexion au virtual machine pcrfclient01
  2. Ouvrez jvm.conf (par exemple, vi /etc/broadhop/pcrf/jvm.conf).
  3. Ajoutez l'option : - XX : ErrorFile=<directory>/<file-name>%p.log à la liste et s'assurent que le chemin du répertoire spécifié existe et que l'utilisateur QNS a la pleine autorisation au-dessus de ce répertoire.  Exemple :  - X : ErrorFile=/home/qns/fatal_error%p.log
  4. La commande de syncconfig.sh peut poser beaucoup de problèmes si les fichiers de conf dans pcrfclient01:/etc/broadhop ne sont pas dans la synchronisation avec les fichiers de conf dans /etc/broadhop sur les VMs exécutant le service QNS. syncconfig.sh prendra les fichiers de conf pcrfclient01:/etc/broadhop et écrira plus de les fichiers de conf dans /etc/broadhop sur les VMs exécutant le QNS. 

    Avertissement : La commande synconfig.sh prendra les fichiers de conf pcrfclient01:/etc/broadhop et remplacera tous les fichiers de conf dans /etc/broadhop sur les virtual machine exécutant le service QNS (exemple d'ifor, iomgr01, iomgr02, qns01, qns02, etc.)

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

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 117999