Creating custom monitors

To create a custom monitor, from Alerts and Diagnostics > Manage alerts in the navigation panel:

1. Click on the New monitor button in the top-right corner of the page to open the monitor configuration.

2. Fill in the fields under the General tab.

3. Define the NQL Query and conditions tab.

   • Including Trigger condition and Scheduling frequency.

4. Configure Notifications via email or webhooks for proactive alert management.

Configuring General monitor settings

From the New monitor configuration page, fill in the following fields under the General tab.

• Trigger: Custom monitors offer the Schedule trigger method used for periodic checks. Set specific intervals in the scheduling frequency section in the Query and conditions tab.

• Type: Custom monitors offer the following Types of detection modes:

• Name: Provide a meaningful name for the monitor. The system uses this name to send notifications and visualize monitors on the Alerts overview page.

• NQL ID: The system automatically generates a unique identifier from the monitor Name. Use the NQL ID to query this monitor within Nexthink.

  • You can only edit the NQL ID during the monitor creation, using the following characters a-z, 0-9, _.

  • You cannot create a monitor with an NQL ID that was used by a deleted monitor until there are no events in the system still associated with the deleted monitor (30 days max).

• Priority: Set the priority level. The default level is medium.

• Tags: Create custom tags for monitors. This enables you to filter alerts in the Alerts overview and in Webhook integrations. Currently, you can define up to ten tags per monitor.

Defining NQL Query and conditions for a custom monitor

From the monitor configuration page, fill in the following fields under the Query and conditions tab.

If needed, click the Show in Investigations button to view the query investigation results.

1. Write the NQL query to define the metrics to monitor. With NQL, you can:

   • Select one or multiple metrics.

   • Specify the scope using a where clause.

   • Define alert granularity with time aggregation and the by keyword for grouping.

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

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

execution.crashes during past 24h
| summarize 
  total_number_of_crashes = count(), 
  devices_with_crashes = device.count()

devices
| with antiviruses
| where is_up_to_date == no

devices
| with antiviruses
| where is_up_to_date == no
| compute device_count = count()

execution.crashes during past 24h
| summarize total_number_of_crashes = count()
| where total_number_of_crashes >= 10

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

execution.crashes during past 24h
| where binary.name == "excel.exe"
| summarize total_number_of_crashes = count()

execution.crashes during past 24h
| summarize total_number_of_crashes = count() by binary.name

1. Define Trigger conditions that activate alerts. Trigger conditions are sensitive to the chosen detection Type for the monitor. Use each metric computed in the NQL query to narrow down the condition.

Trigger conditions for Metric threshold

In trigger conditions for monitors with a Metric threshold detection, the monitor triggers alerts based on relational operators—greater than or equal to, less than or equal to—against the value you set.

The system triggers the alert when all trigger conditions are met.

Trigger conditions for Metric change

In trigger conditions for monitors with Metric change detection:

• The first trigger condition represents the deviation rule—higher or lower—that proportionally compares the current metric to the baseline (7-day global average).

• Additional trigger conditions activate the alert based on relational operators—greater than or equal to, less than or equal to—against the defined threshold.

The system triggers the alert when all trigger conditions are met.

In the example below, the first trigger condition activates an alert when the CPU Usage value doubles the metric average over the last 7 days.

These trigger conditions apply to both Schedule and Events-trigger monitors.

Trigger conditions for Metric seasonal change

In trigger conditions for monitors with Metric seasonal change detection:

• The first trigger condition sets the sensitivity band or range computed the from time-of-day baseline from the last 7 days. The monitor triggers an alert when the current metric value falls outside the selected standard deviation range for that time slot:

  • slightly = one standard deviation (±1σ)

  • moderately = two times the standard deviation (±2σ)

  • highly = three times the standard deviation (±3σ)

• Additional trigger conditions activate the alert based on relational operators—greater than or equal to, less than or equal to—against the defined threshold.

The system triggers the alert when all trigger conditions are met.

In the example below, the first trigger condition activates an alert when the Percentage of failed connections is outside the band two standard deviations (±2σ) from the baseline.

1. Set the Scheduling frequency of the monitor to determine how often the system evaluates the trigger condition.

   • The possible timeframes are 15 min, 1 hour, 3 hours, 6 hours, 12 hours, 24 hours, 48 hours and 7 days. These timeframes depend on the monitor NQL query ( during past clause) and the configured detection method:

     • For Metric change, the scheduling frequency ranges from 15 minutes to several days.

     • For Metric seasonal change, the maximum scheduling frequency is 24 hours, as more than 1-day frequency does not contribute to computing the mean for the same slot across the last 7 days.

device_performance.boots during past 24h

device_performance.boots during past 7d

session.events during past 1h

session.events during past 24h

execution.events during past 1h

execution.events during past 24h

execution.events during past 7d

session.vdi_events during past 1h

session.vdi_events during past 7d

1. Choose an alert auto-recovery option. In many alert scenarios, the monitor does not need to extend the recovery period by 72 hours, as the Trigger condition is normalized:

   • In these cases, recover alerts immediately after the monitor's first evaluation returns no data due to inactivity.

   • On the contrary, you may decide to wait 72 hours to, for example, account for a weekend break and keep the alert open during this inactivity period—instead of closing and opening a new alert.

Creating custom monitors for virtual desktops (VDI)

While built-in monitors for virtual desktops (VDI) provide out-of-the-box functionality with partial customization, you can create custom VDI monitors for specific organizational needs.

Consider the following when creating custom VDI monitors:

• Only the Schedule trigger, with a minimum granularity of 15 minutes is available for custom VDI monitors.

• Use VDI-related NQL tables and fields in the Query and conditions. For example, the query below calculates the average network latency per desktop pool.

  • If needed, you may add trigger conditions to activate an alert when the average latency in the pool exceeds a threshold value, for example, 50ms.

session.vdi_events during past 15min
| where session.vdi_event.network_rtt != null
| summarize average_network_latency = network_rtt.avg(), 
total_number_of_sessions = vdi_session.count() by vdi_session.desktop_pool

RELATED TOPICS

• Detecting issues impacting multiple devices

• Detecting issues impacting a single device or user

• Nexthink Library

• Product configuration