Correlating Multiple WMI Events
WMI events provide a means for actions to perform place when there is a change in the managed environment. Actions are carried out by event consumers which are registered to receive events through a subscription. An example of a subscription might be "Consumer X is interested in events A and B." In such a case, consumer X is notified each time A occurs and each time B occurs, with no relationship between A and B events.
For more information about support and installation of this component on a specific operating system, see Operating System Availability of WMI Components.
The Event Correlator permits structuring subscriptions where there is a correlation between A and B events. For example, "Consumer X is interested in A events, but only if a B event has occurred within the last 5 minutes."
Common types of correlation scenarios would include:
- Statistical analysis scenarios which would compile and store aggregated data about a business's activity. For example, an Internet portal would find it prohibitively resource-intensive to log all events on the system. It is reasonable, however, to log summary events, such as a daily web usage summary, a daily usage summary for each URL, and a daily summary for each referring URL.
- Critical event scenarios which would alert an administrator upon critical conditions in the system. For example, it may not be important to know each time a disk share size drops below some critical level, but the Event Correlator could be configured so that if the disk share size dropped below that level and stayed there for a specified period of time, a warning would be sent to the administrator.
- Health-monitoring scenarios in which certain types of events are not considered a problem until their frequency exceeds a specific level. For example, it is not considered a problem when a network device delivers several error events in an hour. It is worth noting and alerting the network administrators if the number of errors in an hour exceeds one hundred. Other health-monitoring scenarios would include rising and falling edge monitoring and trend monitoring.
- Policy condition scenarios which implement an appropriate policy when specified system conditions arise. For example, a cluster of two computers might have the policy that if one of the computers fails the load is automatically transferred to the other computer and the system administrator is notified. However, if the remaining computer is experiencing low disk space, the policy is to switch the cluster into a lower availability mode and start a cleanup processes. Implementing the second policy requires correlating the two conditions.
These types of event correlation could be accomplished programmatically by setting and maintaining state using program variables. Depending upon the type of correlation needed, the Event Correlator will create and maintain either a persistent or a transient state. Persistent state remains even through a system restart and is maintained in the repository, while transient state is kept in memory.
The Event Correlator exposes state through Common Information Model (CIM). This means that to correlate events, you need to program the state machine.
Though this can be done in C/C++, it is most easily done by creating Managed Object Format (MOF) files that include the following:
State class definition (this is analogous to creating program variables). The state class defines the properties that are important to track, the state changed, and calculates any needed results.
Event filter definitions. The filters specify which events the updating consumer receives. This includes both incoming events and instance modification events fired by the state object.
Correlation result definition. There are two ways of notifying the action consumer that a correlation has occurred.
Define a special extrinsic event which the updating consumer fires when the final state is reached.
- or -
Define the result as a property value in the state object. In this case, no additional event declaration is needed and the action consumer merely subscribes to the instance modification event associated with this property.
Action consumer instances. For each particular state change, a different instance of the updating consumer must be declared. These instances specify how the state properties are changed upon receiving a particular event.
Event registration. Each updating consumer must be bound to an event filter.
Related topics
Creating Correlation Scenarios
Correlating Events Without Templates