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 la información cuando ocurre una falla del sistema o una caída de la habitación de la directiva de Quantum (QPS). Si se cumplen el soporte físico, el software, y los requisitos de la máquina virtual, es inverosímil que el QPS causará un crash.

Prerrequisitos

Requisitos

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.

• Versión 5.5 QPS y posterior.

Nota: Ciertos registros no aparecerán en las versiones QPS más viejas que la versión 5.5 QPS.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Capture la información

Si sucede una falla del sistema QPS, recoja esta información:

Diagnósticos y registros del debug

1. El login a la directiva y a la carga gobierna la máquina virtual del cliente de la función (PCRF) (por ejemplo, pcrfclient01) y recoge la información de diagnóstico (por ejemplo, /opt/broadhop/installer/diag/diagnostics.sh).
2. Inicie sesión a la máquina virtual del cliente PCRF y recoja la información del debug. La información del debug incluye el registro consolidado QNS, el repo del svn, y a los detalles de la configuración QNS. Aseegurese que los registros consolidados cubren la época de la falla del sistema y que el nivel de debug está fijado en el archivo logback.xml. 
3. Recoja esta salida de su QPS (por ejemplo, ejecute /opt/broadhop/installer/diag/zip_debug_info.sh y la salida se salva en /var/tmp/debug_info <date>.zip).
4. Inicie sesión al caso de la máquina virtual QPS donde ocurrió la falla del sistema. (por ejemplo, pcrfclient0x, lb0x, qns0x, portal0x). Recoja los registros QNS y aseegurese que el registro QNS incluye la época de la falla del sistema. (por ejemplo, gato /etc/broadhop/license/QUANTUM201311210402429360.lic).

Información sobre la licencia QPS

1. Inicie sesión a la máquina virtual del cliente PCRF y recoja la información sobre la licencia QPS. Un QPS se autoriza generalmente para una característica específica y hay un número máximo de sesiones concurrentes que apoya. El QPS también tiene una fecha de vencimiento para esta característica.
2. Navegue a este directorio: /etc/broadhop/license y captura la salida del archivo de la licencia (.lic). (por ejemplo, gato /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 a la máquina virtual del cliente PCRF y recoja la salida. Ejemplo: /opt/broadhop/control/top_qps.sh
3. Inicie sesión a la máquina virtual que corresponde (por ejemplo, pcrfclient0x, lb0x, qns0x) y capture este las estadísticas del sistema:

   gato /proc/meminfo > Información de la memoria afectada un aparato
   libere - s 60 > las estadísticas de la memoria para cada minuto
   vmstat 1 > estatus CPU para cada minuto
   picosegundo - aux. | pista -10 > detalles de proceso del top 10 que consume la mayor parte de la utilización de la CPU
   swapon - s > resumen de uso del intercambio por el dispositivo
   . du - a | clase - n - r | pista - n 10 > archivos/directorios del top 10 que consumen más espacio

4. Inicie sesión a la máquina virtual del sessionmgr y recoja el mongostat y el mongotop de las salidas, que ayudarán para resolver problemas si el problema está relacionado con la base de datos o no.

Rosque la configuración en el constructor de la directiva

Inicie sesión al constructor de la directiva y navegue a los datos de referencia > a System-1 > las configuraciones plugs-in > roscando la configuración. 

El número de hilos pudo extenderse a partir del 40 a 50 para los TP, pero es menos de 1,000. El número máximo de hilos que usted puede configurar es 50. Si usted aumenta el número de hilos, esto afecta el rendimiento del sistema. 

Registro del error fatal

Cuando ocurre una falla del sistema, el QPS genera un registro del error fatal, que contiene el estado del proceso que ocurrió en ese entonces el error fatal. El error fatal o los errores de excepción fatales hace el programa abortar.

El registro del error fatal incluye esta información:

• La excepción de funcionamiento o señala que provocado el error fatal
• Versión y información de la configuración
• Detalles en el hilo que provocó el error fatal y el seguimiento de pila del hilo
• La lista de hilos que se ejecutan y de su estado
• Información de resumen sobre el montón
• La lista de bibliotecas nativas cargadas
• Argumentos de la línea de comando
• Variables de entorno
• Detalles sobre el operating system (OS) y la Unidad de procesamiento central (CPU)

El nombre del archivo predeterminado del registro sigue este formato: hs_err_pid<pid>.log y se genera en el directorio en funcionamiento donde los procesos correspondientes de las Javas comenzaron. Ejemplo: el directorio en funcionamiento del usuario cuando el usuario comenzó el proceso QNS.

Si usted no conoce el directorio en funcionamiento, busca el sistema para el archivo con el nombre hs_err_pid*.log y examina el archivo por una época que haga juego cuando ocurrió el error.

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

1. Inicie sesión a 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 se aseeguran que existe la trayectoria de directorio especificado y que el usuario QNS tiene permiso completo sobre ese directorio.  Ejemplo:  - X: ErrorFile=/home/qns/fatal_error%p.log
4. El comando de syncconfig.sh puede causar muchos problemas si los archivos del conf en pcrfclient01:/etc/broadhop no están en el synch con los archivos del conf en /etc/broadhop en los VM que funcionan con el servicio QNS. syncconfig.sh tomará los archivos del conf pcrfclient01:/etc/broadhop y encima escribirá los archivos del conf en /etc/broadhop en los VM que ejecutan el QNS. 

   Advertencia: El comando synconfig.sh tomará los archivos del conf pcrfclient01:/etc/broadhop y sobregrabará todos los archivos del conf en /etc/broadhop en las máquinas virtuales que funcionan con el servicio QNS (ejemplo del ifor, iomgr01, iomgr02, qns01, qns02, los etc.)

5. Recomience la aplicación QNS y ingrese el comando restartall.sh