Use o Portal de Erros Conhecidos e a Comunidade para ajudar você a encontrar problemas de informação.

Preferências gerais

Auto-saúde

Por padrão, o recurso de monitoramento de integridade automática não está habilitado. Para habilitá-lo, navegue até Event Management > Configurações > Propriedades e selecione Sim para a propriedade Enable Event Management self-health monitoring (evt_mgmt.self_health_active). Use este recurso para monitorar e rastrear muitos recursos de Gestão de eventos.

Nota:

Os ICs usados no serviço de integridade automática são criados no CMDB.

Use as configurações a seguir para ajudar a evitar a degradação do desempenho.

Tópico	Detalhes
Regras de negócios	Evite escrever regras de negócios para tabelas de evento [em_event], pois elas não são executadas no URL REST padrão atual que é usado para injeção de evento. As regras de negócios que são gravadas para tabelas de alerta [em_alert] devem ser altamente eficientes ou podem resultar em degradação do desempenho. Em vez de gravar uma regra de negócios, considere se é mais apropriado gravar um trabalho. Uma regra de negócios ineficiente pode fazer com que a criação de um incidente para um alerta falhe e o cálculo do impacto do alerta falhe. Não grave regras de negócios assíncronas para tabelas de alerta. As regras de negócios não devem mudar o campo Categoria nas tabelas de evento [em_event].
Ampliação	Verifique o tempo médio de processamento de eventos antes de aumentar o rendimento do evento ao iniciar pela primeira vez com Gestão de eventos. Faça esta verificação depois que um fluxo inicial de eventos e todas as regras estiverem em vigor. Se o tempo de processamento demorar alguns milissegundos por evento, determine a causa da desaceleração do processamento antes de continuar a escalonar. A duração do desempenho pode ser verificada na tabela Estatísticas de desempenho [sa_performance_statistics].
Configurar para ambientes em grande escala	Defina a propriedade Habilitar processamento de eventos de vários nós (evt_mgmt.event_processor_enable_multi_node) como Sim. Habilite vários nós em ambientes de produção e defina valores com base no tamanho da implantação e na taxa de eventos esperada. Defina a propriedade Número de eventos de processamento de trabalhos programados (evt_mgmt.event_processor_job_count) como 4. Se você estiver enviando eventos de uma origem personalizada, verifique se os eventos têmchave de mensagem ou origem, nó, tipoe dados de recurso.
Problemas de latência para receber eventos	Verifique as seguintes configurações: Verifique se o campo Bucket na tabela do evento [em_event] está definido como um valor maior que zero (0). Navegar até Scheduler do Sistema > Trabalhos programados e pesquise por - process events*. Verifique se todos os trabalhos - process events* existem de acordo com a configuração da propriedade Número de eventos de processamento de trabalhos programados (event_processor_job_count). Verifique se o Estado é Running ou Ready. Se o estado for Queued ou Error, defina o estado do trabalho como Ready.
Arquivar eventos	Evite alterar o tempo de retenção padrão dos eventos. Para registrar eventos por mais tempo, crie uma tabela de arquivamento e um trabalho que copie novos eventos para ela. Faça isso programando um trabalho para fazer backup regularmente de eventos [em_event] para uma tabela personalizada. Não estenda a rotação da tabela adicionando mais dias.

Integração de eventos

Interceptações SNMP

• Use uma ferramenta de monitoramento para enviar interceptações SNMP, em vez de enviá-las diretamente dos dispositivos.
• Para evitar ter que reescrever as regras de evento, carregue MIBs antes de definir as regras de evento.

API do serviço Web

• Usar uma API de serviço Web para integração pode reduzir o número de regras de evento necessárias. Esta ação evita a necessidade de transformar eventos (os dados preparados são enviados em um evento para a instância).
• Use credenciais dedicadas para integração. Opcionalmente, designe credenciais específicas para cada origem de evento.

CloudWatch

Use credenciais dedicadas para integrar o CloudWatch com ServiceNow.

E-mail

Use o e-mail somente se a origem tiver um volume baixo e outras opções não estiverem disponíveis, como executar um script ou encaminhar uma interceptação SNMP.

Regras de evento

Definições de configuração ao criar regras de evento:

• Grave Regras de Evento para aplicar ao maior número de eventos possível. Regras mais específicas podem ser criadas conforme necessário e devem usar um valor de ordem inferior.
• Se uma regra mais geral puder alcançar o mesmo resultado, evite escrever Regras de evento que se apliquem somente a um determinado subconjunto de eventos.
• Quando as Regras de evento são aplicadas a eventos, nenhuma mudança é feita no evento original. Todo o processamento ocorre na memória, portanto, use o campo Anotações de processamento e/ou use o link de ação de IU Verificar processo de evento para solucionar problemas.
• Se você alterar uma regra/transformação que tenha regras de mapeamento existentes, revise e teste novamente com eventos reais ou simulados.
• Certifique-se de que o valor do campo De corresponda exatamente a uma cadeia de caracteres no JSON no campo additional_info de um evento. Essa correspondência acontece quando uma regra é configurada com base nas informações de um arquivo MIB. Se o arquivo MIB não for carregado, o JSON da interceptação SNMP mostrará varbinds (vinculação de variável) com nomes pontilhados, em vez do nome traduzido no MIB. A regra de mapeamento do campo de evento falha ao ser aplicada.
• Estabeleça uma convenção de nomenclatura consistente. Uma convenção comum é: <customer acronym>.<Event Source>.<Description>. Por exemplo, ACME.OEM.Normalize
• Se duas Regras de Evento tiverem condições semelhantes definidas, use o campo Ordem para controlar qual Regra de Evento será executada.
• Use Regras de evento para associar um alerta a um IC.

Configurações adicionais para criar regras de evento:

Resultado desejado	Atividade necessária
Desduplicação eficaz e habilitação de processamento de eventos paralelos eficiente	Preencha os campos Origem, Nó, Tipo, Recurso, Nome da métrica.
Vinculação de IC	Vincule ao host - preenchendo o campo Nó e, opcionalmente, os identificadores de IC. Vinculação à aplicação e/ou dispositivo – preenchendo o campo Identificadores de IC e o campo Informações adicionais.
Correlação de alertas, usando agregação de alertas	Preencha os campos Recurso e Nome da métrica. Nota: Se o IC também estiver vinculado, a correlação de alertas será aprimorada.

Campos de evento personalizado

Inclua campos adicionais somente no campo Informações adicionais do evento.

Não adicione campos adicionais a um evento adicionando um campo personalizado à tabela de evento [em_event].

Não adicione colunas à tabela de evento [em_event].

Para obter informações sobre como incluir campos adicionais em eventos, consulte Campos de alerta personalizados.

Desduplicação

Definições de configuração para desduplicação.

• O campo message_key é usado para desduplicação. Se valores de chave de mensagem confiáveis não forem fornecidos com o evento de origem, é importante ter um plano bem definido para construir esses identificadores.
• Se a chave da mensagem não estiver definida, a chave da mensagem padrão será <Source + Node + Type + Resource + Metric Name> .
• A diretriz é fazer com que a origem do evento preencha os campos <Source + Node + Type + Resource + Metric Name> prontos para uso e preencha a chave de mensagem. Esta ação permite uma melhor distribuição do processamento de eventos entre trabalhadores de instância e nós.
• Se o evento de origem não tiver valores para esses campos, certifique-se de preenchê-los usando regras de transformação. Esta ação não afeta o processamento de eventos, mas é usada para desduplicação. Preencha o máximo possível desses campos antes que eles sejam enviados para a instância. Esta ação fornece melhor distribuição de eventos pelos trabalhadores do processador e, portanto, melhor rendimento e escala.

Vinculação de IC

• Sempre que possível, sempre tente vincular um alerta a um IC.
  Nota:

  Embora as Regras de evento sejam definidas em eventos, os ICs são vinculados a alertas que resultam desses eventos e não estão vinculados ao evento.
• Para vincular um host, uma máquina ou qualquer dispositivo a um IP, preencha o campo Nó do evento com um nome de host exclusivo, FQDN, IP ou endereço MAC. Se outros identificadores forem necessários para identificar um host, preencha o campo ci_identifiers com um formato JSON. O formato JSON deve conter o nome e o valor do campo do CMDB para executar a correspondência.
  Nota:

  O campo Nó de evento deve ser preenchido a partir de uma regra de evento ou preenchido com um nome de host exclusivo da origem antes que o evento seja inserido.
• A estratégia de vinculação primária é usar o campo Nó. Se o campo Nó não for preenchido previamente no evento, ele poderá ser preenchido usando regras de evento.

Configurações de alerta

Ciclo de vida do alerta

Funcionalidade de alerta geral:

• Um alerta é aberto sempre que um evento não é ignorado ou seu limite é excedido por uma regra de evento e a desduplicação não identifica o evento como pertencente a um alerta existente.
• Um alerta é encerrado quando um evento de encerramento é enviado na mesma chave de mensagem ou o alerta é encerrado manualmente.
• Um alerta será reaberto se um alerta de abertura que tenha a mesma chave de mensagem for enviado dentro do intervalo de tempo definido nas propriedades (o padrão é uma hora).
• Se um alerta for aberto e fechado em uma taxa alta, conforme definido nas propriedades, ele se tornará oscilante. Quando essa taxa de abertura e fechamento para, o alerta sai do estado de oscilação.
• Se um incidente for aberto a partir de um alerta, esse alerta permanecerá aberto enquanto o incidente permanecer aberto. Por padrão, quando o incidente ou o alerta é encerrado, o outro também é encerrado. Este comportamento pode ser configurado usando propriedades.
• Não feche um alerta ao criar um incidente correspondente.
• Não exclua um alerta em aberto. Feche um alerta primeiro e exclua-o.
• Use Confirmar para indicar que o alerta é conhecido e pode ser temporariamente ignorado.
• Não use o Reconhecimento para marcar um alerta como precisando de atenção.
• Não crie alertas em nenhum destes estados:
  • Encerrado
  • OK
  • Abrir
• A propriedade evt_mgmt.alert_auto_close_interval fecha automaticamente os alertas após o período especificado. Não especifique 0, pois este valor desabilita o recurso e pode levar à degradação do desempenho.
• Não crie alertas no estado OK. Em alguns sistemas de monitoramento, OK indica que um problema foi resolvido, enquanto em outros sistemas de monitoramento, OK é usado para denotar eventos que não são de importância operacional. Para o primeiro caso, use Limpar em vez de OK usando uma Regra de mapeamento. Para o último caso, tenha uma regra Ignorar, a menos que os eventos sejam de valor específico.

Regras de ação de alerta

• Um trabalho programado aplica regras de ação de alerta a novos alertas a cada 11 segundos. Se uma regra de alerta não iniciar imediatamente, aguarde de 10 a 15 segundos antes de iniciar a solução de problemas.
• Use o campo Ordem para controlar qual Regra de Alerta será executada se duas Regras de Alerta tiverem condições semelhantes definidas.
• Use regras de ação de alerta com modelos de tarefa para preencher valores estáticos em um incidente. Use o script preenchedor para atribuir valores dinâmicos no incidente. O script preenchedor pode retornar um valor falso para anular a criação do incidente.
• Crie um usuário chamado Gestão de eventos (ou um nome semelhante). Em seguida, o campo Criado por em um modelo de tarefa (por exemplo, Incidente) pode ser definido para indicar que o usuário era a origem da tarefa.
• Para executar qualquer atribuição de valor dinâmico ou para substituir a atribuição de valor dinâmico OOB, use a inclusão de script EvtMgmtCustomIncidentPopulator.

Correção

• Sempre defina as propriedades do fluxo de trabalho de orquestração para a tabela Tarefa de correção [em_remediation_task].
• Usar Fila do ECC e Fluxo de trabalho > Fluxo de trabalho em tempo real > Todos os Contextos para encontrar informações mais detalhadas sobre atividades de correção.

Regras de negócios

• As regras de negócios criadas em tabelas de alerta não devem demorar mais do que alguns milissegundos. Em vez de usar uma regra de negócios, considere se a mesma funcionalidade pode ser obtida usando um trabalho.
• Não use regras de negócios para associar um alerta a um IC. Use regras de evento para vincular em vez de usar regras de negócios.

Planejamento

• Organize a configuração de origem de evento de filtros, módulos e assim por diante em vários esforços paralelos, em vez de em série.
• Valide os formatos de evento processados para garantir que os dados analisados estejam alinhados com os resultados desejados.
• Teste eventos de produção em um ambiente de não produção. Integre com gerenciadores de elemento de não produção e instâncias ServiceNow. Se os gerenciadores de elemento de não produção não estiverem disponíveis, envie eventos dos gerenciadores de elemento para os ambientes de produção e não produção.

Serviços e painel

• Use Grupos de serviço para agrupar serviços em grupos lógicos para reduzir o número de serviços exibidos no painel Integridade de serviço.
• Importe mapas de serviço criados manualmente.

Inteligência para métricas logs e arquivos do coletor

Inteligência para métricas logs e arquivos do coletor estão localizados no caminho $(MID_SERVER_DIR)/agent. Use esses logs e arquivos para fins de solução de problemas e monitoramento.

O desempenho deInteligência para métricas pode ser verificado no arquivo de log MID Server quando o parâmetro mid.log.level MID Server está no modo de depuração.

Inteligência para métricas os números de desempenho estão disponíveis na tabela Estatísticas de desempenho [sa_performance_statistics]. Para exibir os números de desempenho, filtre a lista Estatísticas de desempenho do Metric Collector.