Cálculo de impacto do alerta

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 alerta 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 passado do IC afetado.
• Relacionamentos entre ICs para um serviço de aplicações específico ou serviços de aplicações.
• Se o elemento IC incluir uma rede ou dispositivos de armazenamento.
• Os alertas sobre ICs no estado de manutenção são excluídos do cálculo de impacto.
  Nota:

  • ICs são considerados em manutenção não apenas quando uma solicitação de mudança ativa é programada, 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.
• Por padrão, o impacto é calculado para todos os serviços de aplicações operacionais. No entanto, o sistema permite filtrar o cálculo de impacto por classe de serviço ou por serviço de aplicações individual. Para obter mais informações, consulte Adicionar CMDB tabelas ou classes para cálculo de impacto e Adicione serviços de aplicações para cálculo de impacto.

Se houver uma conexão entre serviços, o impacto de um serviço no 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

Como o impacto é calculado

O cálculo de impacto 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 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. 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ário-primário no serviço de aplicações ou nos serviços de aplicações.
2. Se não houver caminho do CMDB do serviço para o IC, mas uma associação aparecer na tabela svc_ci_assoc, mostre um relacionamento Depends-on entre o serviço de aplicações e o IC. Caso contrário, não mostrará 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 serão exibidos 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 programada para o IC ou se for Status da instalação Do IC é Em Manutenção Todos os alertas no IC afetado sã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 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 é programada, 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 nos ICs no serviço também ficam 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 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 a topologia de rede ou mudanças de caminho no serviço de aplicações. 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 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 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 severidade 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 gravidade nos ICs afetados em um nível. Por exemplo, se a severidade 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 eventos usa 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 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 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 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 severidade 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 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 severidade for Critical, a regra de redundância diminui 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

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 adicional são executados para uma dependência de serviço de aplicativos para um IC que não faz realmente 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 aplicações. Gestão de eventos executa as seguintes etapas:

1. Derive relacionamentos entre os ICs de serviço de aplicações e os ICs relacionados. Use os relacionamentos, as 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 eventos painel.
   • 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 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 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 de impacto. As regras de impacto padrão a seguir 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 Principal cada membro tem 30% de influência (90% dividido por 3). A gravidade de todo o cluster só pode mudar para Principal quando todos os três membros têm uma severidade de Principal .

Você pode configurar regras de impacto diferentes por cluster e, portanto, a propagação de 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 de 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

No exemplo acima, há dois pontos de entrada. O cluster Osaka no lado direito tem três ICs. O cluster Tokyo 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 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 a configuração manual de cluster, há duas linhas: Impacto na aplicação e Membro do cluster da aplicação. 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 a falha para seus pais) são duas. O cluster 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, embora a falha do cluster de Tóquio seja laranja grave.

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 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 em relacionamentos de infraestrutura.

Serviço de aplicações de IC

Determina como o impacto se aplica a entidades primárias ou secundárias que fazem parte de um serviço de aplicativos.

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 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 severidade de Principal cada membro tem 20% de influência (60% dividido por 3). A gravidade de todo o cluster só pode mudar para Principal quando dois ou mais membros do cluster têm uma severidade de Principal . Todo o cluster também é considerado inativo.

Caminho de Armazenamento

Determina como o impacto 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 do cálculo de impacto

Nome da Propriedade	Descrição
evt_mgmt.impact_calculation.alert_group_support	Habilitar suporte a grupo de alertas.
evt_mgmt.impact_maintenance.sleep_time_sec	Tempo mínimo em segundos para verificar a 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 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: 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_msec	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 ).

Para obter mais informações, consulte Gestão de eventos - Cálculo de impacto [KB1157218] .