Receiving alerts (classic)
Some functionality described in this document is linked with Finder (classic).
Nexthink Finder is a Windows-only desktop application whose functionality is now available within the Nexthink web interface. Nexthink can now be used directly from a browser and most functions no longer require an additional desktop application.
Alerts allow the system to automatically notify you of any particular issue within your IT infrastructure. Alerts can be received via email, in the Nexthink web interface for service-based alerts, or in the Device view of Finder for investigation-based alerts.
Below is a table that summarizes the types of alerts, the potential receivers of alerts and the possible mechanisms to send alerts:
Alert type | Recipient | Sending mechanism |
|---|---|---|
Investigation-based alert |
|
|
Service-based alert |
|
|
Receiving service-based alerts
The Nexthink web interface can generate service-based alerts, which are always related to service dashboards. The triggering of 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 Service Alerts of the Nexthink web interface. In addition, the Nexthink web interface 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 every 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 over the last hour.
For example, let us suppose that you set the ratio of devices with errors in a service to 10% and 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 period, the Nexthink web interface 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 has 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 from 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 now becomes 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, be aware 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-minute 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 subscribers 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. To use our previous example once again, 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 corresponding 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
To see information about the occurrences of service-based alerts in the Nexthink web interface:
Select Alerts and Diagnostics from the main menu.
Click on My Service Alerts in the navigation panel to view the list of alerts.
If an alert is still active, a bell icon is displayed in the first column of the table for a specific alert.
Click on History in the navigation panel 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 page.
In My Service 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 appears to its right.
Click the info icon to see the details of the alert.
In the dialog box 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 Finder with your user account.
Click the Settings section of the accordion on the left-hand side of 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 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 have been assigned to you because of your roles:
Select Alerts and Diagnostics from the main menu.
Click on My Service Alerts in the navigation panel to view the list of alerts.
There you have the list of the alerts that you added to the Nexthink web interface 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.