How impact is calculated

Impact calculation varies depending on the CI relationships for a business service or manual service. Additional factors, such as change requests, network paths, storage paths, and related CIs, all affect impact calculation.

Business services

You can learn about the impact tree from the following video tutorial.

The following impact calculation flow operates for alerts where the outage does not affect a network or network storage. Event Management performs the following steps:
  1. Create a business service map. Use the svc_ci_associated and cmdb_rel_ci tables to create child-parent relationships in the business service or manual service.
  2. If there is no CMDB path from the business service to the CI but an association appears in the svc_ci_assoc table, show a Depends-on relationship between the business service and the CI. Otherwise, show no connection.
  3. For a manual service, if the CIs assigned to the service are also connected to the service in the CMDB, the map keeps the hierarchy between CIs as they appear in CMDB. The CI service assignments appear in the Service Configuration Item Associations section of the Manual Services form. If there is no connection to the service in the CMDB, the CIs appear directly under the service in the map.
  4. Create the impact tree. Mark the magnitude of an outage by 100% down, 60% affected, 40% impaired, or 20% impaired. If the items in two or more clusters are affected, the impact is 100% down.

Change requests and the In Maintenance status

If an active change request is scheduled for the CI or if the Status of the CI is In Maintenance, all alerts on the affected CI are excluded from impact calculation. The Alerts tab and Alert console also temporarily hide all corresponding alerts. The impact tree shows the CI in green with a note of (In Maintenance). The impact tree and the business service map temporarily show CIs in green.

Note: Starting with the Helsinki release, CIs are considered to be in maintenance not only when an active change request is scheduled, but also when the Status field of the CI is set to In Maintenance. In both cases, the CI is excluded from impact calculation and alerts for the CI do not appear in the Alert console.

For a business service, all alerts on CIs in the business service are also hidden from the Alerts tab. The entire business service is shown in green on the impact tree. For a host with an active change request, the host applications are considered as one unit. All child applications are treated in the same manner as the host until the change request is no longer active. For additional information, see How alerts work with CIs in maintenance.

Network paths

To account for network redundancy, Event Management uses a separate impact calculation. You can see network topology or path changes in the business service. The following impact calculation flow operates for alerts where a network path is affected. Event Management performs the following steps:
  1. Create a business service map for the affected network.
    • Use the host ID and target IP information from the alert and the network path from the Network Paths [sa_network_paths] table.
    • Use the elements in the network path that inherit from the Configuration Item [cmdb_ci] table. Also, use the elements that are associated to the path, from the Infra Path To Elements [sa_infra_path_assoc] table.
    • Set the relationships. The application CI has a Depends on::Used by relationship on an element in the path that is defined in the CI Relationship [cmdb_rel_ci] table. In the relationship, the application CI is the parent and the element in the network path is the child.
  2. Calculate a separate severity for each regular element in the path. Each regular element in the path contributes its own severity to its ancestors up to the application CI where the path originated from.
  3. Calculate all redundant elements in the path with the redundancy rule by reducing the severity on the impacted CIs by one level. For example, if the severity is Critical, the redundancy rule decreases severity by one level to Major.
  4. Create the impact tree. Mark the magnitude of an outage by 100% down, 60% affected, 40% impaired, or 20% impaired. If the items in two or more clusters are affected, the impact is 100% down.

Storage paths

To account for storage device redundancy, Event Management uses a separate impact calculation. You can see impact tree updates when the network storage topology changes from the business service. Event Management performs the following steps for alerts that contain storage CIs:
  1. Create a business service map for the affected storage device:
    • Use the storage device in the sa_fs_to_storage_path table. The storage device definition uses the file system information in the path.
    • Use the elements in the storage path that inherit from the Configuration Item [cmdb_ci] table. Also, use the elements that are associated to the path from the Infra Path To Elements [sa_infra_path_assoc] table.
    • Set the relationships. The application CI has a Depends on::Used by relationship on an element in the path that is defined in the CI Relationship [cmdb_rel_ci] table. In the relationship, the application CI is the parent and the element in the storage path is the child.
  2. Calculate a separate severity for each regular element in the path. Each regular element in the path contributes its own severity to its ancestors up to the original application CI the path.
  3. Use the redundancy rule to calculate redundant elements in the path by reducing the severity on the impacted CIs by one level. For example, if the severity is Critical, the redundancy rule decreases by one level to Major.
  4. Create the impact tree. Mark the magnitude of an outage by 100% down, 60% affected, 40% impaired, or 20% impaired. If the items in two or more clusters are affected, the impact is 100% down.

Related CIs

As alerts generate for a CI, additional impact calculations run for related CIs. For example additional impact calculations run for a business service dependency to a CI that is not actually part of the business service. These related CIs are not discovered as part of the service. Instead, the related CIs are specified by an infrastructure relationship definition.

The following impact calculation flow operates for alerts with CIs that have a dependency to related CIs which are considered outside the business service. Event Management performs the following steps:
  1. Derive relationships between the business service CIs and related CIs. Use the relationships, impact rules, and other data from the Infrastructure Relations [em_impact_infra_rel_def] table.
  2. Add related CIs to the impact tree and alert list on the Event Management dashboard.
    • Use data from the Infrastructure Relationship [em_impact_infra_rel_def] table to show containment links to the host.
    • Use the Impact Status [em_impact_status] and Alert History [em_alert_history] tables to determine the status.