Distinguishing instance state changes from propagated states

PATROL has two ways an application instance can achieve the WARN or ALARM state as follows:

  • A PSL change_state
  • An inherited parameter state

The WARN and ALARM state can be detected by analyzing the "status" and "ruleState" variables in the agent symbol table. This is possible through a PSL script, but is also possible through external SNMP access to the PATROL MIB.

The OFFLINE state can only occur due to a PSL change_state, and cannot be inherited from parameter states.

The "status" and "ruleState" variables are built-in variables in the instance's symbol table. The following table lists those situations that apply:


"status" and "ruleState" variables

"status"

"ruleState"

Meaning

OK

OK

No activity such as alarms or state changes

WARN

OK

Propagated WARN parameters

ALARM

OK

Propagated ALARM parameters

OK

WARN

Not possible

WARN

WARN

PSL change_state to WARN

ALARM

WARN

PSL change_state to WARN, but also a parameter in ALARM

OK

ALARM

Not possible

WARN

ALARM

Not possible

ALARM

ALARM

PSL change_state to ALARM

Any state

OFFLINE

PSL change_state to OFFLINE

Was this page helpful? Yes No Submitting... Thank you

Comments