Standard events published by the PATROL Agent

This page describes the standard events published by the agent that reveal a state change. It describes the circumstances leading to event publication and other details. The following table lists the events and to what class they belong. 

Standard events that reveal a state change

Event classes

Following are the event classes for standard events published by PATROL Agent:

Application state event

Every time the state of an application instance (see Instance state event) changes, the parent application state is also checked. As a result the following Events are published:

• UpdAppState Event is published if the child instance is currently the worst instance and its state has improved.
• WorstApp Event is published if the child instance becomes the worst instance.

The UpdAppState Event is published every time the worst instance of the computer is calculated:

• After application discovery.
• When running "%REFRESH_APPL_DISC <COMPUTER-APP_NAME>".
• When running the "%RESET" command.

The following table provides description, default, severity, and configuration information for the UpdAppState and WorstApp Events:

Computer state event

The computer state changes in the following circumstances:

• At startup when the agent user is initiated.
• After the computer instance has been created.
• After application discovery.
• When running "%REFRESH_APPL_DISC <COMPUTER-APP_NAME>".
• When running the "%RESET" command.

As a result of a computer state change, the UpdMachineState Event is published when the new computer state is different from the previous one. Event argument #2 indicates the reason:

• A parameter with a state worse than the current state > Argument #2 is set to "inherited from %s parameter `%s'".
• Simple discovery of bad application > Argument #2 is set to "inherited from application `%s'."
• Worst instance > Argument #2 is set to "inherited from instance `%s' of application `%s'."
• Rule state of the computer instance > Argument #2 is set to "derived from rules for the computer."

If the computer state did not change, the following events are published:

• Event "1" is published when a new parameter is causing this alert state.
• Event "2" is published when a new bad application has been found, replacing the old one.
• Event "3" is published when a new application instance is the reason.

The following table provides description, default, severity, and configuration information for the UpdMachineState, 1, 2, and 3 Events: 

Instance state event

The UpdInstState Event is published as follows:

• When an instance is destroyed.
• When an instance is a nested instance and the agent is in the process of un-registering the parent instance.
• When an instance is created using PSL create().
• After setting the rule state of an instance via PSL change_state() if the compound state has changed as a result of setting the rule state.
• During simple discovery of an application instance if the compound state changes.
• When the compound state of an instance changes. The compound state of an instance changes when any of the following situations occur: 1) the rule state of an instance changes; 2) the state of a parameter associated with the instance changes; 3) the compound state of a nested instance changes. The following text explains the reason for the instance state change:
  • Nested instance > "Current state is inherited from instance '%s'."
  • Parameter > "Current state of instance `%s' is inherited from an alert on %s parameter `%s'."
  • Rule state of the instance > "Current state of instance `%s' is derived from application rules."
  • [Computer instance only] Parameter in the computer instance > "Current state is inherited from an alert on %s parameter `%s'."
  • [Computer instance only] Rule state of the computer instance > "Current state is derived from application rules."

The following table provides description, default, severity, and configuration information for the UpdInstState Event:

Parameter alert event

Parameter Alert Events are those events related to parameter range and border definitions. As an example, let's assume the following ranges:

The table below shows which event is generated when a parameter value changes from one range to another.

The following sequence of values will validate all state transitions. Note that the out-of-range state or alert state must not affect the state transitions. Setting out-of-range state and alert states to (OK, OK, OK) or (WARN, WARN, WARN) will produce the same state transitions.

1. 15 (Normal)
2. 85 (Normal > Alarm#1)
3. 95 (Alarm#1 > Alarm#2)
4. 195 (Alarm#2 > Out-of-Range)
5. 15 (Out-of-range > Normal)
6. 195 (Normal > Out-of-range)
7. 95 (Out-of-range > Alarm#2)
8. 85 (Alarm#2 - Alarm#1)
9. 15 (Alarm#1 -> Normal)
10. 95 (Normal > Alarm#2)
11. 15 (Alarm#2 > Normal)
12. 195 (Normal > Out-of-range)
13. 85 (Out-of-range > Alarm#1)
14. 195 (Alarm#1 > Out-of-Range)

The following table provides description, default, severity, and configuration information for Events 9, 11, and 39: 

Parameter state event

UpdParState Event is published when a parameter satisfies the following conditions:

• Reactivated
• Destroyed
• Suspended/resumed
• Set by a 'status' variable in PSL (example set (<param>/status).
• Set by a 'value' variable in PSL (example set (<param>/value) or while reading the variable value from a pipe. As a result of the new value, the parameter state changes.

The following table provides description, default, severity, and configuration information for the UpdParState Event:

Recovery action event

Event 10 is published when a recovery action runs. Event 12 is published when all recovery actions run, but failed to correct the state of a parameter. 

The following table provides description, default, severity, and configuration information for Events 10 and 12: