Alarm Management


The alarm management module is based on the detection of events which internal (VNOC), SNMP thresholds, or sylogs sent by the managed devices and collected by the MSActivator. Alarm management is designed to provide email notifications to customers or managers, to send SNMP traps to an external trap server, or trigger predetermined automated processes.

The detection of events relies on rules configured at the super administrator level. Rule management is available for the super administrator (ncroot). The rules are defined globally and can be modified by the SOC team. The SOC team can modify the setting of the notification on a per-event and/or per-customer basis. The rules are executed on a periodic basis (the period frequency can be configured) and alarms are generated whenever a rule matches.

Rule Management

Rule management allows the super administrator to build, test and configure some rules.


Event Details

The event row can be expanded to display all the event fields as well as some additional fields.

Event fields

Internal events

The event below is an internal event (prefixed by VNOC) generated by the MSActivator.


  • _timestamp: this is the date when the event was actually stored in the MSActivator log indexer.
  • _ttl: this is the event Time To Leave in the log indexer cluster. "2w" stands for 2 weeks. This means that after 2 weeks this event will be removed from the system. This value is configurable systemwide and it should be set according to the event and logs retention period required for the MSActivator.


Alarms can also be triggered based on conditions that match certain syslogs sent by devices.

For example, the event below is triggered by a FortiGate when login attempts fail three times in a row:


Matching rules

When lots of rules are stored in the system, it is convenient to be able to get the list of the rules that match a specific event. The list of matching rules is available in the "matching rule(s)" tab of the event detail.

In the example below, you can see that the first result of the search for "Header Leakage*" would also be matched by the rule RESERVED.


The reason for this is the term "RESERVED" is also found in the first result of the search for "Header Leakage*", which houses the rule "RESERVED".


Rule Builder

The rule builder field is a simple textbox that allows the user to type rules based on the MSActivator search engine query syntax.


The rule is directly executed over the events that are available in the system.


You can select from a list of severities to associate to a rule.

A severity selection is required when building a rule. Selecting a severity will allow, for example, the system to raise an alarm whenever a certain severity is raised, whatever the event is.


Scope of a Rule

By default, a rule will apply to all customers on the system, and thus by extension, to every device in the system.

It is possible to create rules on a customer by customer basis. When creating customer specific rules, only one customer can be selected at a time.


Rule Criteria

Two types of criteria are available for configuration:

  • the alarm recipient
  • the alarm media


The alarm recipient is a list of checkboxes (customer, manager, privileged manager and administrator). It is mandatory to select at least one recipient for the rule. Each recipient is associated to a role as defined by the MSActivator RBAC. This selection determines who will be contacted when an alarm is triggered. An alarm can also be sent to a group of users based on the roles selected by the alarm recipient check-boxes.

Automated Process Execution

In addition to notifications, the user can configure the execution of a Workflow process when an alarm occurs.


To do this, select a service and a process using the list shown above.

From the advanced parameter section, select the fields that will be passed as parameters to the process.

The list of fields should match the list of variables that are defined for the process.

For example, the following process variables:


would be listed as:


Note: the parameters are used to run an aggregation query over the data index in the Elasticsearch cluster. Therefore it is not recommended to use the date or raw log fields as process parameters, because the value of these fields is different for each log.

Event Cumulation and Cumulation Time

When processes need to be executed based on events, there is a possibility to control the event cumulation. This is to avoid cases where lots of events are triggered (some security attack for example) but we don't want the system to execute 1 process per event.

By default the event cumulation (EC) is set to 10: ten events will have to be detected before the process is executed.

The default cumulation time is 15 minutes: the system will wait 15 minutes to trigger the process.

This event cumulation time (ET) defines a sliding window of ET minutes. A workflow is triggered when at least EC events have been detected in the sliding window of ET minutes.
Setting 0 to ET means an empty sliding window and no alarm can be found (this of course should be avoided).

The two parameters work together and whichever threshold is reached first will trigger the execution.


Setting the event cumulation (EC) to 0 means "real-time mode". This leads to:

  • have the fastest response time,
  • ensure that there is one workflow executed for one event matching the detection rule.

If EC is different from 0, a filter aggregates in one event the events detected at the same time for the same customer and the same device.

Rule Creation

To be applied, the rule must be saved in the system.

For example, in order to get notifications whenever login to the device fails due to an invalid password on a managed device, the rule below can be used and saved with a name (in this case, "LOGIN_FAILED"):


Rule Load and Update

To update an existing rule, the rule should be loaded first.


Then click "save rule".

Rule Deletion

To delete a rule, simply click on the red "X" and confirm the action when prompted.

Rule Application

A rule is applicable as soon as it is saved in the system.

If a rule has been created to send a email if a match is found, the system will start running the rule and possibly sending emails as soon as the rule is saved.

The MSActivator rule matching process is a rule with a period (in seconds) that can be configured with the configuration tool, accessed using the following path:

SEC Engine configuration->Initial Configuration->check_alert period

For more details read the Technical details chapter.

Alarm Management

Users can view their alarms from the customer portal or from the customer menu (Monitoring->Alarm)


The user can select the time range they wish to display (from the last 10 minutes to the past day). Users can also select the number of events to be displayed in the detailed view. The alarm summary view shows a list of events aggregated by severity, type and subtype. The detail view shows each event with the detail of the event that triggered the alarm.


Create a Rule to Send Alarm for SNMP Thresholds

SNMP thresholds can be configured using monitoring profiles. The SNMP threshold events are characterized by the keyword SNMPTHLD. The following search should bring back some results, provided that this kind of event has been raised and exists in the event index.


Create Rules to Send Alarm for Configuration Update

Configuration update events are generated by the MSActivator and look like this:

%VNOC-<severity level>-UPDATECONF: <message>

The following rule should match every configuration update related event, whether it failed or it succeded:


Or for configurations related to object:


In case of a configuration error, the MSActivator will raise an event %VNOC with a severity level 1 (%VNOC-1-UPDATECONF: <message>)

One possible way to detect PUSHCONFIG events that have failed is to filter the event by severity and only search for severity 1:


Another method to generate an alarm based on configuration failure is:


It is often useful to have multiple rule types for different types of configuration related events.

For example, license related issues can be detected by the rule below:


Create Rules to Send Alarm When Device Goes Down or Up

To trigger an alarm when an IPUP or an IPDOWN happens, use the rule below:


Create a Rule to Detect Security Events

Use the rule below to detect threat events detected by a UTM:


This rule can be made more specific to target specific threats. As shown below, you can use it to detect a threat were the destination port is 80:


Video Tutorial

Technical details

Configuration variables that modify the alarm checking process

There are many MSA components involved in the devices states acquisition that lead to potential alarms.
For syslogs the following process shows configuration values for fast alarms detection :

Execution periodicity

Configuration variable

Port 514

syslogd daemon
1 second (default = 60)

1 second
1 second (default = 10)
sms_parserd.conf : parse-files-lookup-period

polling *.esdata files
1 second
called by parserd, periodicity hard-coded


10 seconds (default = 60)

In command-line on sec node, the /opt/configurator/configure --expert command allows the configuration variables modifications.

The menu options for the following variables:

  • UBI_SMS_SYSLOG_AGREG_TIME => 4: SEC Engine configuration => 3: SEC Engine syslog configuration => 2: File aggregation time for syslogs (in sec)
  • UBI_ES_BULK_FILE_AGREGATION_TIME => 11: ElasticSearch configuration => 3: SEC Engine => 6: Time to wait before closing the ElasticSearch bulk log files
  • UBI_SMS_CHECK_ALERT_PERIOD => 4: SEC Engine configuration => 1: Initial Configuration => 31: check_alert period