Receiving alerts
Overview
Find below a table that summarizes the types of alerts, the potential receivers of the alert and the possible mechanisms to send the alert:
Receiving system alerts
Configure the email address of the admin account to receive system alerts. The Engine sends system alerts by email to inform the administrator of the status of the system. Remember that system alerts are predefined alerts that notify special circumstances detected by the Engine, such as internal errors or the expiration of your software license. No user can modify them.
To send emails, the Engine uses the SMTP configuration of the Appliance where it is installed. Only the main administrator receives emails from system alerts. In addition to sending system alerts via email, the Engine logs each occurrence of a system alert in the system log of the Appliance.
Receiving service-based alerts from the Portal
The Portal can generate service-based alerts, which are always related to service dashboards. The triggering of a service-based alerts depends therefore on the results of their corresponding service, as seen by each particular user (their view domain). When a service-based alert is triggered, it appears as active in the special dashboard My Alerts of the Portal. In addition, the Portal sends emails to subscribers of the alert both when the alert is triggered and when the alert terminates.
To determine when a service-based alert is triggered and terminated, it is important to know about the sliding window mechanism of services. The values of a service are sampled each 10 minutes, but these values are added along one hour intervals for the purpose of generating alerts. Thus, an alert will be triggered or terminated depending on the values collected by its associated service during the last hour.
For example, let us suppose that you set the ratio of devices with errors in a service to 10% and that you create an alert associated to this service. In the next 10 minutes, the service reports that 15 out of 100 devices are in error. Therefore, since the ratio of devices in error is 15% and there was no other previous data available for the last one hour, the Portal triggers the alert associated to the service. Now let us consider the status of the alert depending on the results of the service after the next interval of 10 minutes:
The service reports that no device used it
The accumulated value of the service for the last hour is still 15 devices in error out of 100; the same as in the previous 10 minutes. Therefore, the alert is still active. Following the same reasoning, if no one uses the service for one hour, the alert remains active until the end of the hour, when the first use reported (15%) lies behind the last hour window. At that point, the alert terminates.
The service reports that 5 out of 100 devices are in error
Supposing that the 100 devices that accessed the service during this interval are the same devices that accessed the service during the previous interval, the accumulated number of devices with error for the last hour are at least 15 (more if the 5 newly reported devices are not part of the 15). The alert is therefore still active.
The service reports that 15 out of 300 devices are in error
Supposing that the 15 devices with error are the same 15 devices with error of the previous interval, and that the 300 devices that accessed the service include the 100 devices of the previous interval, the ratio of devices in error to devices accessing the service becomes now 5%. Since 5% is lower than the threshold of 10% configured in the real-time service widget, the alert terminates immediately.
Another factor to take into account is the minimum number of devices impacted that you configured in the alert. If you set the option ignore until x or more devices are impacted, beware that impacted device in this context means device accessing the service and not device with error. In our previous example, the number of impacted devices during the first 10 minutes interval is therefore 100, and not 15.
Finally, it is important to note that the triggering of an alert also depends on the view domain of its subscribers. In the same way that the results of a service dashboard depend on the view domain of the user who watches them, a service-based alert is sent to one of its subcribers only if the the alert conditions are met within the view domain of that subscriber. That is, service-based alerts are triggered individually per each subscriber and not globally. Using again our previous example, if the value of 15 devices in error out of 100 (15%) was seen by a user with a complete view of the system and another user with a restricted view domain can only see 1 device in error out of 25 (4%), only the first user will receive the alert (>10%).
Moreover, if you have defined multiple hierarchies in your setup, each user has a view domain per hierarchy. An alert can be triggered when its conditions are met within any of these different view domains. The actual view domains in which the alert was triggered and their correspoding hierarchy are detailed in the email that the subscriber of the alert receives. Therefore, only one email is sent per alert and per subscriber even if the alert is triggered in multiple domains.
Viewing service-based alerts in the Portal
To see information about the occurrences of service-based alerts in the Portal:
Log in to the Portal as a particular user.
Click the bell icon in the top right of the Portal window and choose either:
My alerts, to see a table with the list of alerts to which you are subscribed and information on their last occurrence.
If an alert is still active, a bell icon is displayed in the first column of the My alerts table for that alert.
History, to see the past occurrences of the alerts to which you are subscribed.
It is possible to filter the results of the History table by hierarchy, alert name, and date by editing the controls on the top right of the dashboard.
In both dashboards My alerts and History, it is possible to look at the details of an alert, which enable you to break down the results by hierarchy levels:
Hover the mouse over the name of the alert in an entry of the table and an info icon (a little i with blue background) appears to its right.
Click the info icon to see the details of the alert.
In the dialog with the details, select the desired hierarchy from the list Display impact data for hierarchy.
Select a level of the hierarchy from the list Hierarchy level to get the results of the alert for a particular level only.
Optional: Click the right pointing arrow with the label CSV at the bottom right corner of the table to export the details of the alert to a CSV file.
Receiving alerts linked to roles
Even when you do not create alerts yourself, you can receive alerts that are assigned to you by the roles attributed to your user account. You cannot modify or delete any of the alerts that are linked to your roles. The alerts that can be linked to roles are of two types:
Investigation-based alerts
Service-based alerts
To see the investigation-based alerts that are attributed to you according to your roles:
Log in to the Finder with your user account.
Click the Settings section of the accordion on the left-hand side of the Finder.
Inside Settings, select Role-based alerts from the drop down list labeled Section. For each one of your roles, you see a folder holding the alerts that correspond to the role.
Moreover, in the Device view of the Finder, there is a separate alert timeline for each one of your assigned roles. Alerts on devices that are attributed to you because of your roles are displayed there.
To see the service-based alerts that got assigned to you because of your roles:
Log in to the Portal with your user account.
Click the bell icon in the top right corner of the window.
Select the dashboard My alerts.
There you have the list of the alerts that you added to your Portal or that were automatically added because they are mandatory for at least one of your roles. You can see if the alert is linked to a role in the last column.
RELATED TASKS
RELATED CONCEPT
Last updated