Sem fio : Cisco Policy Suite for BNG

Logs e informação exigidos no caso de uma falha de sistema QPS

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve as etapas que devem ser terminadas a fim capturar a informação quando uma falha de sistema ou um impacto da série da política do quantum (QPS) ocorrem. Se o hardware, o software, e as exigências da máquina virtual são cumpridos, é improvável que o QPS causará um crash.

Contribuído por Aravindhan Balasubramian, por Tony Pina, e por Vinodkumar Tiwari, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

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:

  • Liberação 5.5 QPS e mais atrasado.

Nota: Determinados logs não aparecerão nas liberações QPS mais velhas do que a liberação 5.5 QPS.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Capture a informação

Se uma falha de sistema QPS acontece, recolha esta informação:

Os diagnósticos e debugam logs

  1. O início de uma sessão à política e ao carregamento ordena a máquina virtual do cliente da função (PCRF) (por exemplopcrfclient01) e recolhe a informação de diagnóstico (por exemplo, /opt/broadhop/installer/diag/diagnostics.sh).
  2. Entre à máquina virtual do cliente PCRF e recolha debugam a informação. Debugar a informação inclui o log QNS, o repo do svn, e detalhes de configuração consolidados QNS. Certifique-se de que os logs consolidados cobrem a época da falha de sistema e de que o nível de debug está ajustado no arquivo logback.xml. 
  3. Recolha esta saída de seu QPS (por exemplo, execute /opt/broadhop/installer/diag/zip_debug_info.sh e a saída é armazenada em /var/tmp/debug_info <date>.zip).
  4. Entre ao exemplo da máquina virtual QPS onde a falha de sistema ocorreu. (por exemplo, pcrfclient0x, lb0x, qns0x, portal0x). Recolha os logs QNS e certifique-se de que o log QNS inclui a época da falha de sistema. (por exemplo, gato /etc/broadhop/license/QUANTUM201311210402429360.lic).

Informação de licença QPS

  1. Entre à máquina virtual do cliente PCRF e recolha a informação de licença QPS. Um QPS é licenciado geralmente para uma característica específica e há um número máximo de sessões simultâneas que apoie. O QPS igualmente tem uma data de expiração para esta característica.
  2. Navegue a este diretório: /etc/broadhop/license e captura a saída do arquivo da licença (.lic). (por exemplo, gato /etc/broadhop/license/QUANTUM201311210402429360.lic).

Estatística de sistema

  1. Capture a estatística de sistema (exemplo: CPU, memória, utilização do disco).
  2. Entre à máquina virtual do cliente PCRF e recolha a saída. Exemplo: /opt/broadhop/control/top_qps.sh
  3. Entre à máquina virtual que corresponde (por exemplo, pcrfclient0x, lb0x, qns0x) e capture esta estatística de sistema:

    gato /proc/meminfo > informação de memória atribuída
    livre - s 60 > estatísticas da memória para cada único minuto
    vmstat 1 > estado CPU para cada único minuto
    picosegundo - auxiliar | dirija -10 > detalhes de processo da parte superior 10 que consome a maioria da utilização CPU
    swapon - s > sumário de uso da troca pelo dispositivo
    . du - a | tipo - n - r | cabeça - n 10 > arquivos/diretórios da parte superior 10 que consomem mais espaço

  4. Entre à máquina virtual do sessionmgr e recolha o mongostat e o mongotop das saídas, que ajudarão a fim pesquisar defeitos se a edição está relacionada ao base de dados ou não.

Rosqueie a configuração no construtor da política

Entre ao construtor da política e navegue aos dados de referência > ao System-1 > configurações de encaixe > rosqueando a configuração. 

O número de linhas pôde variar de 40 aos 50 pés para TP, mas é menos de 1,000. O número máximo de linhas que você pode configurar é 50 pés. Se você aumenta o número de linhas, este impacta o desempenho de sistema. 

Log de erro fatal

Quando uma falha de sistema ocorre, o QPS gerencie um log de erro fatal, que contenha o estado do processo naquele tempo que o erro fatal ocorreu. O erro fatal ou os erros de exceção fatais fazem com que o programa aborte.

O log de erro fatal inclui esta informação:

  • A exceção de funcionamento ou sinaliza que provocado o erro fatal
  • Versão e informação de configuração
  • Detalhes na linha que provocou o erro fatal e o rastreamento de pilha da linha
  • A lista de linhas sendo executado e de seu estado
  • Informação sumária sobre o montão
  • A lista de bibliotecas nativas carregadas
  • Argumentos da linha de comando
  • Variáveis de ambiente
  • Detalhes sobre o operating system (OS) e a unidade de processamento central (CPU)

O nome de arquivo do log do padrão segue este formato: hs_err_pid<pid>.log e é gerado no diretório de funcionamento onde os processos correspondentes das Javas começaram. Exemplo: o diretório de funcionamento do usuário quando o usuário começou o processo QNS.

Se você não conhece o diretório de funcionamento, procura o sistema pelo arquivo com o o nome hs_err_pid*.log e o examina o arquivo por um momento esse combina quando o erro ocorreu.

Termine estas etapas a fim especificar o lugar para o erro fatal:

  1. Entre à máquina pcrfclient01 virtual
  2. Abra jvm.conf (por exemplo, vi /etc/broadhop/pcrf/jvm.conf).
  3. Adicionar a opção: - XX: ErrorFile=<directory>/<file-name>%p.log à lista e certificam-se de que o trajeto de diretório especificado existe e de que o usuário QNS tem a permissão completa sobre esse diretório.  Exemplo:  - X: ErrorFile=/home/qns/fatal_error%p.log
  4. O comando de syncconfig.sh pode causar muitos problemas se os arquivos do conf em pcrfclient01:/etc/broadhop não estão na sincronização com os arquivos do conf em /etc/broadhop nos VM que executam o serviço QNS. syncconfig.sh tomará os arquivos do conf pcrfclient01:/etc/broadhop e redigirá sobre os arquivos do conf em /etc/broadhop nos VM que executam o QNS. 

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

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


Document ID: 117999