Customizing built-in monitors

To ensure accuracy, the system prevents editing certain fields of built-in monitors, including library monitors for virtual desktops (VDI).

However, you can create custom VDI monitors within certain limitations.

Customize System and Library monitors and use them as the starting point for a more complex monitor configuration that increases the relevancy of alerts. Remember that Nexthink updates to original library monitors do not keep the modifications you made.

To customize a built-in monitor, from Alerts and Diagnostics > Manage alerts in the navigation panel:

Open the action menu of a System or Library monitor and select Configure.
Customize the fields under the General tab.
Adapt the defined NQL Query and conditions tab.
- Including Trigger condition, Filter, ‘group-by’ clause and Scheduling frequency.
Check the configured Notifications via email or webhooks for proactive alert management.

Prerequisites and dependencies to use built-in monitors

The following library monitors require the Collaboration Experience expansion product:
- Call quality - Zoom number of poor calls (increase)
- Call quality - Teams number of poor calls (increase)
The following system monitors require Nexthink instances fully transitioned to Infinity :
- Binary connection establishment time increase
- Binary failed connection ratio increase
To use breakdown by location as an optional group by in device performance monitors, you need to enable the geolocation on the Product configuration page of the Administration module.

Customizing General fields of built-in monitors

From the monitor configuration page, check the following fields under the General tab:

Type: View the type of detection mode the monitor is using built-in monitors offer the following detection modes
- Metric threshold triggers an alert when the value of one or more metrics reaches a user-defined threshold.
- Metric change triggers an alert when the current metric value differs from the reference baseline, which is the average of the metric values retrieved over the past 7 days.
- Metric Seasonal Change triggers an alert when the current metric value deviates beyond its expected average range—calculated using standard deviations from values collected over the past 7 days.
- Global detection triggers an alert when a specified number of devices use a particular binary version or binary configuration that performs worse than other versions or configurations across organizations using Nexthink. Adjust the threshold for this alert within your organization.
Name: View the name of the built-in monitor. The system uses this name to send notifications and visualize monitors on the Alerts overview page.
NQL ID: View the monitor NQL ID. Use it to query this monitor using NQL.
- The Global issue detection type is based on anonymized data from all organizations using Nexthink and, therefore, does not require an NQL query.

Adapting predefined Query and conditions

From the monitor configuration page, adapt the following fields under the Query and conditions tab:

A built-in monitor uses a predefined query to determine which metric it evaluates. View the query directly in Investigations by clicking on the Show in Investigations button.

Enhancing configured Trigger condition

Customize the existing Trigger condition that activates the alert on the built-in monitor. Consider the following:

Conditions for each metric are computed in the NQL query.
In Metric change type monitors, only the first condition verifies the metric change, whereas all the additional conditions compare it against the threshold.
In built-in monitors, some conditions are preconfigured, but you can adjust them to fit your organization's needs.
Using multiple metric thresholds allows you to increase the relevancy of alerts. For example, ensure the system does not raise alerts during low service usage or if a few devices are impacted.
- You can choose between greater than or equal to or less than or equal to when defining thresholds.

Enhancing configured Filter

You can add additional filters to include or exclude certain applications or devices from being monitored. Filtering is only available for built-in monitors that evaluate the following inventory objects: users, devices, applications, and binaries.

Additional ‘group-by’ clause

Add metrics for monitors that track device performance and call quality issues per organizational hierarchy breakdown, including custom levels and location breakdowns. Grouping is only available for built-in monitors that evaluate devices.

Setting Scheduling frequency

The time interval determines how often the system evaluates the trigger condition. The scheduling frequency is fixed for built-in monitors.

An alert Scheduling frequency, for example of 7 days, means the monitor evaluates the alert every 7 days, starting on the 1st of each month.

This may cause the system to trigger alerts sooner than expected, such as one alert on the 28th of a specific month, but triggered again on the 1st of the month after.

Choosing Alert auto-recovery options

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, use the Auto recovery options for Advanced monitor configurations under the Query and conditions tab to 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.