Registros e información requeridos en caso de falla del sistema QPS

Introducción

Este documento describe los pasos que se deben completar para capturar información cuando se produce una falla o una caída del sistema de Quantum Policy Suite (QPS). Si se cumplen los requisitos de hardware, software y máquina virtual, es poco probable que se produzca un fallo en QPS.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• QPS versión 5.5 y posteriores.

Nota: Ciertos registros no aparecerán en las versiones de QPS anteriores a la versión 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.

Información de captura

Si se produce un error en el sistema QPS, recopile esta información:

Registros de diagnóstico y depuración

1. Inicie sesión en la máquina virtual cliente de la función de reglas de cobro y políticas (PCRF) (por ejemplo, pcrfclient01) y recopile información de diagnóstico (por ejemplo, /opt/broadhop/installer/diag/diagnostics.sh).
2. Inicie sesión en la máquina virtual del cliente PCRF y recopile información de depuración. La información de depuración incluye el registro QNS consolidado, la repo de svn y los detalles de configuración de QNS. Asegúrese de que los registros consolidados cubran la hora de la falla del sistema y que el nivel de depuración esté configurado en el archivo logback.xml. 
3. Recopile este resultado de su QPS (por ejemplo, Ejecutar /opt/broadhop/installer/diag/zip_debug_info.sh y el resultado se almacena en /var/tmp/debug_info<fecha>.zip).

Información de licencia de QPS

1. Inicie sesión en la máquina virtual del cliente PCRF y recopile la información de la licencia QPS. Un QPS suele tener una licencia para una función específica y hay un número máximo de sesiones simultáneas que soporta. El QPS también tiene una fecha de vencimiento para esta función.
2. Vaya a este directorio: /etc/broadcast/license y capture el resultado del archivo de licencia (.lic). (por ejemplo, cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Estadísticas del sistema

1. Capture las estadísticas del sistema (Ejemplo: CPU, memoria, utilización del disco).
2. Inicie sesión en la máquina virtual del cliente PCRF y recopile el resultado. Ejemplo: /opt/broadhop/control/top_qps.sh
3. Inicie sesión en la máquina virtual que corresponda (por ejemplo, pcrfclient0x, lb0x, qns0x) y capture estas estadísticas del sistema:

   cat /proc/meminfo > Información de memoria asignada
   free -s 60 > Estadísticas de memoria para cada minuto
   vmstat 1 > estado de CPU por cada minuto
   ps -aux | head -10 > Los 10 detalles principales del proceso que consumen la mayor parte de la utilización de la CPU
   swapon -s > swap usage summary por dispositivo
   . du -a | sort -n -r | head -n 10 > Los 10 archivos/directorios principales que consumen más espacio

4. Inicie sesión en la máquina virtual sessionmgr y recopile los resultados mongostat y mongotop, lo que ayudará a resolver el problema si el problema está relacionado con la base de datos o no.

Configuración de subprocesos en el creador de políticas

Inicie sesión en el generador de políticas y navegue hasta Datos de referencia > Sistema-1 > Configuraciones de complementos > Configuración de subprocesos. 

El número de subprocesos puede oscilar entre 40 y 50 para TPS, pero es inferior a 1000. El número máximo de subprocesos que puede configurar es 50. Si aumenta el número de subprocesos, esto afecta al rendimiento del sistema. 

Registro de errores fatales

Cuando ocurre una falla del sistema, el QPS genera un registro de errores fatal, que contiene el estado del proceso en el momento en que ocurrió el error fatal. Los errores de excepción mortales o los errores de excepción mortales hacen que el programa se aborte.

El registro de errores fatales incluye esta información:

• La excepción de funcionamiento o la señal que provocó el error fatal
• Información de configuración y versión
• Detalles del subproceso que provocaron el error fatal y el seguimiento de pila del subproceso
• La lista de subprocesos en ejecución y su estado
• Información resumida sobre el montón
• La lista de bibliotecas nativas cargadas
• Argumentos de la línea de comandos
• Variables de entorno
• Detalles sobre el sistema operativo (SO) y la unidad de procesamiento central (CPU)

El nombre del archivo de registro predeterminado sigue este formato: hs_err_pid<pid>.log y se genera en el directorio de trabajo donde se iniciaron los procesos Java correspondientes. Ejemplo: el directorio de trabajo del usuario cuando el usuario inició el proceso QNS.

Si no conoce el directorio de trabajo, busque en el sistema el archivo con el nombre hs_err_pid*.log y examine el archivo durante un tiempo que coincida con el momento en que se produjo el error.

Complete estos pasos para especificar la ubicación del error fatal:

1. Inicie sesión en la máquina virtual pcrfclient01
2. Abra jvm.conf (por ejemplo,vi /etc/broadhop/pcrf/jvm.conf).
3. Agregue la opción: -XX:ErrorFile=<directory>/<file-name>%p.log a la lista y asegúrese de que la ruta de acceso del directorio especificada exista y que el QNS del usuario tenga permiso completo sobre ese directorio. Ejemplo: -X:ErrorFile=/home/qns/fatal_error%p.log
4. El comando "syncconfig.sh" puede causar muchos problemas si los archivos conf en pcrfclient01:/etc/bandhop no están sincronizados con los archivos conf en /etc/broadcast en las VM que ejecutan el servicio QNS. El archivo syncconfig.sh tomará los archivos pcrfclient01:/etc/bandhop conf y, sobre, escribirá los archivos conf en /etc/bandhop en las VM que ejecutan el QNS. 

   Advertencia: El comando synconfig.sh tomará los archivos pcrfclient01:/etc/andhop conf y sobrescribirá todos los archivos conf en /etc/andhop en las máquinas virtuales que ejecutan el servicio QNS (por ejemplo, iomgr01, iomgr02, qns01, qns02, etc.).

5. Reinicie la aplicación QNS e ingrese el comando restartall.sh