[ Bottom of Page | Previous Page | Next Page | Contents | Index ]

Actions

When the event under analysis matches the conditions in the initial event filter of a rule, the rule is triggered and the rule engine runs the actions of the rule. A rule can contain one or more actions, each separated by a comma. A rule action contains one or more predicate calls. The following example shows the structure of a very simple rule action.

The types of actions are shown in the following list, and described in Action types.

• action
• reception_action
• redo_action

An action should be given a meaningful name, so it can be easily identified when tracing rules. Action names must also be unique within each rule. If you don't provide a name for an action, the rule compiler assigns its own names, such as action_1, action_2, and so forth.

The rule engine runs actions in sequential order as defined by their position in the rule, unless a predicate is called that changes the flow of control, such as the commit_action predicate. There is no guarantee of execution order of predicate calls within an action. (Actually, predicate execution order within an action conforms to Prolog logic execution rules.) If you do not know Prolog logic execution rules and want predicates to run in a certain order, place them in separate actions within a rule and order the actions accordingly.

Action types

There are three types of rule actions, described as follows:

action

Run each time a rule is triggered. This action is run for all events.

reception_action

Run only the first time a rule is triggered for a newly received event. This action is typically used for filtering duplicate events and placing redo requests. A reception_action is only valid in a plain rule.

Note:

If an internal event is generated using the generate_event predicate, the event is not placed into the reception buffer but reception_actions are still run on the event.

redo_action

Run only when a redo request is applied to a previously received event. A redo request is a reanalysis of an event. The redo_analysis predicate places a redo request. A redo_action is only valid in a plain rule.

The following example shows the usage of different action types:

• The oserv_script reception_action is only run for newly arriving events of class universal_oserv with a severity of WARNING. The reception_action is not run for redo requests.
• The link_host regular action is run for all events with the same criteria as stated previously, whether the event is newly received or has been previously received but is being reanalyzed from a redo request.

  If this action would have been written as a redo_action instead of a regular action, it would only run upon a redo request. By specifying the event linking to occur in a regular action, the action will run regardless of the order of arrival of events. For additional information about redo requests, see redo_analysis.

rule: link_oserv_to_host: (
  description: 'Link the universal_oserv to universal_host
                if they are related',

  event: _event of_class 'universal_oserv'
    where [probe_arg: _probe_arg,
           severity: equals 'WARNING'],

  reception_action: 'oserv_script': (
    exec_program(_event,
                 'oserv_beep.sh','%s',[_probe_arg],
                 'YES')
  ),

  action: 'link_host': (
    first_instance(
      event: _host_ev of_class 'universal_host'
        where [severity: within ['CRITICAL','FATAL'],
               probe_arg: equals _probe_arg,
               status: outside ['CLOSED']
        ]),

    set_event_status(_event,'ACK'),

    link_effect_to_cause(_event, _host_ev)
  ) 
).

Directives

Directives can be included in rules. Directives specified within rule sets or rules are defined with the directive: keyword syntax. If you specify more than one directive in a directive clause, separate the directives with commas; for example, directive: fire_on_non_leaf, profile. The directives are described as follows:

fire_on_non_leaf

Enables the evaluation of rules for events that are non-leaf node classes; that is, superclasses. By default, rules are only triggered by events that are leaf-node classes. This directive must be placed before the initial event filter in a rule.

The following example shows a use of the directive. This particular example causes the rule to evaluate all events because it specifies the base event class EVENT in its event filter. All other classes inherit from the base event class.

rule: test_rls: (
   directive: fire_on_non_leaf,
   event: _evt of_class within [ 'EVENT' ]
   where [ ],

   reception_action: action0:
   (
      drop_received_event
   )
).

profile

Enables profiling of rule execution. This directive enables you to obtain detailed information in report form about the execution of each rule being profiled. The profile directive can be placed at the beginning of a rule set or within individual rules. You can also profile an entire rule base with the wrb -comprules -profile command. Profiling is not enabled by default. See Profiling rules for additional information.

trace

Enables tracing of rule execution.The trace directive can be placed at the beginning of a rule set or within individual rules. You can also trace an entire rule base with the wrb -comprules -trace command or using the rule builder dialog. Tracing is not enabled by default. See Tracing rules for additional information.

[ Top of Page | Previous Page | Next Page | Contents | Index ]