Generic SCE Rules

One of the great flexabilities of TEC is the capability to define new BAROC classes to meet specific needs. More often than not, this leads to literally hundreds of classes defined for a given rule base and unless managed properly the sheer number of classes can result in many specific rules, each firing on a specific event class.

The TEC rule language gives programmers the ability to manage the complexity by using BAROC class inheritance. You can write rules to fire on all Logfile_Base derived events or all ITM events. The relatively new State Based Correlation Engine (SCE) does not have this ability. The events it processes are not BAROC objects so the SCE can not evaluate BAROC class inheritance, attribute correctness, or even tell if the event class exists in a rule base at all.

When you write an SCE XML rule you specify the class of events that need to trigger the rule using the eventType tag. As I mentioned before, the SCE has no inheritance knowledge so you can not use Logfile_Base and expect an Su_Fail event to trigger rule execution, only specific events of the class Logfile_Base. To get a SCE rule to fire on multiple classes you have two options: specify multiple eventType tags or specify no eventType.

If no eventType is used then a SCE rule wile fire on all events and you must use conditions contained within the tag to limit which events will trigger rule actions. For example:



ignoreMissingAttributes="true"/>






This rule will result in suppressing duplicate events within 30 seconds of each other as long as the source slot is set to LOGFILE. Remember, the SCE has no concept of the dup_detect BAROC facet so you have to specify what slots the state machine needs to track to identify duplicates. This is done using the attributeSet attribute of the tag. The important thing to keep in mind is that unlike TEC rules, the class name has nothing to do with identifying duplicate events. If I removed the msg slot from the attributeSet, the rule listed above would treat a Su_Success, a No_Disk_Space, or a Su_Failure as duplicates so long as the origin, sub_origin, and hostname slots were the same in each event.

Not specifying an eventType causes the SCE to evaluate the predicate conditions on each and every received by the engine. While this may have an impact on performance, it makes maintaining the XML rules much easier since you will not have to modify the XML each time a new class is added.

As I said earlier, you can also use multiple eventType tags in an XML rule to filter events and improve overall performance. Again, pay attention to the cloneable tag. If you defined every Logfile_Base derived class as an eventType tag in a rule, you will still have same problem as the previous example if your attributeSet is not specific enough.