Cálculo do impacto do alerta

  • Versão de lançamento: Yokohama
  • Atualizado 30 de jan. de 2025
  • 11 min. de leitura
  • O cálculo do Impact 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 do Impact, nos mapas de serviços de aplicações e nos painéis.

    Os cálculos do Impact 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 do Impact.
    • Número de alertas ativos relacionados.
    • Histórico anterior do IC afetado.
    • Relacionamentos entre ICs para um determinado serviço de aplicações ou serviços de aplicações.
    • Se o elemento de IC incluir uma rede ou dispositivos de armazenamento.
    • Os alertas sobre ICs no estado de manutenção são excluídos do cálculo do Impact.
      Nota:
      • ICs são considerados em manutenção não apenas quando uma solicitação de mudança ativa é agendada, mas também quando o. Status O campo 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 do Impact usam informações de várias fontes para definir a gravidade do alerta
    Fatores que afetam o status do Impact

    Como o impacto é calculado

    O cálculo do Impact varia dependendo dos 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, afetam o cálculo do Impact.

    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 eventosexecuta as seguintes etapas:
    1. Crie 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 secundários-primários no serviço de aplicações ou nos serviços de aplicações.
    2. Se não houver um caminho do CMDB do serviço para o IC, mas uma associação aparecer na tabela svc_ci_assoc, mostre um relacionamento dependente entre o serviço de aplicações e o IC. Caso contrário, não mostre 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 item de configuração de serviço do Serviço de aplicaçõesformulário. Se não houver conexão com o serviço no CMDB, os ICs aparecerão diretamente abaixo dos serviços de aplicações no mapa.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100%, 60% afetada, 40% prejudicada ou 20% prejudicada. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% inferior.
    Solicitações de mudança e o status Em manutenção

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

    Nota:
    • ICs são considerados em manutenção não apenas quando uma solicitação de mudança ativa é agendada, mas também quando o. Status O campo 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 sobre ICs no serviço também estão ocultos na guia Alertas. Todo o serviço é 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 eventosusa um cálculo de impacto separado. Você pode ver a topologia de rede ou mudanças de caminho no serviço de aplicações. O fluxo de cálculo do Impact a seguir opera para alertas em que um caminho de rede é afetado. Gestão de eventosexecuta as seguintes etapas:
    1. Crie um mapa de serviço de aplicações 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 derivados da tabela de 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 Depende de::Usado por em um elemento no caminho 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 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 gravidade 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 gravidade nos ICs afetados em um nível. Por exemplo, se a gravidade for Critical, a regra de redundância diminui a gravidade em um nível para Major.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100%, 60% afetada, 40% prejudicada ou 20% prejudicada. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% inferior.
    Caminhos de armazenamento
    Para considerar a redundância do dispositivo de armazenamento, Gestão de eventosusa um cálculo de impacto separado. Você pode ver atualizações da árvore de impacto quando a topologia de armazenamento de rede muda do serviço de aplicações. Gestão de eventosExecuta as seguintes etapas para alertas que contêm ICs de armazenamento:
    1. Crie um mapa de serviço de aplicações 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 derivados da tabela de 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 Depende de::Usado por em um elemento no caminho 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 IC da aplicação original do caminho.
    3. Use a regra de redundância para calcular elementos redundantes no caminho reduzindo a gravidade nos ICs afetados em um nível. Por exemplo, se a gravidade for Critical, a regra de redundância diminui em um nível para Major.
    4. Crie a árvore de impacto. Marque a magnitude de uma indisponibilidade em 100%, 60% afetada, 40% prejudicada ou 20% prejudicada. Se os itens em dois ou mais clusters forem afetados, o impacto será 100% inferior.
    ICs relacionados

    À medida que 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 aplicações para um IC que não faz realmente parte do serviço de aplicações. 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 do Impact 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 aplicações. Gestão de eventosexecuta as seguintes etapas:
    1. Derive relacionamentos entre os ICs de serviço de aplicações e ICs relacionados. Use 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 Gestão de eventospainel.
      • Use 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 Impact [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 gravidade 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 aplicáveis, os serviços de aplicações e as configurações do Impact. 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 de todo o cluster como Grave cada membro tem 30% de influência (90% dividido por 3). A gravidade de todo o cluster só pode mudar para Grave quando todos os três membros têm uma gravidade de Grave .
    Você pode configurar regras de impacto diferentes por cluster e, portanto, a propagação de impacto de 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 de cluster para downstream em direção aos clusters secundários.
    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 de Osaka no lado direito tem três ICs. O cluster de Tóquio no lado esquerdo tem dois ICs. O servidor de backup de Tóquio e Osaka tem primários compartilhados - cluster de Tóquio e cluster de Osaka. No painel direito, você pode ver a Árvore do Impact, 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 manual de cluster, há duas linhas: Impacto na aplicação e Membro do cluster de aplicações. Os secundários são exibidos desde que o campo Impacto em foi selecionado como Primário e não como Serviço de aplicações. Na linha Membro do cluster de aplicações, o campo Influência é configurado como dois. Isso implica que a quantidade mínima de crianças que falham (e que propagam o fracasso para seus pais) são duas. O cluster de Osaka está configurado como três. A porcentagem é diferente para o servidor de backup de Tóquio e Osaka para cada cluster (50% e 34%). Como você pode ver, mesmo que a falha do servidor de backup de Tóquio e Osaka seja crítica, ela influencia os pais de forma diferente. O cluster de Osaka permanece verde, mesmo que a falha do cluster de Tóquio seja Laranja Maior.

    Clique em um serviço ou IC para ver os alertas associados a ele. Por exemplo, se você clicar no serviço de aplicações de alto nível, os alertas associados a ele serão exibidos na área de alerta na 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 nos relacionamentos de infraestrutura.
    Serviço de aplicações de IC
    Determina como o Impact se aplica a 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 100%. Por exemplo, a gravidade do impacto primário é derivada do IC secundário com a gravidade mais alta.
    IC primário na aplicação
    Define o impacto somente na entidade primária.
    Caminho de Rede
    Determina como o Impact 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 Grave cada membro tem 20% de influência (60% dividido por 3). A gravidade de todo o cluster só pode mudar para Grave quando dois ou mais membros do cluster têm uma gravidade de Grave . Todo o cluster também é considerado inativo.
    Caminho de Armazenamento
    Determina como o Impact se aplica a 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 do impacto
    Nome da Propriedade Descrição
    evt_mgmt.impact_calculation.alert_group_support Habilite o suporte do 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 cronograma de solicitação de mudança para o IC.
    evt_mgmt.impact_calculation.alert_copy_delay O atraso após criar ou atualizar um alerta, antes que ele seja usado para cálculo e agrupamento de impacto. Usado para compensar as regras de negócios atrasadas ou lentas definidas na tabela em_alert. Padrão: 2000 ms.

    Usado quando alertas e eventos são processados um de cada vez (quando o. evt_mgmt.max_objs_in_alert_query a propriedade não está definida ou está definida como 1 ).

    evt_mgmt.impact_calculation.alert_copy_delay_when_alerts_are_processed_in_batch_ms O atraso após criar ou atualizar um alerta, antes que ele seja usado para cálculo e agrupamento de impacto. Usado para compensar atrasos ou regras de negócios lentas definidas na tabela em_alert. Padrão: 30000 ms.

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