Argent Alert Executors/Backup Consoles
The reason to implement Argent Alert Executors is that some alerts must be executed from a particular location. The most common situation is to send pager or SMS messages from a particular location to avoid long distance call rates.
There is another important consideration. In Argent AT Mother/Daughter architecture, the Daughter Supervising Engine fires events by communicating with the Argent Console Main Engine.
In case the connection is not available, Daughter Supervising Engine can cache the event requests until the connection is restored.
Argent Alert Executors can function like an emergency backup engine for Argent Console.
When Daughter Engines cannot send out event firing requests to the main Argent Console engine, it can ask the locally installed Argent Alert Executors to fire the alert first.
In the meantime, the event requests can still be cached until connection to the main Argent Console engine is restored. In fact, the Mother Supervising Engine behaves in the same way.
On remote engines that need the backup Argent Console engine feature, the Argent Alert Executor is defined by the registry:
HKLM\Software\Argent\ARGENT_CONSOLE\BACKUP_SERVERNAME
If for some reason, customers do not want to use the backup engine feature, this registry entry can be left blank. In the meantime, the normal Alert Executor functionality continues to work as per normal.
Note: Argent AT allows specifying actions at the Relator level, known as the “Instant Correction” field of a Rule in a Relator.
As a result, the action is executed immediately within the context of Relator. A typical example is to restart a service when some Rule is broken.
Say the monitored node is at the Daughter site. Argent Console Main Engines cannot restart the service through the Internet.
In Argent XT, we had to deploy an Alert Executor at the Daughter site to execute a Service Alert.
But customers do NOT need to do so in Argent AT.
Instead, customers can specify the Service Action in the Relator along with the rule. The point is, before the customer decides to deploy an Alert Executor, they should check if it is really needed.
Note: When Argent Alert Executors fire urgent alerts, it does not have a connection to the SQL database at the Argent Console main engine. As a result, there is no way to check if the same event is still pending, or the occurrence count has exceeded the threshold, the urgent alert is always fired.
To avoid the potential alert flooding, alerts of the same event won’t be fired within 30 minutes by default.
The number is controlled by the registry:
HKLM\Software\Argent\ARGENT_CONSOLE\Server\URGENT_EVENT_ALLOWED_LAPSE_MINUTE
To deploy Argent Alert Executors, it is simply an option in SETUP.EXE.
To determine where the alert should be handled, Argent AT uses the following logic:
-
If the Alert does not have the option of using ‘Node Specific Engine‘, the Alert is handled by the central Argent Console engine.
- If the Alert has the node specific option checked, first check the CMDB-X node properties to see if the node uses an Alert Executor. If it is used, the alert should be handled by the Alert Executor.
- If it is not specified, check the CMDB-X node properties of the belonging network group to see if an default Alert Executor is specified. If it is, the alert should be handled by the Alert Executor.
- Otherwise, the alert is handled by the central Argent Console engine.
