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.
