Applies To
- Impact 1.2.9
Summary
In this document we examine which events Service Impact evaluates to report the availability or performance status of Dynamic Services.
Theory
The default Service Impact interpretation of Resource Manager events is summarized below:
- Events in the /Status/Snmp and /Status/WMI classes are Ignored by Service Impact.
- Events in the /Status event class (and all /Status subclasses) are evaluated for Dynamic Service Availability in the following way:
- Critical severity events -
- cause the status of the related element to change to Red / DOWN
- Error severity events -
- cause the status of the related element to change to Orange / Degraded
- Warning severity events -
- cause the status of the related element to change to Yellow / At Risk
Events in the /Status class can include:
- ping down
- IP service failures
- JMX checks, etc.
- Events in the /Perf event class (and all subclasses) are evaluated for Performance as follows:
- Critical severity events cause the status of the related element to change to Red / DOWN
- Error severity events cause the status of the related element to change to Orange / Degraded
- Warning severity events cause the status of the related element to change to Orange / Degraded
Events in the /Perf event class typically relate to exceeded thresholds on:
- Filesystems
- CPU
- Memory
Note that if an event has been generated for a component of a device (for example, a specific process), by default this event is not interpreted by Service Impact for the purposes of the device's availability or performance. In order for events related to a component to be interpreted by Impact, the component itself must be added to the Service as its own Element. Administrators can identify the component that must be added by examining the Component field of the event.
Example
The following example makes the concept more clear.
Assume that LinuxServerA is an Element of Service called Wordpress Blog. If the http process on LinuxServerA quits, a Resource Manager event is created in the event console, but Impact will not interpret that event for the purposes of LinuxServerA's availability or performance, and therefore the event will not affect the availability or performance status of the Wordpress Blog Service. If the administrators of Wordpress Blog decide that the http process on LinuxServerA is indeed a dependency of the Wordpress Blog Service, they must add the http process on LinuxServerA as its own Element of the Wordpress Blog Service.
Comments