Service states
Services uses events from Collection Zone to determine the availability and performance states of dynamic services. Understanding how states are assigned and propagated helps you interpret what you see in the Services page and perform effective root cause analysis.
Availability and performance states
If there are no negative events for the members or dependencies of a service, the availability state is Up and the performance state is Acceptable. The following table shows the default state assignments for negative events.
| Service state type | Event class | Event severity | Service state |
|---|---|---|---|
| Availability | /Status/* (except /Status/SNMP and /Status/WMI) |
Critical | Down |
| Error | Degraded | ||
| Warning | At risk | ||
| Performance | /Perf/* |
Critical | Unacceptable |
| Error | Degraded | ||
| Warning | Degraded |
By default, events generated for a component of a device do not affect the availability or performance state of the device itself in Services. For a component event to affect a service's state, you must add the component as a member of the dynamic service.
For example, if a device named LinuxServerA is a member of a service, and the HTTP process on LinuxServerA generates an event, that event does not affect LinuxServerA's state in the service. To include the HTTP process in the service's health calculation, add the HTTP process on LinuxServerA as a member of the dynamic service.
State propagation policies
State propagation policies determine how availability and performance states move through the dependency graph when an event occurs on a service member. When an event occurs on a member, Services identifies all service contexts in which that member participates and applies the relevant policies to determine how the state change propagates.
The following policy types are available, listed in order of precedence:
-
Contextual policy: Propagates the member's state change only to its immediate parent members within the current service context. A contextual policy overrides both global and default policies.
-
Global policy: Propagates the member's state change to its parent members in all service contexts in which the member participates. A global policy overrides the default policy.
-
Default policy: Sends the state of the worst condition affecting the member to its parent member. The default policy applies when no contextual or global policy is assigned.
If multiple policies are applied to a member, contextual policies take precedence over global policies, and both override the default policy.
Actual and derived state
Each member in a service model has two states:
-
Actual state: Determined by events that occur on the member, regardless of the service contexts in which it participates.
-
Derived state: Determined by policy propagation within a given service context.
In the Impact view, the symbol inside a node's border reflects the actual state. The border itself reflects the derived state. A member's actual and derived states can differ. For example, a member's actual state may be Up, but an applied contextual policy may result in a derived state of Down.
Visual state indicators
The Impact view uses symbols and borders to indicate actual and derived states. The following table describes the visual indicators for each state combination.
| Availability | Performance | Symbol (actual state) | Border (derived state) |
|---|---|---|---|
| Up | Acceptable |
 |
Green border |
| At risk | Not applicable |
 |
Yellow border |
| Degraded | Degraded |
 |
Orange border |
| Down | Unacceptable |
 |
Red border |