Alertas da ferramenta de monitoramento em tempo real

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.