Actions - Scripts and Emails
Last updated: September 12. 2012
Actions allow you to do several things upon the arrival of certain messages or user interaction. They are commonly used for notifying non-monitoring people via Email, transfer events into a ticket system and similar stuff. The Event Console allows you to perform two kinds of actions:
Those actions can be triggered in two situations:
In order to use actions you first need to configure them. This is done in the Global Settings in den section Event Console:
The following screenshots shows an example of an action of the type Email:
2.1. Action ID
Just like rules every action has a fixed internal ID. This ID is used in the rules when referring to actions. Better do never change the IDs of existing actions. Otherwise you loose the reference to existing rules.
When you check this box then the action will not be available as a command in the status GUI. It will only be displayed in the rule configuration for such actions that are directly executed when the rule triggers.
2.5. Type of Action
Here you can select Send Email or Execute Shell Script. Emails are being sent to a fixed address that you can configure. In both three fields Recipient Email address, Subject and Body you can use placeholders in order to insert information parts of the actual event.
The following table shows some of the available macros. The exact table will be show in the context help (available via a click on ).
An alternative to sending an Email is executing a custom shell script. You can put the code directly into the text area in the configuration. It will be executed in the following way:
Please make sure that your script is not taking too much execution time. During the execution of the script the event daemon is blocked. If that is a problem for you, a trick is to make the script create an at-Job:
echo "/usr/local/bin/my_script" | at now
This will schedule the execution of a job right now, but the atd will run this asynchronously. Of course you need atd running for this to work.