Important

   

This documentation space contains information about PATROL Agents when deployed in a TrueSight Operations Management environment. If you are a BMC Helix Operations Management user, see PATROL Agent 22.1 for BMC Helix Operations Management. Open link

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

Standard event

Event class

1

Computer state event

2

Computer state event

3

Computer state event

9

Parameter alert event

10

Recovery action event

11

Parameter alert event

12

Recovery action event

39

Parameter alert event

UpdAppState

Application state event

UpdInstState

Instance state event

UpdMachineState

Computer state event

UpdParState

Parameter state event

WorstApp

Application state event

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:

 UpdAppStateWorstApp
DescriptionUpdate state of application %s.Worst instance of application '%s' is '%s'.
Default SNMP settingNo trap
Default storagePEM circular file
SeverityHigh (4) if new state is ALARM
Medium (3) if new state is WARN
Low (2) if it is another state change
Very low (1) if no state change occurred in the application
ConfigurationSetting AR_ALLOWSENDPARAMONLY to yes in patrol.conf will disable publishing of these events. By default it is set to no.

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: 

 UpdMachineState123
DescriptionUpdate status of host: %s %s.Current state of '%s' is %s.Current state of '%s' is inherited from application '%s'.Current state of '%s' is inherited from instance '%s' of application '%s'.
Default SNMP settingNo trap
Default storagePEM circular file
SeverityLow (2)
ConfigurationSetting AR_ALLOWSENDPARAMONLY to yes in patrol.conf does not affect the events. By default it is set to no.

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

UpdInstState

Description

Update status for instance %s.Reason:%s

Default SNMP setting

No trap

Default storage

PEM circular file

Severity

High (4) if new state is ALARM
Medium (3) if new state is WARN
Low (2) if it is another state change
Very low (1) if no state change occurred in the instance

Configuration

Setting AR_ALLOWSENDPARAMONLY to yes in patrol.conf will disable publishing of this event. By default it is set to no.

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:

Example

Border range is [0,100]; out of range state: OK; trigger alarm: "immediately on alarm".
Alarm#1 range is [80,90]; alert state: WARN; trigger alarm: "immediately on alarm".
Alarm#2 range is [90,100]; alert state: ALARM; trigger alarm: "immediately on alarm".
The "normal range" is [0,80].

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

Parameter

Normal

Alarm #1

Alarm #2

Out-of-Range

Normal

NA

11

11

39

Alarm #1

9

NA

11

39

Alarm #2

9

11

NA

39

Out-of-Range

9

11

11

NA

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: 

 91139
Description

%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is  now OK - current value is %{PARAMETER_VALUE}

%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is in %{EVENT_TYPE} current value is %{PARAMETER_VALUE

%s of %s parameter '%s' triggered on '%s'. %f %s %d
Default SNMP settingTrapTrapNo trap
Default storagePEM circular file
SeverityMedium (3)High (4)Medium (3)
ConfigurationSetting AR_ALLOWSENDPARAMONLY to yes in patrol.conf does not affect the events. By default it is set to no.

Note

 If you have configured an MRL rule using the old rule format, then replace the rule as shown in the following examples:

Parameter alert event type 11

#Old format for event type 11

%s of %s parameter '%s' triggered on '%s'. %d <= %f <= %d

#New format for event type 11

%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is in %{EVENT_TYPE} current value is %{PARAMETER_VALUE}

# The following example illustrates how to use this new format using a pconfig rule

"/EventSetup/Format/BiiP3/catalogs/0/types/11/slots/msg" = { REPLACE = "%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is in %{EVENT_TYPE} current value is %{PARAMETER_VALUE}"}

Parameter alert event type 9

 #Old format for event type 9

Alert on '%s' from %s parameter '%s' cancelled; exception no longer exists.

#New format for event type 9

%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is  now OK - current value is %{PARAMETER_VALUE}

# The following example illustrates how to use this new format using a pconfig rule

"/EventSetup/Format/BiiP3/catalogs/0/types/9/slots/msg" = { REPLACE = "%{PARAMETER_NAME} for %{APPCLASS}/%{APPINSTANCE} is  now OK - current value is %{PARAMETER_VALUE}"}


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:

Parameters

UpdParState

Description

Update status of parameter %s: new value %s.

Default SNMP setting

No trap

Default storage

PEM circular file

Severity

High (4) if new state is ALARM
Medium (3) if new state is WARN
Low (2) if it is another state change
Very low (1) if no state change occurred in the parameter

Configuration

Setting AR_ALLOWSENDPARAMONLY to yes in patrol.conf does not affect the event. By default it is set to no.

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: 

 1012
DescriptionAll recovery actions have been run.Recovery action run in response to the %s alert generated by %s parameter '%s' of '%s'.%s.
Default SNMP settingNo trap
Default storagePEM circular file
SeverityMedium (3)
ConfigurationSetting AR_ALLOWSENDPARAMONLY to yes in patrol.conf does not affect the events. By default it is set to no.
Was this page helpful? Yes No Submitting... Thank you

Comments