The following is the documentation to reference the information in the Impact tab:
Customer Impact: From page 57 of the Service Manager User Guide:
About a Customer's Criticality and a Service's Outage Alarm Priority
A customer's criticality is factored into the impact calculation of any alarms that cause a service outage for one of the customer's services. Assume, for example, that "Customer A" has a Medium criticality value of 15 and "Customer B" has a Low criticality value of 5 and both Customer A and B are associated to services that have high criticality values and are down.
The root cause alarm for the outage on Customer A's service will have an increased impact of + 30 for the service and + 15 for the customer. The root cause alarm for Customer B's service will have an increased impact of +10 for the service and +5 for the customer.
Consequently, because Customer A has a higher criticality value the alarms that affect Customer A's service have a higher impact. This means that although both example alarms affect high criticality services, the root-cause alarm that affects Customer A's service appears higher in the alarm view in OneClick because it is ranked a higher priority alarm than the root-cause alarm that affects Customer B's service.
Service Impact: From page 24 of the Service Manager User Guide:
Criticality - Specifies the criticality value that is factored into the impact calculation for a service resource model in an alarm state (the root cause alarm). If a service is degraded as a result of the resource alarm, one half of the service's criticality value is factored into the impact calculation for the alarm. If a service is slightly degraded, one third of the value is factored into the calculation. If a service is down, the entire value is factored into the calculation.
Low (default) = 10
Medium Low = 15
Medium = 20
Medium High = 25
High = 30
For example, a Degraded High criticality service has an impact of (50%) * 30 = 15, and a Down Low criticality service has an impact of (100%) * 10 = 10. The alarm that caused the Degraded High criticality service has a comparatively greater impact than the alarm the caused the Down Low criticality service.
Symptoms: From page 20 of the Condition Correlation User Guide:
Specifies the relationship between symptomatic conditions and the root cause condition.
You can choose one of the following relationships:
o Caused By-The alarm associated with the root cause condition caused the alarms for the associated symptomatic conditions. When the rule is met, OneClick suppresses the alarms for symptomatic conditions and lists them as symptoms under the Alarms view Impact tab in OneClick.
o Implies-The symptomatic conditions suggest the existence of another condition that may be unknown to the management system. When the rule is satisfied, the set event of the implied condition is processed on the target model. Though, this may raise an alarm on the target model, OneClick will not suppress the alarms for symptomatic conditions.
o Implied Cause-This rule incorporates the logic of the Caused By and Implies rules. The symptomatic conditions are indicative of another condition. The set event of this implied condition is processed on the target model. If this event raises an alarm on the target model, OneClick will suppress the alarms associated with the symptomatic conditions and will list the suppressed alarms as symptoms of the root cause alarm under the Impact tab in OneClick.
If you choose Implies or Implied Cause, the Root Cause Target selection box appears on the Correlation Rule window. It lets you specify whether the alarm should be generated on the correlation domain with which the rule is associated or on one of the symptomatic conditions.
Root Cause Condition
Specifies the single condition that caused or was the implied cause of the symptomatic conditions. You can select only one root cause condition for a rule.
Management Lost Impact: From page 90 and 95 of the How to Manage Your Network with SPECTRUM:
This text entry box takes a value that indicates the relative importance of the device within the network being modeled. When SPECTRUM loses contact with the device, this value is summed for the device itself and all of its downstream neighbors for which a gray condition is now being asserted (because their actual status cannot be determined). The aggregate device criticality value is displayed as the Impact Severity value of the associated alarm in the Alarm Manager's Impact Scope view. The default value for all devices is "1"; you can increase this value as desired depending on how important you consider the device to be (the higher the number, the more critical the device is to the network). For more information on the Impact Scope view, refer to the Enterprise Alarm Manager User Guide (2065).
You can assign a relative importance value to port models using the port criticality (0x1290c) attribute. The criticality of a port is used in the Impact Severity calculations of an alarm on any port which may cause a network outage. You can also display the criticality of a port in the Web Alarm View to allow prioritization of port alarms. The port criticality attribute can be set for an individual port using the port model's Port Fault Management View, or the Global Attribute Editor. For more information, see the Search Manager User's Guide (2383).
Customer and Service Impact require the creation of Services and Customers associated with a Service.
Symptoms requires the creation of Condition Correlations.
Management Lost Impact is based solely on the Device and Port Criticality values assigned to the models impacted by an outage. The Device and Port Criticality for a model can be changed using the Attribute Editor. Then, the Impact column can be displayed in the OneClick Alarms tab and then sorted on Criticality and Impact so that the most critical with the highest impact is at the top of the list of alarms. .
Definition of the "Impact" tab in SPECTRUM OneClick
(Legacy KB ID CNC TS29563 )