Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Tivoli TEC Rules Language

Compound rules Typical Errors Adding classes to the rulebase Removing legacy components  

The rules language is an external syntax which compiles into PROLOG. Because additional templates can be written in PROLOG, a knowledge of PROLOG is very helpful in creating custom rules.

While any given rule set must be maintained and developed in the same way as it was created, either with the Rule Builder or programming, it is important to note that a given rule base may have some rule sets that were created with the Rule Builder and some that were programmed.

Rules are of the form if-then. The if part is expressed in the Event Class and Conditions, while the then part is expressed in the Actions.

A rule will conditionally execute its actions based on the class of the event instance which is being evaluated. Each simple rule acts on one event instance of a specified class.

After specifying an event class, you might choose to additionally qualify rule actions based on the values in the attributes. In the first example on Goal--Examples of Rules in English, the rule should only execute if this machine is the NFS file server, so a condition that hostname ="bebop" enforces that constraint.

In the second example, su to root is a potential security threat; adding to_user as a user defined attribute in the Su_Failure event gives you the opportunity to activate the rule only if to_user =root. Every attribute you add to a BAROC definition allows you to constrain actions based on it.

There are two relationships for attribute values:

Equality is expressed by providing a single entry with the in list relation.

Using tests on attributes can encode relationships among events, such as when the hostname attribute in a Host_Down is tested against the server attribute in an NFS_Server_Not_Responding. These should be well documented in the BAROC files for easier maintenance. Remember that the relationship encoded in the rules is not visible in the BAROC file. Modifying the BAROC file could impact the execution of rules by disturbing such relationships. Also, multiple attribute constraints may be specified.

There are two pieces of information to specify in the action of a simple rule--what to do and when to do it.

If the conditional part of a rule is satisfied, when does the action take place? Consider the examples in the opening of this unit.

In the first example, when an event instance of class hostdown arrives, action is taken. In the second example, if a threshold of more than 10 duplicates are received, action is taken. In the third example, when a status change is made to an already received event, action is taken. Finally, in the last rule, action is taken 15 minutes after arrival if the event instance is still OPEN.

In general, there are several possible points in time when an action takes place, including:

Each rule must specify only one trigger.

The complete list of activation points is:

Rule structure

This section describes the general rule structure, provides usage notes, and shows examples for the following rule types. Explanations of each rule type can be found in Rule types.

Rule parser grammar

An HTML file containing the grammar for the rule parser in Backus Naur Form (BNF) notation is located on the event server at the following location:

$BINDIR/../generic_unix/TME/TEC/BOOKS/HTML/rulep.html

and on the product CD at the following location:

/BOOKS/HTML/rulep.htm

The grammar provides complete structure and syntax for rule language statements.

General structure of a plain rule

The following example shows the general structure of a plain rule:

rule: rule_name: (
  description: 'description_text',
  
  directive: directives,

  event: event_filter
    where [
      attribute_conditions
    ],

  action: action_name: (
    action_body
  )
).

Usage notes

Examples

  1. The following plain rule example correlates the clearing of printer problem events with a Printer_Error_Cleared event.
    rule: print_reset :(
    
      event: _event of_class 'Printer_Error_Cleared' 
        where [
          status: equals 'OPEN' ,
          hostname: _hostname
        ] ,
    
      reception_action:(
        all_instances(event: _prt_ev of_class 
          within ['Printer_Paper_Out',
                  'Printer_Toner_Low',
                  'Printer_Offline',
                  'Printer_Output_Full',
                  'Printer_Paper_Jam',
                  'Printer_Door_Open'
          ]
    
          where [hostname: equals _hostname,
                 status: outside ['CLOSED']
          ],
    
          _event - 3600 - 3600 ),
    
        change_event_status( _prt_ev, 'CLOSED' ),
    
        drop_received_event
      )
    ).
  2. The following plain rule example sets a timer for 90 seconds on a printer problem event. If the timer expires and the problem is not fixed, the timer rules (including the one shown in example 1 of General structure of a timer rule) are evaluated.
    rule: print_assist : (
    
      event: _event of_class 
        within ['Printer_Paper_Out',
                'Printer_Toner_Low',
                'Printer_Offline',
                'Printer_Output_Full',
                'Printer_Paper_Jam',
                'Printer_Door_Open'
        ]
    
        where [
          status: _status equals 'OPEN' ,
          hostname: _hostname,
          msg: _msg
        ] ,
    
      reception_action:(
        set_timer(_event, 90, '')
      )
    ).

General structure of a change rule

The following example shows the general structure of a change rule:

change_rule: rule_name: (
  description: 'description_text',
  
  directive: directives,

  event: event_filter,
    where [
      attribute_conditions
    ],

  sender: sender_filter,

  attribute: attribute_change_filter,

  action: action_name: (
    action_body
  )
).
 

Usage notes

Example

The following change rule example sends a mail message to tec_print when an error has been cleared on the printer. This message is only sent when a preceding message indicating a printer problem was issued (the num_actions attribute equals 1).

change_rule: print_chg_assist : (

  event: _event of_class 
    within ['Printer_Paper_Out',
            'Printer_Toner_Low',
            'Printer_Offline',
            'Printer_Output_Full',
            'Printer_Paper_Jam',
            'Printer_Error_Cleared',
            'Printer_Door_Open'
    ]

    where [
      hostname: _hostname,
      status: _status outside ['CLOSED'],
      num_actions: equals 1,
      msg: _msg
    ] ,

  attribute: status set_to _new_status within ['CLOSED'],

  action:(
    exec_program(_event,
      'scripts/TEC_Send_Mail.sh',
      '"TEC - %s: %s" tec_print "The following condition for printer \
%s has been fixed:\n\t%s"',
      [_new_status, _msg, _hostname, _msg],
      'YES')
  )
).

General structure of a timer rule

The following example shows the general structure of a timer rule:

timer_rule: rule_name: (
  description: 'description_text',
  
  directive: directives,

  event: event_filter,
    where [
      attribute_conditions
    ],

  timer_duration: timer_duration_filter,

  timer_info: timer_info_filter,

  action: action_name: (
    action_body
  )
).

Usage notes

Examples

  1. The following timer rule example sends a mail message to tec_print for assistance with a printing problem, if the problem has persisted past the expiration of a timer set on one of the events shown in the list of the event filter. The expiration of the timer set in example 2 in General structure of a plain rule causes this rule to be evaluated.
    timer_rule: timer_print_assist : (
    
      event: _event of_class 
        within ['Printer_Paper_Out',
                'Printer_Toner_Low',
                'Printer_Offline',
                'Printer_Output_Full',
                'Printer_Paper_Jam',
                'Printer_Door_Open'
        ]
    
      where [
        status: _status equals 'OPEN' ,
        hostname: _hostname,
        msg: _msg
      ] ,
    
      action:(
        exec_program(_event,
          'scripts/TEC_Send_Mail.sh',
          '"T/EC - %s: %s" tec_print "The printer %s has the \
    following condition:\n\t%s"',
          [_status, _msg, _hostname, _msg],
          'YES')
      )
    ).
  2. The following timer rule example raises the severity of an event to FATAL that has had a Level 1 timer expire and has not yet been acknowledged or closed. A Level 2 timer is set as part of this rule.
    timer_rule: 'upgrade_level1': (
      
      event: _event of_class 'universal_host'
    
        where [
          status: outside ['CLOSED','ACK']
        ] ,
    
      timer_info: equals 'Level 1',
    
      action: raise_sev: (
        set_event_severity(_event, 'FATAL'),
        set_timer(_event, 90, 'Level 2')
      )
    ).

General structure of a simple rule

The following example shows the general structure of a simple rule:

simple_rule: rule_name: 
  description: 'description_text'
  
  directive: directives

  event: event_filter
    where [
      attribute_conditions
    ]

  when:
    event_conditions:
    event_actions

Usage notes

Example

The following example simple rule changes an Su_Failure event to a severity of FATAL if an su command (switch user) to root fails three times within five minutes

simple_rule: escalate_su_failure:

  description: 'Escalate more than 3 su root failures
    in 5 minutes.'

  event: Su_Failure
    where [ to_user: equals 'root' ]

  when: frequency_exceeds 3 within 5 minutes:
      change_event_severity('FATAL').

General structure of a correlation rule

The following example shows the general structure of a correlation rule:

correlation_rule: rule_name: 
  description: 'description_text'
  
  directive: directives

  event_relation: event_class1 operator event_class2
  within: integer minutes

  when: [
    event_class1.attribute1 equals
    event_class2.attribute2
  ]

Usage notes

Example

The following two correlation rules examples can be used together to set up a simple correlation event sequence that links a fan failure event to a temperature warning event, and a temperature warning event to a temperature shutdown event.

correlation_rule: fan_fail_causes_temp_warn:

  description: 'This rule links a fan failure event and a
    temperature warning event on the same computer.'

  event_relation: Fan_Failure_Notification causes Temperature_Warning

  within: 10 minutes

  when: [
    Fan_Failure_Notification.hostname equals
      Temperature_Warning.hostname 
  ]


correlation_rule: temp_warning_causes_temp_shutdown:

  description: 'This rule links a temperature warning event and a
    temperature shutdown event on the same computer.'

  event_relation: Temperature_Warning causes Temperature_Shutdown

  within: 15 minutes

  when: [
    Temperature_Warning.hostname equals Temperature_Shutdown.hostname
  ]

Filters

Filters define the criteria that must be satisfied by an event before a rule is run. If the evaluation of a filter fails, the rule is skipped. The properties tested in a filter must be those defined for the class of the event. There are three types of filters:

Event filters

The event class specification tests the class of the event under analysis to see if the rule applies to that event class. The following list describes variations of a class specification and shows examples of each:

_
The _ variable (a single underscore character), also referred to as the anonymous variable, is instantiated with the name of the event class of the event under analysis. This variable means that you won't be retrieving the name of the event class for use later in the rule. The following example event filter succeeds for every event of every event class and instantiates the name of the event class to the anonymous variable:
event: _event of_class _ 
_class
The _class variable is instantiated with the name of the event class of the event under analysis. The following example event filter succeeds for every event of every event class and instantiates the _class variable with the name of the event class:
event: _event of_class _class 
class_name
This is the explicit name of an event class. The following filter succeeds if the event under analysis is of the Printer_Error_Cleared event class.
event: _event of_class 'Printer_Error_Cleared'
Note:

If class_name is a superclass of the event under analysis, the class specification part of the filter succeeds for all events that are subclasses of class_name. If the fire_on_non_leaf compiler directive is enabled, the class specification part of the filter also succeeds if class_name is a superclass (also referred to as a non-leaf node).
 

_class within [class_name1,...]
 
This class specification tests for one or more event classes in a list. If the event under analysis is a member of the list, the class specification part of the filter succeeds.

If any of the event class names in the list is a superclass, the class specification part of the filter succeeds for all events that are subclasses of the superclass.

If the fire_on_non_leaf directive is enabled, the class specification part of the filter also succeeds if event class is a superclass.

The list can either be specified as a variable that has been previously defined, or an explict list of class names. For lists, the brackets are required and event class names must be separated by a comma. The following filter succeeds if the event under analysis is one of those within the list and is an example of specifying an explicit list within the rule:
event: _event of_class 
    within ['Printer_Paper_Out',
            'Printer_Toner_Low',
            'Printer_Offline',
            'Printer_Output_Full',
            'Printer_Paper_Jam',
            'Printer_Door_Open'
    ]
Note:

You can optionally use the _class variable to capture the event class name for use later in the rule. For example, an event filter can look like the following example. If the event under analysis is one of those in the list, the _class variable is instantiated with the event class name.

event: _event of_class _class
    within ['Printer_Paper_Out',
            'Printer_Toner_Low',
            'Printer_Offline',
            'Printer_Output_Full',
            'Printer_Paper_Jam',
            'Printer_Door_Open'
    ]

The following example shows the use of a variable in place of a literal LIST_OF value:

;Class file
TEC_CLASS:
     Logfile_Base ISA EVENT
     DEFINES {
        alist: LIST_OF STRING, default=['Printer_Paper_Out',
                                        'Printer_Toner_Low',
                                        'Printer_Offline'];
     };
END
;Rules file
print_reset:
   ( event: _event of_class 'Printer_Error_Cleared'
     where [   status: equals 'OPEN',
              alist: _aclasslist     ],

reception_action:
    ( first_instance( event: _prt_ev of_class
           within _aclasslist
           where [ status: outside ['CLOSED'] ],
          _event - 3600 - 3600),
    change_event_status(_prt_ev, 'CLOSED') ) 
).
_class outside [class_name1, ...]
 
This class specification tests for one or more event classes in the form of a list. The brackets are required and event class names must be separated by a comma. If the event under analysis is a member of the list, the class specification part of the filter does not succeed. If any of the event class names in the list is a superclass, the class specification part of the filter does not succeed for all events that are subclasses of the superclass. If the fire_on_non_leaf compiler directive is enabled, the class specification part of the filter also does not succeed if the event class is a superclass. The following filter does not succeed if the event under analysis is one of those within the list:
event: _event of_class 
    outside ['Printer_Paper_Out',
             'Printer_Toner_Low',
             'Printer_Offline',
             'Printer_Output_Full',
             'Printer_Paper_Jam',
             'Printer_Door_Open'
    ]
Note:

You can optionally use the _class variable as described in the _class within specification.

Attribute conditions

You can optionally further restrict the criteria of an event filter with attribute conditions. Attribute conditions are the where clause of an event filter. Attribute conditions let you optionally specify tests that must be satisfied by certain attribute values of the event under analysis. You can also instantiate variables with attribute values in the attribute conditions section. This lets you use those variables later in the rule--similar to the _class variable in an event filter.

The event under analysis must have passed the class specification part of the event filter first, before the attribute conditions are tested. If the event passes both the class specification and attribute conditions of the event filter, the rule is run.

Attribute conditions can take the following general forms. The where clause begins with the where keyword and an open bracket. It ends with a closed bracket. The entire event filter, including the where clause, ends with a comma. If you don't specify any attribute conditions, you must still create an empty where clause.

Change rule filters

You can have the following two additional filters in change rules:

Sender filter

A sender filter of a change rule lets you filter on the sender of a change request. Senders of change requests can be one of the following:

agent
An event adapter.
engine
The rule engine.
operator(name)
An administrator from an event console.

The valid operators for a sender filter are:

equals
Tests whether the sender is a specific value. The following example tests whether the sender is the rule engine:
sender: equals engine,

The following example tests whether the sender is an operator. This example also instantiates a new variable, _sender, which can be used in a subsequent action. (The _x variable is not available outside the filter.)

sender: _sender equals operator(_x),
outside
Tests whether the sender is not equal to one of the values in a list. The following example tests whether the sender is an administrator:
sender: outside [agent,engine],
within
Tests whether the sender is equal to one of the values in a list. The following example tests whether the sender is member of a set of administrators, and if so, instantiates the _sender variable with the value:
sender: _sender within                    [operator('root@orange'),
                    operator('root@red'),
                    operator('root@blue')
                    ],

You can also use a sender filter to simply instantiate a variable with the value of the sender, as shown in the following example:

sender: _sender,
Attribute change filter

An attribute change filter of a change rule lets you filter on the requested change to an attribute value of an event.

The only required operator for an attribute change filter is set_to. The operand on the left side of the set_to operator is the name of the attribute to test. The operand on the right side of the set_to operator is the value specified in the requested change, or a comparison to the requested change. The operand on the right side of the set_to operator can be a single value or a list specification. For a list specification, a variable must be used to hold the value of the requested change.

The following operators are valid for comparisons in an attribute change filter:

The within operator tests whether an attribute value is equal to one of the values in a list, while the outside operator tests whether an attribute value is equal to a value not in the list.

Note:

Ensure that you use the appropriate operator for the data type to test.

The following examples show various attribute change filters:

Timer rule filters

You can have the following two additional filters in timer rules:

timer_info filter

A timer_info filter of a timer rule lets you filter on the timer information specified with the timer_info argument of the set_timer predicate. The set_timer predicate is used to set a timer on an incoming event. The timer_info argument of the set_timer predicate can be any value, such as an integer, string, or a structured item (such as a list).

The following operators are valid for comparisons in a timer_info filter:

The within operator tests whether an attribute value is equal to one of the values in a list, while the outside operator tests whether an attribute value is equal to a value not in the list.

Note:

Ensure that you use the appropriate operator for the data type to test.

The following examples show various timer_info filters:

timer_duration filter

A timer_duration filter of a timer rule lets you filter on the value specified for the timer_duration argument of the set_timer predicate. The set_timer predicate is used to set a timer on an incoming event. The timer_duration argument of the set_timer predicate is an integer value representing the number of seconds for the duration of the timer.

The following operators are valid for comparisons in a timer_duration filter:

The within operator tests whether an attribute value is equal to one of the values in a list, while the outside operator tests whether an attribute value is equal to a value not in the list.

Note:

Ensure that you use the appropriate operator for the data type to test.

The following examples show various timer_duration filters:

 

Note:

The actions described in this section only pertain to plain, change, and timer rules. Simple rules use simple conditions and simple actions, as described in General structure of a simple rule. Correlation rules use event relationships for their actions, as described in General structure of a correlation rule.

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.

Types of action

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

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:

  1. action Run each time a rule is triggered. This action is run for all events.
     
  2. 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.
     

  3. 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:

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:

 

Compound rules

Compound rules relate two events. Here's an example of a compound rule in English.If a HostUp event arrives, close any HostDown events for that hostname that happened within 10 minutes of the HostUp.

Compound rules involve two event instances. There are two ways the events can be related:

Prior to Tivoli Enterprise Console 2.5, programming was the only way to create rules. That capability still exists and in some cases it must be used.

Below is a programmed rule roughly comparable to one already shown in this unit. The rule is the one in which a PhysicalMemoryLow causes a SwapOut.

Rules consist of a header and a body. The header expresses the conditional part of a rule, and if an event is of a certain class with certain attributes (not shown in this example), then the action in the body will fire. The action consists of one or more templates. The template in this case is link_effect_to_cause.

The variables begin with an underscore. In this rule there are two variables — _lowmem and _swap_ev. The time window, which is expressed as “within 20 minutes” in the Graphical Rule Builder, is expressed as variable – (number of seconds before) – (number of seconds after). In this case, 10 minutes before and 10 minutes after the _memory_ev is received.

The all_instances in the action is an event specifier. It is a way of searching events for correlation.

The commas and syntax are precise but it is beyond the scope of this class to explain it in detail.

This diagram shows how a single problem in a distributed system can give rise to many problems and alerts. The real problem is with the Frame Relay service provider and that’s who has to fix it. However, this problem will often generate alerts from many internal monitoring systems. Without good event management, it is very difficult to determine which problems are real and which are just natural results of the Frame Relay problem. This means support will often either waste time examining imaginary problems or neglect real problems unrelated to the Frame Relay.

The final step of event management design categorizes each event by its role in the causal chain. A primary event is itself a root cause; when one is received, the appropriate response can be taken immediately. Depending on the circumstances, a secondary event may be either a symptom of a prior cause or a cause in itself; good event management will help determine if a secondary event should be addressed or if attention should be focused elsewhere. A clearing event simply indicates that a problem no longer exists. However, this may deserve investigation as well: if a network link cycles down and back up repeatedly, good event management can alert you this recurring failure.

TEC 3.7 introduced new functions to simplify the implementation of this event management analysis. The new functions make it easier to specify the relationships between events and then search for the appropriate event during processing. In addition, these functions separate the event relationships from the response actions. This separation permits a single rule to provide custom correlation for all the events that are handled the same way, greatly reducing the number of rules required and the implementation and support requirements.

A number of new predicates have been added to the Enterprise Console with two goals in mind.

The first goal is to make it easier and more efficient to perform correlation with the Enterprise Console based on the causal relationships. Two of the new predicates are used to create descriptions of the event relationships based on diagrams like the ones above; these descriptions are loaded into the Enterprise Console when it is started. The remaining predicates use these stored descriptions to search for related events when new events are received. In other words, the remaining predicates search for causal events, effect events, clearing events and clear "target" events (the problem events that are cleared) given a newly received reference event.

The second goal is to reduce the number of Enterprise Console rules by writing rules such that a single rule can handle many events. This is possible because (a) the processing for a given event is often determined by its role in the causal chain rather than its specific event class and (b) the event relationship information for all events is stored in the Enterprise Console when it is started. With these two facts in mind, the new predicates were designed to record and retrieve the stored information by event class, which can be determined for any event. This means that a single rule can process any number of different event classes provided those classes all require the same processing; the new predicates determine the class of the current event and retrieve the appropriate information automatically. Thus, the number of rules should be governed by the number of unique event management behaviours required rather than the number of events in the environment (each unique behaviour requires a rule to implement that behaviour).

The new functionality splits correlation into two parts. First, the event relationships are defined in the TEC rule engine at startup. Then, when an event is received, TEC can automatically search for the appropriate related event or events based on the stored relationship information for each type of event.

Here is an example of a simple event relationship network for an uninterruptible power supply and the corresponding relationship definition. The diagram shows that once a UPS goes on battery, its battery will run low and eventually discharge completely, sending an event at each stage. The definition statement lists these events in their logical order along with corresponding clearing events and correlation conditions; this completely describes the diagram and the correlation it prescribes. With this information, good event management can distinguish system problems from power failures and help diagnose battery problems. The heavy black arrow pointing off to the right indicates that once the UPS shuts down a machine, there will likely be many more related events from other sources that are not shown here such as host_unavailable, server_not_responding and the like.

This is a corresponding rule to process incoming events. The first action clause (in red) searches for a prior causal event: if a prior cause is found, the new event is merely a symptom so it is acknowledged, the two events are linked to record the relationship and processing concludes. If no prior cause is found, the second action clause (in blue) looks for a downstream effect that may have been detected and received before the new cause; if it finds one, the prior effect is acknowledged and the new causal event becomes the target for response. Note that this rule does not name any specific event class: it will perform this processing using the stored correlation information for every event, thereby replacing any number of rules in previous versions of TEC and greatly reducing the implementation and maintenance requirements. Note that, by ordering the rules in your rulebase appropriately, any event can be given the specific processing it requires.

To capitalize on ITEC’s ability to process events and respond based on what has already happened, more functionality has been added to simplify and accelerate event validation. This is based on the concept of event_criteria: sets of criteria are defined each with a unique name when TEC is started. During event processing, an event may be checked against any criteria set simply by giving the name of the set. The criteria support all major comparison operators and regular expressions.

To search the event cache for specific events more quickly and easily, there are new cache_search functions based on the event_criteria just introduced. Once again, uniquely named searches are defined at startup based on pre-defined criteria sets. In any rule, a cache search may be executed based on the named search to find any or all events that satisfy the specified criteria. The time range to search and the maximum number of events to search for may be specified. I’ll add that the existing search functions such as all_instances have been optimized internally but require no change in the rules.                                                                                   

In this example, the two event instances are the HostUp and the HostDown. The relationship is cancels, because one event closes the other. This section will explain the capabilities of the Rule Builder to create rules which relate two events to each other.

A compound rule expresses a relationship between two events, therefore, you are asked to provide a class for each event instance. Both instances may be of the same class. For example, an application might send in a heartbeat, i.e., a regular status indicating that the application is up. Each regular status report could close the previous one. If one remains open past a timeout period, that is an indication that the application has gone off-line.

This is similar to selecting a class type for events for simple rules, except that exactly two classes, which may be identical, are selected.

You need to specify the relationship between these two events. There are two relationships--one event can cause another event, and one event can cancel another. Each correlation has an implicit action, so you do not specify actions in compound rules.

The causal relationship links one event as the cause of the second event. For example, a HostDown causes an NFS_Server_Not_Responding. The power of linking is not felt at the time of linking. However, after linking any status changes in the cause automatically propagate to the effect. To continue with the example, if the HostDown is closed, the NFS_Server_Not_Responding will also close. This action is implicit. It cannot be changed or supplemented using the Rule Builder.

The causal relationship should be thought of as cause and effect. It does not mean that one event generates another event.

The cancels relationship, as illustrated in the opening to this section, means that one event closes another event. This closure takes place immediately. Another example would be a PrinterJamCleared cancels a PrinterJammed. The closure action is implicit. It cannot be changed or supplemented using the Rule Builder.

The time window appears on all compound rules. Suppose your site detected thirty Su_Failures. If all thirty failures happened in a short period of time rather than over an extended period of time, that implies a security concern. If a clearing event happens shortly after a problem event is reported, it is likely they are related. Time windows help to determine if events are related.

Time windows are also performance enhancers, since they limit the number of events to be searched for each correlation.

Events can arrive out of order due to network traffic jams and equipment failures. The time window allows for that, and does not assume causal events will arrive before effect events, even though, in the real world, the cause would always be created first.

Notice the dialog also allows you to specify a comparison between attributes in the two event instances.

In compound rules, you may optionally compare attributes in the two different events. In the paper jammed example, it would be wise to ensure that the paper jam and the printer off-line were happening on the same printer ( origin is the IP address) before linking them causally.

In compound rules, you can not test the value of an attribute against a literal value, for example, if hostname = "tivoli."

It may make sense to compare different attributes, depending on context. In the last example, we compared the origin attributes of the two events, that is, we compared the same attribute in both events. But if we were considering linking an NFS_Server_Not_Responding as an effect of a Host_Down, it would be advisable to test the server attribute of the NFS_Server_Not_Responding against the hostname attribute of the Host_Down. In many cases such as this example, it makes sense to compare different attributes in the two events.

Actions in compound rules are not specified because they are implicit. If one event caused another, when the first is closed or acknowledged, that status change propagates to the second. If one event cancels another, the second event is closed when the first is received. These actions execute, regardless of the order of arrival of the events, as long as they are both within the specified time window.

In this lesson, you will learn to build sophisticated responses using the Rule Editor capabilities.

The example of the performance monitoring application will be extended here. Suppose your application detects when a process is swapped out of main memory, when memory is dangerously low, and when more memory has been added to the configuration.

Frequent swapping can indicate a more serious problem--thrashing. The whole system is slowing down, because no one process can get its working set into memory. This can be caused by lack of memory. Adding memory solves the problem and alleviates the symptoms.

The following sections demonstrate how Tivoli Enterprise Console helps you identify, resolve, and dismiss these problems.

 

Processing events

To process an event, the rule engine compares the event against the applicable rules in the active rule base. When the event matches the event filter criteria for a rule, the rule is triggered. Rules are run one at a time, based on the order of their placement in the rule base, which is basically the rule order within each rule set and within rule-set order. Note that there are predicates that can alter the regular flow of control for rule evaluation, for example, the commit_action, commit_rule, and commit_set predicates alter the flow of control.

Events are stored in the event database after all applicable rules have been run for the event, except in the case where a rule contains an action to drop an event.

The rule engine processes events in the following order:

Processing timer expiration

The rule engine evaluates timer rules for an event, based on the expiration of a timer that was set on the event with the set_timer predicate. When the timer expires, the event is evaluated against all timer rules. For example, you can create a timer rule that specifies that all Su_Success events close one hour after reception, and then set a timer on all Su_Success events as they are received.

Processing the next transaction

Internally generated events, internal change requests, and redo requests are processed within the transaction for the event in which they were called. Each event transaction is completed before the next event transaction is processed; that is, a new event is not processed by the rule engine until all processing is complete for the current event.

Performance tips

The following tips are offered to improve rule engine performance:

Rule language reference

This chapter provides detailed descriptions and syntax for items that comprise the rule language. It is intended for users who are familiar with the rule concepts and need additional details about the rule language.

Naming conventions

The following table describes naming conventions for rule-related objects.

Object Convention
BAROC file Any file name supported by the operating system on which the event server is running.
Event class Any meaningful string, using uppercase, lowercase, or mixed characters. Valid characters for names are underscore (_), a-z (all cases), and 0-9.
Rule base Any meaningful string, using uppercase, lowercase, or mixed characters. Rule base names are displayed as labels for icons in dialogs so keep them short but meaningful. Valid characters for names are underscore (_), a-z (all cases), and 0-9. Directory paths to rule bases cannot contain any blank characters.
Rule set The physical file name of a rule set must be in the form of filename.rls. When referring to a rule set that has already been imported into a rule base, the .rls file name extension is implied and not entered. Also, do not use a period mark in a rule set name.
Rule pack A rule pack name must be in the form of filename.rpk.
Rule name Rule names can begin with a lowercase or uppercase letter; however, a rule name that begins with an uppercase letter must be enclosed within single quotation marks. Each rule within a rule set must have a unique name. Rule names should only contain alphabetic and numeric characters, except an underscore character is permitted, so long as it is not the first character of the name. Although rule names are not required, you should specify them with meaningful names to make rule traces easier to analyze.
Rule action Rule action names must begin with a lowercase letter and can optionally be enclosed within single quotation marks. Each action within a rule must have a unique name. Rule action names should only contain alphabetic and numeric characters, except an underscore character is permitted, so long as it is not the first character of the name. Although rule action names are not required, you should specify them with meaningful names to make rule traces easier to analyze.
Variables See Variables.

Variables

Variables in rules are usually identified by a leading underscore (_), although they can also begin with an uppercase letter instead of an underscore. The recommended convention is to use the form with a leading underscore, as it makes rules easier to understand.

No declaration of variables is required. If a variable is not instantiated, it is instantiated with a value in the first call where it is used.

Note:

When writing rules, pay special attention to the use of variables. Using a variable that has not been instantiated with a value can cause the rule not to work as intended in certain circumstances. For example, in an event filter where the variable _no_value is not instantiated, the following attribute condition would always succeed and instantiate the variables _origin and _no_value to the value of the origin attribute:

where [origin:_origin equals _no_value]

Variables are stored in memory. When the event server shuts down, they are lost. To store variables so they can be reloaded when the event server restarts, write them to a file before the event server shuts down, and then read them back in after the event server is restarted. Prolog predicates such as read and write can be used in rules to perform these actions. See read and write for additional information.

If you do not want strings that begin with an uppercase letter to be interpreted as variables, you must delimit them with single quotation marks. For example, Level_1 would be interpreted as a variable, whereas 'Level_1' would be interpreted as a string.

To illustrate the importance of variable syntax, the following rules perform exactly the same function. If the intent of the second rule is to filter on TEC_Start events only, the TEC_Start class specification should be delimited with single quotation marks in the event filter.

rule: unquoted_single_class1: (

  event: _event of_class _class
  % The name of the event class is stored in variable
  % _class.

    where [
      msg: equals 'unquoted event filter 1'
    ],

  action: (
    set_event_message(_event,'msg changed to %s',
                      [_class])
  )
).


rule: unquoted_single_class2: (
  event: _event of_class TEC_Start
  % The name of the event class is stored in  variable
  % TEC_Start. To filter on event class TEC_Start only, 
  % specify 'TEC_Start' (within quotes)

    where [
      msg: equals 'unquoted class filter 2'
    ],

  action: (
    set_event_message(_event,'msg changed to %s',
                      ['TEC_Start'])
  )
).

Regular variables

Regular variables provide a way of keeping information that can apply to a single rule or to the actions within a rule. The scope of a regular variable is as follows:

The naming convention for variables used to hold the value of an attribute is typically the attribute name prefixed with an underscore character, as shown in the following example in the where clause:

rule:
maintenance_started:
(event: _event of_class 'TEC_Maintenance'
    where [origin: _origin])

Global variables

Global variables provide a way of keeping information that can apply to multiple events in the memory of the rules engine, also referred to as the knowledge base. You might want to use global variables to keep track of the state of a particular object (for example, a host) or to keep counters that apply across multiple events.

The structure of a global variable consists of a group key and key, which are used together to identify the data being stored. A group key is also used to perform operations on all members of a group; for example, initializing all members to a value. A group key is typically a literal value. A key is usually dynamic and assigned its identity based on the attributes of an event. Both a group key and key can be arbitrary strings. The group key can be thought of as the name of an array and the key as an index into the array.

Multi-dimensional global variables can be defined by passing in a key that is derived from each dimension. For example, you can have a two-dimensional array using the origin and sub_origin attributes. Construct the key using the atomconcat and set_global_var predicates as shown in the following example:

atomconcat([_origin, _sub_origin], _key),
set_global_var('My group key', _key, 'My value')

The stored values of global variables can be of any type, such as integers, strings, lists, and so forth. To indicate the stored value is a list, enclose the list members within brackets ([ ]). Whenever you retrieve the list members data into regular variables, enclose the regular variables in brackets as shown in the following example:

set_global_var('My group key', _key, ['a', 'b', 'c']),
% Assign global variable values.

get_global_var('My group key', _key, [_var1, _var2, _var3],
               ['', '', ''])
% Retrieve global variable values into regular values
% The default initialization values ('') are null.

Manipulating global variables

There are several predicates available to manipulate global variables. In the following descriptions, the [i] and [o] notations following an argument indicate whether the argument is an input or output -- meaning whether the argument value is provided by you to use with the predicate or the value is returned by the predicate call, respectively.

The following example unifies the global variable value with the regular variable _into. If the global variable was not set, it is initialized to the value of _init and _into is set to that value.

get_global_var(_groupkey[i], _key[i], _into[o], _init[i])

The following example sets the global variable to the value of _to. The _groupkey and _key arguments must be specified.

set_global_var(_groupkey[i], _key[i], _to[i])

The following example resets all global variables that belong to the group to the value of _to.

reset_global_grp(_groupkey[i], _to[i])

The following example unifies the key and global variable values with the _key and _into regular variables for all global variables of the group in succession. The _groupkey argument must be specified. This predicate can be used to iterate over the members of a group. Note that _key is an output which can then be passed into the set_global_var predicate to change the value, if preferred.

get_global_grp(_groupkey[i], _key[o], _into[o])

Constants

String constants in the rule language are literal strings within single quotation marks. For example, 'WARNING', 'TEC_Error', and 'on' are all string constants.

Numeric constants do not require single quotation marks. For example, 9, 5.4, and 0xFF1953 are all numeric constants.

Comments

There are two forms of comment delimiters that can be used in rules. Text embedded within the /* and */ delimiters is treated as a comment and ignored by the compiler. You can create comments that span multiple lines using these delimiters. The other comment delimiter is the percentage symbol (%). All text after this character until the end of the single line is a comment. You cannot nest the first form of comments, as it will cause a compilation error. You can use a % within /* */ delimiters, but it is treated as literal text and not a comment delimiter.

In BAROC files, the single line comment delimiter is the number sign (#).

Creation, Editing, Compiling cycle

The CLI command to compile a rule base has the following syntax:

 wrb -comprules [-profile] [-trace] <rule base name>

Where:

The -trace option provides the rule trace functionality which is already known from earlier TEC versions.

Rule tracing can be activated either by using the CLI commands or the GUI.

Common Errors

Problems with rules

The most common problems related to rules are:

v Failure to recompile, reload, and activate the rule base.

v Failure to restart all Tivoli Enterprise Console processes after making changes to

the rule base.

For information about the Tivoli Enterprise Console processes, see

“Understanding event server processes” on page 82.

v Introduction of hidden characters or the Windows end-of-line (^M) character in

a rule set causing unpredictable results, such as the product failing to start or

the event console not being updated.

For more information about writing rules, refer to the IBM Tivoli Enterprise Console

Rule Developer’s Guide.

Enabling rule tracing

The Tivoli Enterprise Console product provides a rule tracing facility for

debugging problems related to rules. You can use the rule tracing facility to trace

rules at different levels of granularity. For example, you can trace all rules, a

particular rule set, part of a rule set, or a particular rule. To enable rule tracing,

follow these steps:

1. Compile the rule base with tracing enabled. To do this, use the wrb –comprules

–trace command with a trace directive specified in a rule or rule set.

You can also trace rules from the rule builder. To do this, select Trace Rules in

the Compile Rule Base dialog box.

2. Turn on tracing using the wsetesvrcfg command with the –t option.

3. Load and activate the compiled rule base.

88 IBM Tivoli Enterprise Console: User’s Guide

Note: When a rule base is compiled for the production environment, disable

rules tracing because rule tracing impacts event processing performance.

Rules generate trace output in a file. You can examine the resulting trace file to

analyze and debug problems related to rules. The name and location of the trace

file is set when the event server is configured.

The following table describes the information found in rule trace files.

Table 14. Output in rule trace files

Output Type Description

action The action set when the rule trace is entered and exited

condition The condition set when the rule trace is entered and exited

prolog calls The prolog calls trace, limited to a level of one depth

rule The trace rule whose header matches the current event

predicate The predicate used when entering, exiting, or failing a predicate

action

For more information and specific instructions for determining the level of

granularity for your trace results, refer to the IBM Tivoli Enterprise Console Rule

Developer’s Guide.

Forced cleaning of the event cache

When the internal event TEC_Notice event "Rule Cache full: forced cleaning" occurs, five percent of the events are removed from the cache. Events are removed in order by age, with the oldest events removed first.

Note: The event cache might have different contents than the event repository or an event console. This is because it is primed with events from the event repository when the IBM Tivoli Enterprise Console server is started.

If this TEC_Notice event is received, the solution is either to increase the size of the event cache or to reduce the time that events are kept in the event cache. For more information about setting these parameters, see the description of the wsetesvrcfg command in the IBM Tivoli Enterprise Console Reference Manual. These parameters can also be configured through the Tivoli Desktop using the Event Server Parameters dialog.

SG246614

Rules do not work properly

Compile the rules with tracing on and look at the trace output. Get the rule base and a list of events for which the behavior is not as anticipated. ass="pHeading4">Rule base loading is lengthy and fills up the file system

When rules are loaded into the event server, three directories in the rule base directory (Use the wlsrb -d command to see the directories) are copied into $DBDIR/tec/rb_dir; TEC_CLASSES, TEC_RULES, and TEC_TEMPLATES. In actuality, what really happens is everything under the rule base directory is copied to the $DBDIR/tec/rb_dir directory. If you did not create your rule base in a new or empty directory, then all of the other files and directories in your rule base directory will also get copied.

Forced clearing of the rules cache event

This event signifies that the rules cache is not large enough for the correlations being performed in the rulebase. The event cache, also known as the rules cache, is configurable in the event server parameters. The rules cache is maintained for rule correlation purposes. Adjust this value to hold all the events you will need to correlate on but not more than you need. Setting this value too high will adversely impact Tivoli Enterprise Console's performance.

Each rule in the rulebase will use this cache to correlate with incoming events. If the rulebase uses primitives like ALL_INSTANCES or ALL_DUPLICATES, and the rules cache is large, CPU usage may increase proportionately, and the time to process a rule through the rule base will increase as well. It is important to use templates, such as commit_rule (commits the rule set), commit_set (commits the whole rulebase), and commit_action (commits just the rule), to minimize the amount of time an event spends in rules processing.

In addition, CLOSED events can take up space in the rules cache and should be cleaned out proportionate to the number of events coming in and being processed and the number of events you want to correlate. The longer it takes to process events through the rulebase, the longer it will be for tec_reception to pull new events from the memory buffer, and thus from the reception log.

Server crashes in response to an event

Again, suspect an imperfectly crafted rule: One that perhaps does what you told it to do rather than what you wanted it to do! Load the default rule base. Stop and start the event server. Send the errant event.

Recommended Links

SG246614 Troubleshooting Tivoli Using the Latest Features

ETc

Each rule must specify only one trigger.

The first example is the most common idiom, where the triggering is in response to the arrival of an event instance. However, some conditions are only problems if persistent. In that case, action only happens when some specified frequency within a time range is exceeded. A single Su_Failure is probably a typo, but 100 within a minute may mean an automated break-in attempt.

In other cases, a change might stimulate the rule to act. When a causal event is closed, a rule can automatically close its effect. For example, if an NFS_File_Server_Down caused NFS_File_Server_Not_Responding events, a rule can close the NFS_File_Server_Not_Responding automatically when the NFS_File_Server_Down is closed.

Finally, in a help desk application, outstanding events might be upgraded in severity if they are not serviced, as in the last example at the beginning of this section the severity upgrade is scheduled to begin 15 minutes after the event arrives.

The following graphic shows how you could specify these different activation points.

The complete list of activation points is:

Compound rules

Compound rules relate two events. Here's an example of a compound rule in English. If a HostUp event arrives, close any HostDown events for that hostname that happened within 10 minutes of the HostUp.

In this example, the two event instances are the HostUp and the HostDown. The relationship is cancels, because one event closes the other. This section will explain the capabilities of the Rule Builder to create rules which relate two events to each other.

A compound rule expresses a relationship between two events, therefore, you are asked to provide a class for each event instance. Both instances may be of the same class. For example, an application might send in a heartbeat, i.e., a regular status indicating that the application is up. Each regular status report could close the previous one. If one remains open past a timeout period, that is an indication that the application has gone off-line.

This is similar to selecting a class type for events for simple rules, except that exactly two classes, which may be identical, are selected.

You need to specify the relationship between these two events. There are two relationships--one event can cause another event, and one event can cancel another. Each correlation has an implicit action, so you do not specify actions in compound rules.

The causal relationship

The causal relationship links one event as the cause of the second event. For example, a HostDown causes an NFS_Server_Not_Responding. The power of linking is not felt at the time of linking. However, after linking any status changes in the cause automatically propagate to the effect. To continue with the example, if the HostDown is closed, the NFS_Server_Not_Responding will also close. This action is implicit. It cannot be changed or supplemented using the Rule Builder.

The causal relationship should be thought of as cause and effect. It does not mean that one event generates another event.

The cancels relationship

The cancels relationship, as illustrated in the opening to this section, means that one event closes another event. This closure takes place immediately. Another example would be a PrinterJamCleared cancels a PrinterJammed. The closure action is implicit. It cannot be changed or supplemented using the Rule Builder.

The time window

The time window appears on all compound rules. Suppose your site detected thirty Su_Failures. If all thirty failures happened in a short period of time rather than over an extended period of time, that implies a security concern. If a clearing event happens shortly after a problem event is reported, it is likely they are related. Time windows help to determine if events are related.

Time windows are also performance enhancers, since they limit the number of events to be searched for each correlation.

Events can arrive out of order due to network traffic jams and equipment failures. The time window allows for that, and does not assume causal events will arrive before effect events, even though, in the real world, the cause would always be created first.

Notice the dialog also allows you to specify a comparison between attributes in the two event instances.

Compound Rule Attribute Conditions

In compound rules, you may optionally compare attributes in the two different events. In the paper jammed example, it would be wise to ensure that the paper jam and the printer off-line were happening on the same printer ( origin is the IP address) before linking them causally.

In compound rules, you can not test the value of an attribute against a literal value, for example, if hostname = "tivoli."

It may make sense to compare different attributes, depending on context. In the last example, we compared the origin attributes of the two events, that is, we compared the same attribute in both events. But if we were considering linking an NFS_Server_Not_Responding as an effect of a Host_Down, it would be advisable to test the server attribute of the NFS_Server_Not_Responding against the hostname attribute of the Host_Down. In many cases such as this example, it makes sense to compare different attributes in the two events.

Implicit Actions in Compound Rules

Actions in compound rules are not specified because they are implicit. If one event caused another, when the first is closed or acknowledged, that status change propagates to the second. If one event cancels another, the second event is closed when the first is received. These actions execute, regardless of the order of arrival of the events, as long as they are both within the specified time window.

Lesson 4: Examples of Creating Rules

In this lesson, you will learn to build sophisticated responses using the Rule Editor capabilities.

The example of the performance monitoring application will be extended here. Suppose your application detects:

Frequent swapping can indicate a more serious problem--thrashing. The whole system is slowing down, because no one process can get its working set into memory. This can be caused by lack of memory. Adding memory solves the problem and alleviates the symptoms.

The following sections demonstrate how Tivoli Enterprise Console helps you identify, resolve, and dismiss these problems.

You need to select an existing rule set, or name a new rule set and edit it. To edit an existing rule set, select Edit Rules from the rule base in which you intend to write rules.

Use the GUI Rule Builder to create a new rule set and name it appropriately. The left pointing arrow following the Set Name means that you must enter a carriage return.

Note : This convention with the arrow is an important one. Forgetting the Enter key is a common source of problems in a number of dialogs.

Select an existing rule set, or name a new rule set and edit it.

 

Then create a new simple rule.

Notice the buttons that let you specify Event Class, Conditions, and Actions.

In this example, you are writing rules for a fictitious performance monitoring tool. One of the events being monitored is SwapOut. If there are lots of SwapOut events in a short period of time, thrashing might be occurring and you should take action. Select the SwapOut event class.

When you click the Event Class button, the Select Class dialog box is displayed. Select the class(es) appropriate for the rule being written. If more than one class is selected, then an event instance of any of those classes will allow the rule to continue executing.

You can select additional qualifications by clicking the Conditions button in the Simple Rule dialog. In this case, we want to exclude closed events from consideration.

The Condition in Rule dialog box is displayed. Notice that the conditions are based on the attributes created with BAROC. The Relation choices are not in list, in list, and none. You can either type a value in the Attribute Value(s) field, or select from the pull-down list in the Select Value field.

The Condition Synopsis box displays a summary of the conditions you have specified. This allows you to build multiple conditions, one at a time.

Returning to the Simple Rule dialog, specify the actions for the rule to take. In this example, we are concerned with detecting thrashing, that is, a performance problem in which inefficiency results from not being able to retain a working set in the virtual memory due to memory constraints. The symptom that indicates this might be happening is frequent swapping.

Select the When frequency exceeds a limit choice from the Add pull-down list located below the When to Run box.

The actions are specified in the Actions in Rule dialog box. Our rule will detect a swap that occurs more than three times in two minutes. This can easily be changed. In reality, you would probably want a higher frequency count, but keep it low enough at this point so you can test your rule.

Notice the Action Synopsis shows what you specified. If the synopsis is not synchronized with the parameters provided, you probably forgot the carriage return.

On the right of the Actions in Rule dialog, below the Action(s) box, click the Add pull-down list. The choices are:

Let us say you want to change the severity to CRITICAL. In the real world, you would probably want to run a task or a script (command).

Depending on the choice you make, the rest of the screen reconfigures so you can enter arguments. In this case, a pull-down list of acceptable levels of severity is displayed.

The summary of your rule appears in the Action Synopsis box. You can change it by choosing Edit Rule (instead of New Rule) from the Rule pull-down menu in the Rule Set window. When it is acceptable to you, close the dialogs, remembering to save the rule base.

When the rule base is saved, the Rule Builder process creates a file called < rulebaseName >.rls in the TEC_RULES subdirectory of the rule base.

It is also possible to program rules without using the Rule Builder. While this provides more flexibility and control, and a greater repertoire of actions, it also requires greater effort. The Graphical Rule Builder is the first solution to writing rules, since it is easier to learn, easier to maintain, and provides better forward compatibility.

Prior to Tivoli Enterprise Console 2.5, programming was the only way to create rules. That capability still exists and in some cases it must be used.

The rules language is an external syntax which compiles into PROLOG. Because additional templates can be written in PROLOG, a knowledge of PROLOG is very helpful in creating custom rules.

While any given rule set must be maintained and developed in the same way as it was created, either with the Rule Builder or programming, it is important to note that a given rule base may have some rule sets that were created with the Rule Builder and some that were programmed.

Below is a programmed rule roughly comparable to one already shown in this unit. The rule is the one in which a PhysicalMemoryLow causes a SwapOut.

Rules consist of a header and a body. The header expresses the conditional part of a rule, and if an event is of a certain class with certain attributes (not shown in this example), then the action in the body will fire. The action consists of one or more templates. The template in this case is link_effect_to_cause.

The variables begin with an underscore. In this rule there are two variables — _lowmem and _swap_ev. The time window, which is expressed as “within 20 minutes” in the Graphical Rule Builder, is expressed as variable – (number of seconds before) – (number of seconds after). In this case, 10 minutes before and 10 minutes after the _memory_ev is received.

The all_instances in the action is an event specifier. It is a way of searching events for correlation.

The commas and syntax are precise but it is beyond the scope of this class to explain it in detail.



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019