DLI LPC9, User Manual

Page: 47 / 81

46 CONTENTS
8.3 Notification rules
The rule system is centered around two kinds of entities:
• condition, which determines if a rule is matched, and
• action, which determines what happens if it matches.
Notification rules
# Condition Action Operations
1 outlet==1
message="The up escalator is down!"
severity=CRITICAL
2 severity>=CRITICAL
notify("admin")
3
Submit
Notification rule configuration
A condition is a Lua expression, while rules are Lua blocks (may contain several statements).
Roughly, the condition/action table is equivalent to:
if condition1 then action1 end
if condition2 then action2 end
if condition3 then action3 end
...
However, an important difference is that if a condition would cause an error, the condition is considered false instead;
the corresponding action not taken, but the rule check goes on.
Additionally, an empty condition is equivalent to true , and the corresponding action is unconditionally taken. To
disable an action without deleting it, you can use an explicitly false condition false or a condition that's not a valid
Lua expression, e.g.
-
. To keep the condition text, you can wrap it with
false and (...)
.
Rules are applied from the first one to the last one, so order is important. The "Operations" column contains buttons
which make manipulating rule order easier.
Though you can filter events by the type identifier, it's not necessary in many cases. For example, the condition
auth_allowed==false
will match only
dli.auth.login_denied
events, as
auth_allowed
is set to
false
for those events only. This is notably distinct from a
not auth_allowed
condition, which will match all
sorts of messages which don't have an
auth_allowed
property.
Tricks which allow running code in the condition (as opposed to the action) are possible but discouraged.
DLI LPC9 User’s Guide: 1.7.24.0