Registros e informações necessários em caso de falha do sistema QPS

Introduction

Este documento descreve as etapas que devem ser concluídas para capturar informações quando ocorre uma falha ou travamento do sistema do Quantum Policy Suite (QPS). Se os requisitos de hardware, software e máquina virtual forem atendidos, é improvável que o QPS falhe.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• QPS versão 5.5 e posterior.

Note: Determinados registros não aparecerão em versões do QPS anteriores ao QPS Versão 5.5.

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.

Capturar informações

Se ocorrer uma falha do sistema QPS, colete estas informações:

Logs de diagnóstico e depuração

1. Faça login na máquina virtual cliente Policy and Charging Rules Function (PCRF) (por exemplo, pcrfclient01) e colete informações de diagnóstico (por exemplo, /opt/broadhop/installer/diag/diagnostics.sh).
2. Faça login na máquina virtual do cliente PCRF e coletar informações de depuração. As informações de depuração incluem detalhes consolidados de log QNS, repo de svn e configuração de QNS. Certifique-se de que os registros consolidados cobrem o tempo da falha do sistema e que o nível de depuração está definido no arquivo logback.xml. 
3. Colete essa saída do QPS (por exemplo, Executar /opt/broadhop/installer/diag/zip_debug_info.sh e a saída é armazenada em /var/tmp/debug_info<date>.zip).

Informações de licença do QPS

1. Faça login na máquina virtual do cliente PCRF e colete informações de licença do QPS. Um QPS é normalmente licenciado para um recurso específico e há um número máximo de sessões simultâneas que ele suporta. O QPS também tem uma data de expiração para este recurso.
2. Navegue até este diretório: /etc/broadcast/license e capturar a saída do arquivo de licença (.lic). (por exemplo, cat /etc/broadhop/license/QUANTUM201311210402429360.lic).

Estatísticas do sistema

1. Capture as estatísticas do sistema (Exemplo: CPU, memória, utilização do disco).
2. Faça login na máquina virtual do cliente PCRF e colete a saída. Exemplo: /opt/broadhop/control/top_qps.sh
3. Faça login na máquina virtual que corresponde (por exemplo, pcrfclient0x, lb0x, qns0x) e capture estas estatísticas do sistema:

   cat /proc/meminfo > Informações de memória alocadas
   free -s 60 > Estatísticas de memória para cada minuto
   vmstat 1 > status da CPU para cada minuto
   ps -aux | head -10 > Os 10 principais detalhes do processo que consomem a maior parte da utilização da CPU
   swapon -s > resumo de uso de troca por dispositivo
   . du -a | sort -n -r | head -n 10 > 10 principais arquivos / diretórios que consomem mais espaço

4. Faça login na máquina virtual do sessionmgr e colete as saídas mongostat e mongotop, o que ajudará a solucionar problemas relacionados ao banco de dados ou não.

Configuração de Threads no Policy Builder

Faça login no criador de políticas e navegue para Dados de referência > Sistema-1 > Configurações de plug-in > Configuração de threading. 

O número de threads pode variar de 40 a 50 para TPS, mas é menor que 1.000. O número máximo de threads que você pode configurar é 50. Se você aumentar o número de threads, isso afeta o desempenho do sistema. 

Log de erros fatais

Quando ocorre uma falha do sistema, o QPS gera um log de erros fatal, que contém o estado do processo no momento em que o erro fatal ocorreu. Erros fatais ou de exceção fatal fazem com que o programa seja abortado.

O registro de erros fatais inclui estas informações:

• A exceção ou sinal operacional que provocou o erro fatal
• Informações de versão e configuração
• Detalhes do thread que provocou o erro fatal e o rastreamento da pilha do thread
• A lista de segmentos em execução e seu estado
• Informações resumidas sobre a pilha
• A lista de bibliotecas nativas carregadas
• Argumentos da linha de comando
• Variáveis de ambiente
• Detalhes sobre o sistema operacional (SO) e a unidade central de processamento (CPU)

O nome do arquivo de log padrão segue este formato: hs_err_pid<pid>.log e é gerado no diretório de trabalho onde os processos Java correspondentes foram iniciados. Exemplo: o diretório de trabalho do usuário quando o usuário iniciou o processo QNS.

Se você não souber o diretório de trabalho, procure no sistema o arquivo com o nome hs_err_pid*.log e examine o arquivo por um tempo que corresponda quando o erro ocorreu.

Conclua estes passos para especificar o local do erro fatal:

1. Faça login na máquina virtual pcrfclient01
2. Abra jvm.conf (por exemplo,vi /etc/broadhop/pcrf/jvm.conf).
3. Adicione a opção: -XX:ErrorFile=<diretory>/<file-name>%p.log à lista e certifique-se de que o caminho de diretório especificado existe e de que o usuário QNS tem permissão total sobre esse diretório. Exemplo: -X:ErrorFile=/home/qns/fatal_error%p.log
4. O comando "syncconfig.sh" pode causar muitos problemas se os arquivos conf em pcrfclient01:/etc/broadcast não estiverem em sincronia com os arquivos conf em /etc/broadcast nas VMs que executam o serviço QNS. O syncconfig.sh pegará os arquivos pcrfclient01:/etc/broadcast conf e gravará os arquivos conf em /etc/broadcast nas VMs que executam o QNS. 

   aviso: O comando synconfig.sh pegará os arquivos pcrfclient01:/etc/broadhop conf e substituirá todos os arquivos conf em /etc/broadhop nas máquinas virtuais que executam o serviço QNS (por exemplo, iomgr01, iomgr02, qns01, qns02 etc.)

5. Reinicie o aplicativo QNS e digite o comando restartall.sh