Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Alertas RTMT

Configurar

Alertas do sistema

Alertas do CallManager

BaixaDisponívelVirtualMemory e BaixaSwapPartitionAvailableDiskSpace

LogPartitionHighWaterMarkExceeded e LogPartitionLowWaterMarkExceeded

CpuPegging

Verificar

Troubleshoot

Introduction

Este documento discute os alertas da Cisco Real-Time Monitoring Tool (RTMT) e demonstra como solucionar problemas de alguns alertas comumente vistos.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento do Cisco Call Manager Web Administration.

Componentes Utilizados

As informações neste documento são baseadas no Cisco CallManager Server 11.0.

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.

Informações de Apoio

A RTMT que é executada como um aplicativo do lado do cliente usa HTTPS e TCP para monitorar o desempenho do sistema, o status do dispositivo, a descoberta do dispositivo, os aplicativos de Integração de Telefonia do Computador (CTI) e as portas de mensagens de voz. A RTMT pode ser usada para configurar alertas para o cluster que está monitorando.

O sistema gera mensagens de alerta para notificar o administrador quando uma condição predefinida é atendida, como quando um serviço ativado vai de até inativo. O sistema pode enviar alertas como e-mail/e-page.

RTMT, que suporta definição, configuração e visualização de alertas, contém alertas pré-configurados e definidos pelo usuário. Embora você possa executar tarefas de configuração para ambos os tipos, não é possível excluir alertas pré-configurados.

Alertas RTMT

O Unified RTMT exibe alertas pré-configurados e alertas personalizados na Central de alertas, como mostrado na imagem.

Você também pode acessar a Central de alertas clicando no ícone da Central de alertas na árvore hierárquica na alça do sistema.

Configurar

O Unified RTMT organiza os alertas nas guias aplicáveis: Sistema, CallManager, Cisco Unity Connection e Personalizado.

Você pode habilitar ou desabilitar alertas pré-configurados e personalizados na Central de alertas; no entanto, não é possível excluir alertas pré-configurados.

Os alertas em RTMT são classificados como:

- Alertas do sistema

- Alertas do CallManager

- Alertas personalizados

Alertas do sistema

Esta lista inclui os alertas de sistema pré-configurados:

- Falha na autenticação

- CiscoDRFFailure

- CoreDumpFileFound

- CpuPegging

- EventoAuditoriaCríticaGerado

- ServiçoCríticoInativo

- FalhaHardware

- LogFileSearchStringFound

- LogPartitionHighWaterMarkExceeded

- LogPartitionLowWaterMarkExceeded

- EspaçoDiscoDisponívelPartiçãoAtivaBaixa

- Memória virtualDisponívelBaixa

- BaixoInativePartitionAvailableDiskSpace

- BaixoSwapPartiçãoDisponívelEspaçoDisco

- ServerDown (aplica-se a clusters do Unified Communications Manager (CUCM))

- SparePartitionHighWaterMarkExceeded

- SparePartitionLowWaterMarkExceeded

- SyslogSeverityMatchFound

- SyslogStringMatchFound

- VersãoSistemaIncompatível

- TotalProcessosEThreadsExcedidosLimite

Alertas do CallManager

Esta lista inclui os alertas do CallManager pré-configurados.

- BeginThrottlingCallListBLFSubscriptions

- CallAttemptBlockedByPolicy

- ChamadaProcessandoNóCpuPegging

- CARIDSEngineCrítico

- CARIDSEngineFailure

- CARSchedulerJobFailed

- CDRAgentSendFileFailed

- Falha de CDRFileDelivery

- CDRHighWaterMarkExceeded

- CDRMaximumDiskSpaceExcedido

- CódigoAmarelo

- DBChangeNotifyFailure

- DBReplicationFailure

- DBReplicationTableOutofSync

- PrevençãoDeBloqueioDRB

- DDRDown

- EMCCFailedInLocalCluster

- EMCCFailedInRemoteCluster

- RelatóriosDeQualidadeDeVozExcessivo

- IMEDistributedCacheInativo

- IMEOverQuota

- Alerta de qualidadeIMEQ

- IdentificadoresFallback insuficientes

- IMEServiceStatus

- Credenciais inválidas

- TaxaDePulsaçãoDeTFTPSbaixo

- RastreamentoDeChamadasMal-Intencionado

- MediaListExhausted

- MgcpDChannelOutOfService

- NúmeroDeDispositivosRegistradosExcedido

- NúmeroDeGatewaysRegistradosDiminuídos

- NúmeroDeGatewaysRegistradosAumentado

- NúmeroDeDispositivosMídiaRegistradosDiminuído

- NúmeroDeDispositivosMídiaRegistradosAumentado

- NúmeroDeTelefones RegistradosDescartados

- RouteListExhausted

- SDLLinkOutOfService

- TCPSetupToIMEFailed

- TLSConnectionToIMEFailed

- UserInputFailure

BaixaDisponívelVirtualMemory e BaixaSwapPartitionAvailableDiskSpace

Os servidores Linux têm uma tendência de "não limpar" o uso da memória virtual por um período de tempo, e isso é visto como acumulado e, portanto, esses alertas.

O Linux opera de forma um pouco diferente como um sistema operacional.

Uma vez alocada a memória para um processo, ela não será retomada pelo processador a menos que algum outro processo solicite mais memória do que a memória disponível.

Isso causa memória virtual alta.

Um pedido de aumento do limite para o alarme nas versões mais elevadas do gerenciador de chamadas foi documentado no defeito; https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq75767/?reffering_site=dumpcr

Para partições de troca, esse alerta indica que a partição de troca é deixada com pouco espaço disponível e é usada com grande frequência pelo sistema. A partição de troca é normalmente usada para estender a capacidade física de RAM quando necessário. Em condições normais, se a RAM for suficiente, a troca não deve ser muito usada.

Além disso, podem ser alertas RTMT ativados causados por uma compilação de arquivos temporários, recomenda-se a reinicialização do servidor para limpar todos os arquivos temporários desnecessários.

LogPartitionHighWaterMarkExceeded e LogPartitionLowWaterMarkExceeded

Ao executar show status na CLI de um servidor CUCM, um valor que especifica a porcentagem ocupada e livre de partição de registro no espaço em disco do CUCM é mostrado. Também conhecido como partição comum, esses valores especificam o espaço ocupado pelos logs/rastreamentos e os arquivos CDR no servidor, que, embora sejam inofensivos, podem causar problemas no procedimento de instalação/atualização devido à falta de espaço ao longo do tempo. Esses alertas servem como um aviso ao administrador para limpar os registros que podem ter sido acumulados ao longo do tempo no cluster/servidor.

LogPartitionLowWaterMarkExceeded: esse alerta é gerado quando o espaço preenchido atinge os valores de limite configurados para o alerta. Este alerta serve como um indicador de pré-verificação para o uso do disco.

LogPartitionHighWaterMarkExceeded: esse alerta é gerado quando o espaço preenchido atinge os valores de limite configurados para o alerta. Quando o alerta é gerado, o servidor começa a limpar automaticamente os logs mais antigos para reduzir o espaço para valores de lentes que o limite HighWaterMark.

A melhor prática seria limpar os registros manualmente assim que o alerta LogPartitionLowWaterMarkExceeded fosse recebido.

As etapas para isso são:

Etapa 1. Iniciar RTMT.

Etapa 2. Selecione a Central de Alertas e execute estas tarefas:

Selecione LogPartitionHighWaterMarkExceeded, anote seu valor e altere seu valor de limite para 60%.

Selecione LogPartitionLowWaterMarkExceeded, anote seu valor e altere seu valor de limite para 50%.

A pesquisa ocorre a cada 5 minutos, portanto, aguarde de 5 a 10 minutos e verifique se o espaço em disco necessário está disponível. Se quiser liberar mais espaço em disco na partição comum, altere os valores de thread LogPartitionHighWaterMarkExceeded e LogPartitionLowWaterMarkExceeded para valores mais baixos (por exemplo, 30% e 20%) novamente.

Dê de 15 a 20 minutos para limpar o espaço na partição comum. Você pode monitorar a diminuição no uso do disco com o comando show status da CLI.

Isso derrubaria a partição comum.

CpuPegging

O alerta CpuPegging monitora o uso da CPU com base no limite configurado.

Quando o alerta de pegging da CPU é recebido, o processo que ocupa a CPU mais alta pode ser ocupado indo para a Gaveta do sistema à esquerda, que é Processo.

A partir do CLI do servidor em questão, essas saídas fornecerão algumas informações.

- utils diagnose test

- show process load cpu ordenado

- show status

- lista ativa do núcleo do utils

É recomendável observar se o pico da CPU acontece em um momento específico ou aleatoriamente. Se ocorrer aleatoriamente, os rastreamentos CUCM detalhados necessários, bem como os registros de perfmon RisDC, para verificar o que está disparando o pico na CPU. Se os alertas estiverem acontecendo em uma hora específica do dia, isso pode ser devido a alguma atividade agendada, como backup do Sistema de Recuperação de Desastre (DRS), CDR Load etc.

Além disso, com base nas informações sobre qual processo ocupa a maior parte da CPU, logs específicos são tomados para investigação mais detalhada. Por exemplo. se o culpado for Tomcat, os registros relacionados ao Tomcat serão necessários.

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

Se os alertas não forem descartados depois que você seguir as soluções alternativas sugeridas aqui, ou se os alertas parecerem ter impacto imediato no serviço, entre em contato com o TAC da Cisco com os detalhes necessários sobre a versão do gerenciador de chamadas, o número de nós no cluster, o tempo e a duração do alerta e o processo necessário se restringindo em caso de pegging da CPU.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.