The Rule Engine

Rules are the workhorse of WinSyslog. Except for the interactive display, all actions and processing carried out is configured by the rules defined. The rules are configured by the client and processed by the so-called "rule engine" inside the WinSyslog service.

There is also an online seminar available on WinSyslog's rule engine. To view it, please visit our Seminar's Online Site and select "WinSyslog Rule Engine Processing Explained".

You might already know something similar to the WinSyslog rule engine. Rule engines and rule bases are an extremely powerful tool and in widespread use in the industry. Examples of rule bases can be found at Checkpoint's FireWall One Firewall Rule Base or Cisco Routing filter - just to name a few.

The rule base consist of the rules as configured in the client. The rule engine is the process carrying out the rules. A rule base can contain no, one or an unlimited number or rules. However, if there is no rule at all defined, no action will ever be carried out by WinSyslog. Consequently, the client will issue a warning message in this case.

A rule has a description and associated match conditions and actions. The match conditions are called "criterias". These specify, when  a rule is to be carried out. Again, there can be no, one or many criterias for a single rule. If there is no criteria, the rule will always match. This is useful in many cases. If there is more than one criteria, all criterias need to match in order for the rule to match (logical AND). 

Actions associated with a rule specify what to do when the associated rule matches (and only the associated rule). Actions carry out the actual processing of a messages. For example, actions include logging a message to a flat file or database, sending it via email or forwarding it to another syslog daemon. There can be no, one or an unlimited number of actions associated with a rule. However, if no action is associated, the rule will not have any effect. Consequently, the client will issue a warning when writing the rule base. Rules without actions can be useful to temporarily disable a rule with complex criterias. If there are multiple actions, they are not guaranteed to be carried out in any specific order. If you definitely need an action to be carried out before another one, you currently need to define two rules.

Actions can be modified with action modifiers. These are the strings attached to a specific action. Action modifiers allow to customize a specific behavior of this action. It modifies only this action and only this one, other actions of the same type are not affected - regardless if the appear in the same rule or a totally different one. The use of the action modifier depends on the type of action. For example, with syslog forwarding it is the host the syslog message is to be forwarded to. With ODBC database logging it is the DSN and so on. If there is no action modifier, the values configured in the client's configuration tabs will be used. They are also used for all values that can not be modified via the action modifier (e.g. the SMTP server address for email forwarding).

Below find a screenshot of a rule base with a number of rules, criterias and and action modifier:

Sample Rule Base

But now that we know the elements, how are rules being processed? It's easy. Rules are strictly processed from top to bottom, or from number 1 to the last one (number 6 in our sample). Each rule is checked to see if it matches. If it does, all associated actions are carried out. Then, the rule engine advances to the next configured rule. Once again, it checks if it matches and - if it does - carries out the actions associated with that rule. Then come the next rule and so on. The rule engine stops when there are no more rules to be evaluated. It also stops if a rule contains a "discard" action.

The "discard action" is a very special and powerful action. It does not actually carry out any processing. In fact, it disables all further processing for a message as soon as it is found by the rule engine. Have a look at rule number 3 above. It contains the discard action. If a message matches that rule, actions 4, 5 and 6 will not be evaluated. even if there were a match in these rules, their actions won't be carried out. So what is the discard action good for? It is used to handle common situation where a number of well know messages - unimportant messages - should be filtered out so that the other rules do not need to take care of these messages. In many other products using rules bases, this is called the "block rule". Please note that with Adiscon's rule engine, there can be multiple block rules at multiple layers of the rule base giving you additional flexibility.

One last thing to mention: the rule base is applied to each and every message arriving at WinSyslog. By design, there is no way to modify the behavior of the rule base for the next message to be arrived. This ensures an always consistent processing of incoming messages.

While building and testing your rule base, please keep in mind that the WinSyslog service needs to be restarted to load a modified rule base. We are currently evaluating how to update the rule base dynamically from the client, but the current version does not support this. We care very much for your system performance and as such we have decided to bring dynamic refresh only if it does not interfere to much with the service resource usage. As soon as we reach that goal, dynamic update will be available. In the meantime, we hope you understand our design decision.

Important note to WinSyslog 3.0, 3.1 and 3.2 users: the rule engine supersedes the functionality of the action specific enabled/disable actions on the file, ODBC, etc. tabs of the client. Please note that actions can only be carried out by rules. So it is absolutely vital to configure rules in order to let WinSyslog do any useful work. The Rule wizard imports any pre 3.3 actions and converts them to rules if found (this feature is not available in the preview release).