
Alert Rules GUI
|
The Alert Rules GUI allows you to create and edit the alert rules that omosd uses to create alerts from events.
Starting the Alert Rules GUI
- In order to start the Alert Rules GUI, click on the Alert Rules icon on the desktop.
Navigating the Alert Rules GUI
Alert Rules tool bar
The Alert Rules GUI has a number of top-level tools: Create New Alert Rule, Clone Alert Rule, Edit Alert Rule, Delete Alert Rule, Increase Rule Priority, Decrease Rule Priority, Make Rule Priority Highest, Make Rule Priority Lowest, Refresh. These provides access to all of the functions available in the Alert Rules GUI.
|
|
The table below describes the items contained in the Alert Rule tool bar:
| Icon |
Filters menu item |
Description |
|
Create New Alert Rule |
Allows you to create, in a separate window, a new alert rule. |
 |
Clone Alert Rule |
Clones the alert rule, with the exception of the alert rule name. |
|
Edit Alert Rule |
Enables you to edit, in a separate window, an existing alert rule. |
|
Delete Alert Rule |
Permanently deletes an alert rule from the system. |
|
Increase Rule Priority |
Increases an alert rules priority so the rule fires before the rule in the row above. |
|
Decrease Rule Priority |
Decreases an alert rules priority so the rule fires after the rule in the row below. |
|
Make Rule Priority Highest |
Ensures that the alert rule fires first. |
|
Make Rule Priority Lowest |
Ensures that the alert rule fires last. |
|
Refresh |
Refreshes the alert rule list so that you are viewing the latest alert rules . |
The bottom bar of the Alert Rules GUI contains two buttons:
- Close: closes the Alert Rules GUI.
- Save Priorities: saves the alert rules firing order as shown in the Alert Rules GUI.
The table below describes the column headings for the Alert Rules table located below the top-level tool bar:
| Column heading |
Description |
| Name |
Alert name |
| Agent |
Agent name |
| Description |
Description of the alert rule |
Editing the Alert Rules table
In the Alert Rules table, you can add a new, or remove an existing column heading:
- From the Alert Rules table, click on a column heading to display the drop down menu arrow.
- From the drop down menu list, select Columns.
- From the attribute drop down menu list, tick a check box to add an attribute to the table, or de-select a check box to remove the attribute from the table.
Creating a new alert rule
Clicking on Create New Alert Rule, or Edit Alert Rule, pops up an Alert Rule Editor in a separate window.
Alert Rule Editor
You can use the Alert Rule Editor to create new alert rules, and to edit the properties of existing alert rules.
The table below describes the editable fields contained in the Alert Rule Editor.
Please be advised all references to template strings refer to $ syntax messages. For further information, please refer to the section on Template strings and/or the section on RiverMuse $ syntax.
| Column heading |
Description |
| Rule Name |
Name of the rule. |
| Description |
Description of the alert rule. |
| Filter |
A string of Rule Definition Language. You can edit the field manually, or with assistance from the Alert Rule Filter Wizard. |
| Agent |
Name of the Agent that generates the event. Rules can only be run against events that this agent generates. |
| Event Agent |
A template string defining the Agent name given in the alert rule. |
| Agent Entity |
A template string identifying the Agent host. |
| Discriminator |
A template string distinguishing which alert relates to which event. |
| Severity |
A template string defining the severity level associated with an alert: Clear, Informational, Warning, Minor, Major, Critical. |
| Owner |
A template string identifying an owner of the alert from a list of previously registered users in the User Management GUI. |
| Token 1 - 6 |
Template strings for tokens. |
Template strings
A template is a string that includes some replacement characters, which RiverMuse calls properties (after rsyslog terminology). You can access these properties by including their name after a dollar sign inside a template.
For example, if an event occurs and the event's message reads:
*The template "$alert_msg" will expand to "May 27 14:42:01 incvm
sendmail[STAGING:19717]: n4RDg1xu019716: to=<root@localhost.localdomain>".
Additional properties can be defined in RiverMuse rsyslogd-lite configuration files. These files are located at: /opt/rivermuse/etc/rsyslog/instances-available/
by default.
These files define properties, by using the ActionOmomosField keyword. The properties are then passed to omosd. For example, $ActionOmomosField access_uid means a property called access_uid will be passed to omosd. The actual definition of $ActionOmomosField access_uid is definied later in the configuration file a $template access_uid,"%msg:R,ERE,0,BLANK,2:[^ ]*--end%"
For further information on defining templates using rsyslogd refer to the rsyslog website.
Alert Rule Filter Wizard
The Alert Rule Filter Wizard window enables you to generate a new logical filter for the generation of alerts from events for a new alert rule; as well as, editing a filter for an existing alert rule.
The table below describes the top level menu bar for the Alert Rule Filter Wizard.
| Name |
Description |
| CLAUSE |
Final leaf of logical filter, returning true or false. You must insert after the selected element. Typically compares a variable returned by the agent with a string or integer value; however, may also involve user defined variables (permitted naming letters, underscores and hyphens) such as the templates defined by rsyslog-lite's configuration files in /opt/rivermuse/etc/rsyslog/instances-available/.
Variables may have a simple mathematical calculation performed on them via the evaluation statement, e.g., eval($t0%8)=4 |
| NOT |
Logical negations, reverses the true/false value of the child node. Insert prior to the selected node. |
| AND/OR before |
Logical AND or OR, insert prior to the selected node. |
| AND/OR following |
Logical AND or OR, insert as a child node to the selected element. |
| SUBQUERY |
Currently unimplemented. In future releases, SUBQUERY will form a join on another database table. |
| DELETE ALL |
Deletes the selected node and all its children. |
| DELETE |
Deletes the selected node and re-parents its children. If more then a single child is present, for example, NOT A AND B, where AND is the child of the NOT clause, attempting to delete the AND will fail because NOT can only have one child. |
How to create a new ping fail alert rule
The following is an example that you can follow through step-by-step to accustom yourself to using the Alert Rule GUI for creating new alert rules.
You are required to build a ping fail alert rule so that omosd can run the rule on receiving a ping fail.
- From the Alert Rules GUI, click on Create New Alert Rule.
- In the Rule Name text box, type in PingFail.
- In the Description text box, type in $alert_msg.
- Next to the Filter text box, click on the Alert Rule Filter Wizard icon. Create the following filter, as shown in the How to create a filter in the section below.
- In the Agent text box, type the name of the Agent that will generate the alert, syslog.
- In the Event Agent text box, type the Agent name given in the alert using $ syntax, $agent_name.
- In the Agent Entity text box, type the Agent host, $agent_host.
- In the Discriminator text box, construct a unique string which will control deduplication. A good rule of thumb is this string should contain at least the entity from where the event has come, and the name of the alert rule: $agent_name$alert_host$rule_name
- In the Severity text box, select from the drop down menu, the severity identified with the alert rule, $Critical.
- In the Owner text box, select from the drop down menu, the owner of the alert, usually user nobody: $Nobody.
- Click on Save. Before any new rules become active, you must instruct omosd to re-read the alert rules.

How to create a filter for a ping fail alert rule
The following instructions will create a filter for a ping fail alert rule; thereby, providing a realistic example.
- Open the Alert Rule Filter Wizard by clicking on the icon next to the Filter field in the Alert Rule Definition window.
- From the Alert Rule Filter Wizard, select CLAUSE.
- From the right hand side of the Alert Rule Filter Wizard window, in the Attribute drop down list, select alert_prog.
- Underneath the Attribute drop down list, in the operators drop down list, select =.
- In the value text box type pinger and click on Apply.
- From the left hand side of the Alert Rule Filter Wizard window, highlight the newly created clause, and click on AND/OR before.
- From the right hand side of the Alert Rule Filter Wizard window, click in the AND radio button and click on Apply.
- From the left hand side of the Alert Rule Filter Wizard window, select the AND, and then click on CLAUSE.
- From the right hand side of the Alert Rule Filter Wizard window, in the Attribute drop down list, select alert_msg.
- Underneath the Attribute drop down list, in the operators drop down list, select LIKE.
- In the value text box type ".Fail." and click on Apply.
- Click on Apply. RiverMuse will generate the text filter from the graphical filter tree and place this in the Alert Rule Editor window Filter column.

Instructing omosd
Before any new rules become active, you must instruct omosd to re-read the alert rules by sending omosd a SIGHUP signal, or restarting omosd in the Process Management GUI.
Alternatively, via the command line you can type the following:
- Display the process list for omosd processes on the server running omosd by typing in the following directory /opt/rivermuse/sbin/:
- Direct omosd to re-read the alert rules by sending a SIGHUP command:
Worked example for editing an alert rule
- From the Alert Rules GUI, select the alert rule you want to edit.
- From the Alert Rules GUI, click on Edit Alert Rule icon.
- In the Alert Rule Editor, edit the appropriate fields.
- Click on Save. The changes will be instantly updated in the Alert Rules GUI. Click on Close when you have finished editing the alert rule.
Cloning an alert rule
If you want to have two similar rules, for example:
Cloning allows such rules to be created quickly. You should never have two rules with the same filter because only the one with the "highest" priority will run.
How to clone an alert rule
- From the Alert Rules GUI, select the alert rule you want to clone.
- From the Alert Rules GUI, click on Clone Alert Rule icon.
- In the Confirm window, click on Yes.
- In the Rule Name field, enter an applicable alert rule name.
- Click on Save&Close.
How to delete an alert rule
- From the Alert Rules GUI, select the alert rule you want to delete.
- From the Alert Rules GUI, click on Delete Alert Rule.
- In the pop-up window, click OK. The alert rule will now be permanently deleted.
How to change the firing priority for an alert rule
The firing priority controls the order in which alert rules are applied by omosd to an event being reported by an agent. The system will execute alert rules in the order of increasing priority. The first rule whose filter returns TRUE is run by omosd, and the system then ceases consideration of rules of higher priority. Control over the order of execution in this way allows the implementer, for example, to define a default rule which is applied after omosd is unable to match a lower priority rule to an incoming event. You should as a matter of implementation design, ensure that rules of higher priority have more general filters than those of lower priority.
- From the Alert Rules GUI, select the alert rule you want to fire first, or fire last.
- From the Alert Rules GUI, click on either the Make Rule Priority Highest icon, or Make Rule Priority Lowest icon. The Alert Rules GUI will update the list of alert rules accordingly.
Or
- If you want to change the firing priority but not sort the priority as first or last, click on either the Increase Rule Priority or Decrease Rule Priority icon.
How to refresh the alert rule list
- From the Alert Rules GUI, select refresh.
- The list of alert rules will automatically refresh.
|
|
|