|
|
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 | |||||||
| 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:
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.
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.
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
)
).
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
)
).
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, '')
)
).
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 ) ).
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')
)
).
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
)
).
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')
)
).
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')
)
).
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
| Event Action | Description |
|---|---|
| change_event_severity | Specifies a new value for the severity attribute. Severity can be UNKNOWN, HARMLESS, WARNING, MINOR,
CRITICAL, and FATAL.
Syntax: change_event_severity(new_severity) |
| change_event_status | Specifies a new value for the status attribute. Status can be OPEN, RESPONSE, ACK, or CLOSED.
Syntax: change_event_status(new_status) |
| drop_duplicate_event | Checks for the existence of a duplicate event in the event cache having a status other than CLOSED
within a time window (in whole minutes). If one exists, the repeat_count attribute of the existing event is incremented
by one and the newly received event is dropped. Syntax: drop_duplicate_event(time_window) |
| exec_program | Runs a system command, shell script, or other program. The default search path is $BINDIR/TME/TEC.
The commands, scripts, or programs are run on the same node as the event server. See
exec_program for additional information about the arguments for this event action. The arguments for the exec_program
rule language predicate are similar. Note: For the exec_program event action in a simple rule, only event attributes are valid values for the _arg_list argument, unlike the exec_program rule language predicate for which you can specify any values for the _arg_list argument.Syntax: exec_program(prog_name, _format_string, _arg_list, watch_status) |
| exec_task | Runs a task from the specified task library. By default, tasks are run on the same node as the event
server. Proper access to a task library is necessary to use this action. See
exec_task for additional information about the arguments for this event action. The arguments for the exec_task
rule language predicate are similar. Note: For the exec_task event action in a simple rule, only event attributes are valid values for the _arg_list argument, unlike the exec_task rule language predicate for which you can specify any values for the _arg_list argument.Syntax: exec_task(task_name, format_string, _arg_list, watch_status) |
| forward_event | Sends an event to a different event server. There must be a ServerLocation option specified in the
tec_forward.conf file in the TEC_RULES subdirectory of the rule base. See the description of
forward_event for additional information about the tec_forward.conf file.
Syntax: forward_event() |
| set_event_message | Specifies the text for the msg attribute in the event. This can be an informational message or it
can contain the value of another attribute. See
set_event_message for additional information about the arguments for this event action. The arguments for the set_event_message
rule language predicate are similar.
Note: For the set_event_message event action in a simple rule, only event attribute names are valid values for the _value argument, unlike the set_event_message rule language predicate for which you can specify any values for the _value argument.Syntax: set_event_message(_format, [_value]) |
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').
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 ]
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 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:
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:
event: _event of_class _
event: _event of_class _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).
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') )
).
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.
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.
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.
The following example tests whether the value of the status attribute is OPEN. OPEN is delimited by single quotation marks because it begins with an uppercase letter and would be interpreted by the rule compiler as a variable if it was not enclosed in single quotation marks.
where [status: equals 'OPEN'],
The following example tests whether the value of the status attribute is either OPEN or ACK and instantiates the _status variable with the value:
where [status: _status within ['OPEN','ACK']],
The following example tests whether the value of the status attribute is anything other than CLOSED:
where [status: outside ['CLOSED']]
Ensure that you use the appropriate operator for the data type to test.
where [status: _status],
where [ status: _status outside ['CLOSED'], severity: equals 'CRITICAL', hostname: _hostname ],
You can have the following two additional filters in change rules:
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:
The valid operators for a sender filter are:
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),
sender: outside [agent,engine],
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,
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:
attribute: status set_to 'CLOSED',Note:
The slot keyword for an attribute change filter was used in earlier releases of the IBM Tivoli Enterprise Console product. The attribute keyword is now used. Although the slot keyword is still valid, it might be removed in a future release.
attribute: status set_to _newstatus,
attribute: status set_to _newstatus within ['ACK','CLOSED'],
attribute: repeat_count set_to _newrepeatcount greater_than 5,
attribute: administrator set_to _newadministrator within ['fred','wilma','betty'],
You can have the following two additional filters in timer rules:
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_info: equals 'Level 1',
timer_info: _timerinfo within ['Level 1','Level 2'],
timer_info: _timerinfo,
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:
timer_duration: equals 60,
timer_duration: _timerduration within ['60','90'],
timer_duration: _timerduration,
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.
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.
There are three types of rule actions, described as follows:
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.
The following example shows the usage of different action types:
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 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:
rule: test_rls: (
directive: fire_on_non_leaf,
event: _evt of_class within [ 'EVENT' ]
where [ ],
reception_action: action0:
(
drop_received_event
)
).
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.
create_event_sequence. This predicate is used to define a sequence of events, and any additional information pertaining to those events, that make up an event sequence. This information is loaded into the knowledge base of the rule engine at event server start-up and is used by rules that call correlation predicates. You can load it with a rule triggered by a TEC_Start event at event server start-up time.
create_clearing_event. This predicate is typically used to define a clearing event for one or more problem events that are not part of an event sequence. This predicate can be used to define any clearing event, even if the events it clears are specified in one or more event sequences.
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.
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:
The rule engine queues internally generated events and then processes them first after it has finished processing the current
transaction. Internally generated events are processed in first-in, first-out (FIFO) order. The internally generated event and all
modifications resulting from that event are included in a transaction.
The rule engine queues internal change requests and then processes them in FIFO order after the current transaction and all internally
generated events have been processed.
The rule engine queues redo requests and then processes them in FIFO order after the current transaction completes, all internally
generated events have been processed, and all internal change requests have been processed. A redo request directs the rule engine
to perform a new pass through the rules for a previously received event.
The rule engine queues external change requests and then process them in FIFO order after the current transaction completes,
all internally generated events have been processed, all internal change requests have been processed, and all redo requests have
been processed. When a change request is processed, only change rules are evaluated. The change request is applied to the event
only after all change rules have been evaluated.
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.
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.
The following tips are offered to improve rule engine performance:
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.
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 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 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 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.
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])
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.
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 (#).
wrb -comprules [-profile] [-trace] <rule base name>
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 tothe 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 ina 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 ConsoleRule 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 inthe 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 GuideNote:
When a rule base is compiled for the production environment, disablerules 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 RuleDeveloper’s Guide
.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.
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.
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.
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.
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 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 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:
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.
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard 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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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-Month : How 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
