Detecting issues impacting a single device or user

Refer to the Alerts FAQ to learn how to investigate and query devices associated with an existing alert, using NQL.

Detect an issue that occurs on a single device or for a single user, to help L1 support teams proactively respond and remediate before a user raises a ticket.

To configure a monitor that evaluates a metric per single device or user, create an NQL query that returns a list of devices with a computed metric without further aggregations. You can achieve this in two ways:

1. Start with the devices or users table, join either table with the events table and compute the metric.

devices
| with device_performance.system_crashes during past 7d
| compute total_number_of_system_crashes = number_of_system_crashes.sum()

1. Start with an events table, summarize the metric and add grouping by device.

device_performance.system_crashes during past 7d
| summarize total_number_of_system_crashes = number_of_system_crashes.sum() by device.collector.uid

Notifications:

The system sends notifications for each impacted device or user separately and includes the device or user name in the payload.

Alerts overview dashboard

In the Alerts overview dashboard, the alerts for all devices/users are combined and displayed in a single line. The impacted devices column informs you about the number of devices with alerts.

Considerations

• Do not use this type of query if you expect a large number of objects to trigger an alert at once. Nexthink sets a limit of 500 simultaneous triggers for one monitor. Consider using Data Export or Webhooks for reporting purposes to external systems.

• For this type of query do not use the summarize... by device.name syntax as it will not trigger an alert per device as you might expect.

NQL examples

Below is a list of NQL query examples to help you create and edit monitors. Review the queries and pick the one most similar to the monitor you are creating or editing. Copy the query and adjust it to your use case, including the thresholds that have been provided as an example.

Devices with a high number of system crashes per week ( >=3)

This alert is triggered per device with a device name in the payload.

devices
| with device_performance.system_crashes during past 7d 
| compute total_number_of_system_crashes = number_of_system_crashes.sum()
| sort total_number_of_system_crashes desc

or

device_performance.system_crashes during past 7d
| summarize total_number_of_system_crashes = number_of_system_crashes.sum() by device.collector.uid

In the second example, use the device.collector.uid for grouping. The system sends the device name in the notification.

Devices with a high system drive usage ratio in the last week ( >=90)

This alert is triggered per device with a device name in the payload.

devices during past 7d
| include device_performance.events during past 7d
| compute system_drive_usage_ratio_ = event.system_drive_usage.avg()/event.system_drive_capacity.avg()*100
| list system_drive_usage_ratio_

Unauthorized users accessing Salesforce app

This alert is triggered per user for those who have accessed the Salesforce app and are not from the Marketing or Sales departments. The username is in the alert payload.

users during past 1d
| include web.events during past 1d
| where application.name == "Salesforce"
| compute usage_time_ = event.duration.sum()
| include session.events during past 1d
| where device.organization.entity !in ["MarketingSales"]
| compute interaction_time_ = event.user_interaction_time.sum()