Cálculo de impacto do alerta

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 11 min. de leitura

    • O cálculo de impacto mostra a magnitude de uma indisponibilidade em ICs, serviços, alertas e grupos de alertas. O sistema usa fatores como regras de impacto e relacionamentos de IC para calcular a gravidade de um alerta gerado. A gravidade aparece na árvore de impacto, nos mapas de serviços de aplicações e nos painéis.

    Os cálculos de impacto estão disponíveis para grupos de alertas de serviços de aplicações. Os fatores a seguir são usados para calcular o impacto geral de uma indisponibilidade.
    • Regras de impacto.
    • Número de alertas ativos relacionados.
    • Histórico do IC afetado.
    • Relacionamentos entre ICs para um serviço de aplicações específico ou serviços de aplicações.
    • Se o elemento de IC incluir uma rede ou dispositivos de armazenamento.
    • Alertas em ICs no estado de manutenção são excluídos do cálculo de impacto.
      Nota:
      • Os ICs são considerados em manutenção não apenas quando uma solicitação de mudança ativa está programada, mas também quando o campo Status do IC está definido como Em manutenção.
      • Quando um IC secundário é colocado em manutenção, ele também coloca o IC primário em manutenção.

    Se houver uma conexão entre serviços, o impacto de um serviço sobre o outro também será calculado.

    Figura 1. Os cálculos de impacto usam informações de várias fontes para definir a gravidade do alerta
    Fatores que afetam o status do impacto

    Como o impacto é calculado

    O cálculo de impacto varia de acordo com os relacionamentos de IC para um serviço de aplicações ou serviços de aplicações. Fatores adicionais, como solicitações de mudança, caminhos de rede, caminhos de armazenamento e ICs relacionados, todos afetam o cálculo de impacto.

    Serviços
    O fluxo de cálculo de impacto a seguir opera para alertas em que a indisponibilidade não afeta uma rede ou armazenamento de rede. Gestão de eventos executa as seguintes etapas:
    1. Criar um mapa de serviço. Use as tabelas Associações de item de configuração de serviço [svc_ci_assoc] e Relacionamentos de IC [cmdb_rel_ci] para criar relacionamentos primário-secundário no serviço de aplicativos ou nos serviços de aplicativos.
    2. Se não houver caminho do CMDB do serviço para o IC, mas uma associação for exibida na tabela svc_ci_assoc, mostre um relacionamento Depende de entre o serviço de aplicativos e o IC. Caso contrário, não mostrará nenhuma conexão.
    3. Para serviços de aplicações, se os ICs atribuídos ao serviço também estiverem conectados ao serviço no CMDB, o mapa manterá a hierarquia entre os ICs conforme eles aparecem no CMDB. As atribuições de serviço de IC aparecem na seção Associações de itens de configuração de serviço do formulário Serviço de aplicações. Se não houver conexão com o serviço no CMDB, os ICs serão exibidos diretamente nos serviços de aplicações no mapa.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100% inativo, 60% afetado, 40% prejudicado ou 20% prejudicado. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% menor.
    Solicitações de mudança e o status Em manutenção

    se uma solicitação de mudança ativa estiver programada para o IC ou se o Status de instalação do IC for Em manutenção, todos os alertas no IC afetado serão excluídos do cálculo de impacto. A guia Alertas também oculta temporariamente todos os alertas correspondentes. A árvore de impacto mostra o IC em verde com uma nota de (Em manutenção). A árvore de impacto e o mapa de serviço mostram temporariamente os ICs em verde.

    Nota:
    • Os ICs são considerados em manutenção não apenas quando uma solicitação de mudança ativa está programada, mas também quando o campo Status do IC está definido como Em manutenção.
    • Quando um IC secundário é colocado em manutenção, ele também coloca o IC primário em manutenção.

    Para um serviço, todos os alertas em ICs no serviço também estão ocultos na guia Alertas. O serviço inteiro é mostrado em verde na árvore de impacto. Para um host com uma solicitação de mudança ativa, as aplicações de host são consideradas como uma unidade. Todas as aplicações secundárias são tratadas da mesma maneira que o host até que a solicitação de mudança não esteja mais ativa. Para obter informações adicionais, consulte Como os alertas funcionam com ICs em manutenção.

    Caminhos de rede
    Para considerar a redundância de rede, Gestão de eventos usa um cálculo de impacto separado. Você pode ver as mudanças de topologia ou caminho de rede no serviço de aplicativos. O fluxo de cálculo de impacto a seguir opera para alertas em que um caminho de rede é afetado. Gestão de eventos executa as seguintes etapas:
    1. Crie um mapa de serviço de aplicativos para a rede afetada.
      • Use o ID do host e as informações de IP de destino do alerta e o caminho de rede da tabela Caminhos de rede [sa_network_paths].
      • Use os elementos no caminho de rede que derivam da tabela Item de configuração [cmdb_ci]. Além disso, use os elementos associados ao caminho da tabela Caminho de infraestrutura para elementos [sa_infra_path_assoc].
      • Defina os relacionamentos. O IC da aplicação tem um relacionamento Depends on::Used by em um elemento no caminho que está definido na tabela Relacionamento de IC [cmdb_rel_ci]. No relacionamento, o IC da aplicação é o primário e o elemento no caminho da rede é o secundário.
    2. Calcule uma gravidade separada para cada elemento regular no caminho. Cada elemento regular no caminho contribui com sua própria severidade para seus ancestrais até o IC da aplicação de onde o caminho se originou.
    3. Calcule todos os elementos redundantes no caminho com a regra de redundância, reduzindo a severidade dos ICs afetados em um nível. Por exemplo, se a severidade for Critical, a regra de redundância diminuirá a severidade em um nível para Major.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100% inativo, 60% afetado, 40% prejudicado ou 20% prejudicado. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% menor.
    Caminhos de armazenamento
    Para considerar a redundância do dispositivo de armazenamento, Gestão de eventos usa um cálculo de impacto separado. Você pode ver as atualizações da árvore de impacto quando a topologia de armazenamento de rede muda do serviço de aplicativos. Gestão de eventos executa as seguintes etapas para alertas que contêm ICs de armazenamento:
    1. Crie um mapa de serviço de aplicativos para o dispositivo de armazenamento afetado:
      • Use o dispositivo de armazenamento na tabela sa_fs_to_storage_path. A definição do dispositivo de armazenamento usa as informações do sistema de arquivos no caminho.
      • Use os elementos no caminho de armazenamento que derivam da tabela Item de configuração [cmdb_ci]. Além disso, use os elementos associados ao caminho da tabela Caminho de infraestrutura para elementos [sa_infra_path_assoc].
      • Defina os relacionamentos. O IC da aplicação tem um relacionamento Depends on::Used by em um elemento no caminho que está definido na tabela Relacionamento de IC [cmdb_rel_ci]. No relacionamento, o IC da aplicação é o primário e o elemento no caminho de armazenamento é o secundário.
    2. Calcule uma gravidade separada para cada elemento regular no caminho. Cada elemento regular no caminho contribui com sua própria gravidade para seus ancestrais até o caminho do IC da aplicação original.
    3. Use a regra de redundância para calcular elementos redundantes no caminho, reduzindo a severidade dos ICs afetados em um nível. Por exemplo, se a gravidade for Critical, a regra de redundância diminuirá em um nível para Major.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100% inativo, 60% afetado, 40% prejudicado ou 20% prejudicado. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% menor.
    ICs relacionados

    Conforme os alertas são gerados para um IC, cálculos de impacto adicionais são executados para ICs relacionados. Por exemplo, cálculos de impacto adicionais são executados para uma dependência de serviço de aplicativos para um IC que não faz parte do serviço de aplicativos. Esses ICs relacionados não são descobertos como parte do serviço. Em vez disso, os ICs relacionados são especificados por uma definição de relacionamento de infraestrutura.

    O fluxo de cálculo de impacto a seguir opera para alertas com ICs que têm uma dependência de ICs relacionados que são considerados fora do serviço de aplicativos. Gestão de eventos executa as seguintes etapas:
    1. Derive relacionamentos entre os ICs de serviço de aplicativos e os ICs relacionados. Use os relacionamentos, regras de impacto e outros dados da tabela Relações de infraestrutura [em_impact_infra_rel_def].
    2. Adicione ICs relacionados à árvore de impacto e à lista de alertas no painel Gestão de eventos.
      • Use os dados da tabela Relacionamento de infraestrutura [em_impact_infra_rel_def] para mostrar links de contenção para o host.
      • Use as tabelas Status do impacto [em_impact_status] e Histórico de alertas [em_alert_history] para determinar o status.

    Regras de impacto

    As regras de impacto, que são usadas para cálculo de impacto, estimam a magnitude ou a severidade de uma indisponibilidade com base nos ICs afetados.
    A tabela Regra de impacto [em_impact_rule] contém regras de impacto que mostram os ICs, serviços de aplicações e configurações de impacto aplicáveis. As seguintes regras de impacto padrão estão disponíveis.
    Membro de cluster de aplicações
    Determina como os membros do cluster de aplicações afetam o impacto geral do cluster. Por exemplo, se um cluster de três membros exigir 90% de Influência para definir a gravidade do cluster inteiro como Principal, cada membro terá 30% de Influência (90% dividido por 3). A severidade do cluster inteiro só pode mudar para Principal quando todos os três membros têm uma severidade de Principal.
    Você pode configurar diferentes regras de impacto por cluster e, portanto, a propagação do impacto do IC secundário para o primário (para o mesmo IC secundário) será diferente. Portanto, você pode criar manualmente grupos de ICs (também conhecidos como clusters manuais) e configurar a regra de impacto no nível do cluster para downstream em direção aos secundários do cluster.
    Figura 2. Exemplo em que o mesmo IC secundário propagará seu impacto para o cluster primário de forma diferente para cada cluster
    A gravidade do IC secundário é propagada de forma diferente para cada serviço primário

    No exemplo acima, há dois pontos de entrada. O cluster Osaka no lado direito tem três ICs. O cluster de Tóquio no lado esquerdo tem dois ICs. O servidor de backup Tokyo e Osaka tem primários compartilhados - cluster Tokyo e cluster Osaka. No painel direito, você pode ver a árvore de impacto em que o cluster de Tóquio tem dois membros do cluster de aplicações com 50% de influência cada e o cluster de Osaka tem três com 34% de influência cada.

    Para configuração de cluster manual, há duas linhas: Impacto na aplicação e Membro do cluster de aplicações. Os secundários são exibidos, já que o campo Impacto em foi selecionado como Primário e não Serviço de aplicações. Na linha Membro do cluster de aplicações, o campo Influência está configurado como dois. Isso implica que a quantidade mínima de secundários que falham (e que eles propagam a falha para cima para seus primários) é dois. O cluster Osaka está configurado para três. A porcentagem é diferente para o servidor de backup Tokyo e Osaka para cada cluster (50% e 34%). Como você pode ver, embora a falha do servidor de backup de Tóquio e Osaka seja Crítica em vermelho, ela influencia os primários de forma diferente. O cluster Osaka permanece verde, embora a falha do cluster Tokyo seja laranja principal.

    Clique em um serviço ou IC para ver os alertas associados a ele. Por exemplo, se você clicar no serviço de aplicativos de alto nível, os alertas associados a ele serão exibidos na área de alerta em Exibição de mapa quando você selecionar Alertas. Os alertas listados são os do serviço selecionado. Os alertas de serviços secundários são listados quando esses serviços são selecionados.

    Os seguintes campos de impacto são exibidos quando você seleciona Impacto.

    Inclusão
    Determina o impacto nas entidades com um relacionamento "Contém". Esta regra é somente leitura.
    Dependências de Infraestrutura
    determina a definição de propagação de impacto para ICs em relacionamentos de infraestrutura.
    Serviço de aplicações de IC
    determina como o impacto se aplica às entidades primárias ou secundárias que fazem parte de um serviço de aplicações.
    Impacto de IC
    Aplica-se a serviços de aplicações. Determina o relacionamento entre os membros do serviço. O impacto de ICs secundários para primários é sempre de 100%. Por exemplo, a severidade do impacto primário é derivada do IC secundário com a severidade mais alta.
    IC primário na aplicação
    define o impacto somente na entidade primária.
    Caminho de Rede
    determina como o impacto se aplica a entidades primárias ou secundárias que fazem parte de uma rede tradicional.
    Membro de Cluster de Sistema Operacional
    Determina como os membros do cluster do host afetam o status geral do cluster com base em uma porcentagem ou número de membros do cluster. Por exemplo, se um cluster de três hosts exigir 60% de Influência para definir a gravidade de Principal, cada membro terá 20% de Influência (60% dividido por 3). A severidade do cluster inteiro só pode mudar para Principal quando dois ou mais membros do cluster têm uma severidade de Principal. O cluster inteiro também é considerado inativo.
    Caminho de Armazenamento
    determina como o impacto se aplica às entidades primárias ou secundárias que fazem parte de uma rede de armazenamento.

    Propriedades

    Além de configurar regras de impacto, você pode configurar propriedades para cálculo de impacto.
    Configure estas propriedades, conforme apropriado:
    Tabela 1. Propriedades de cálculo de impacto
    Nome da Propriedade Descrição
    evt_mgmt.impact_calculation.alert_group_support Habilite o suporte ao grupo de alertas.
    evt_mgmt.impact_maintenance.sleep_time_sec Tempo mínimo em segundos para a verificação de manutenção de IC: verifica o campo Status no IC e qualquer programação de solicitação de mudança para o IC.
    evt_mgmt.impact_calculation.alert_copy_delay O atraso após a criação ou atualização de um alerta, antes que ele seja usado para cálculo de impacto e agrupamento. Usado para compensar as chegadas atrasadas ou regras de negócio lentas definidas na tabela em_alert. Padrão = 2000 ms.

    Usado quando alertas e eventos são processados um de cada vez (quando a propriedade evt_mgmt.max_objs_in_alert_query não está definida ou está definida como 1).
    evt_mgmt.impact_calculation.alert_copy_delay_when_alerts_are_processed_in_batch_msec O atraso após a criação ou atualização de um alerta, antes que ele seja usado para cálculo de impacto e agrupamento. Usado para compensar as chegadas atrasadas ou regras de negócio lentas definidas na tabela em_alert. Padrão = 30.000 ms.

    Usado em ambientes de clientes grandes com alto tráfego, quando alertas e eventos são processados em lotes (quando a propriedade evt_mgmt.max_objs_in_alert_query está definida com um valor maior que 1.