Follow

How Service Impact Evaluates Events

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.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk