Creating custom monitors
Last updated
Last updated
Click on the New monitor button in the top-right corner of the page to create a new monitor from scratch.
Use the General tab to define the new monitor.
Custom monitors offer one detection mode. The Metric threshold type compares the value of the NQL query-defined metric to a threshold defined by the user. For example, a monitor triggers an alert when 20% of devices running a binary experienced a crash.
Provide a meaningful name for the monitor. The system uses this name to send notifications and visualize monitors on the Alerts overview page.
The system generates a unique identifier automatically from the monitor’s name. You can only modify the NQL ID during the monitor creation process using the following characters a-z, 0-9, _
. You cannot edit this field once you have created the monitor. Use the NQL ID to query this monitor using NQL.
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).
Set the priority level. The default level is medium.
Create custom tags for monitors. This allows you to filter alerts using tags in the Overview dashboard and in the Webhooks integration. Currently, there is a maximum of ten tags per monitor.
Use an NQL query to define metrics to monitor. NQL facilitates the selection of one or multiple metrics, helps specify the scope with the where
clause and defines the right granularity for the alert context using time aggregation and the by
keyword for grouping. Use the Show in Investigations button to view the results of your NQL query in the Investigations module.
The NQL query must follow several rules to support monitors:
The NQL query for monitors must include a computed or aggregated metric, which means every query requires a compute
or summarize
clause to be compatible with a monitor.
Optionally, include more than one computed or aggregated metric in your query to set multiple conditions for the alert to be triggered.
Use at least one metric to set a threshold for monitoring conditions. Create an additional metric if your original query does not include one.
Not compatible with monitors:
Compatible with monitors:
Do not add conditions to evaluated metrics at the NQL level. Instead, use the Trigger condition section to define the condition.
Incorrect monitor NQL query:
Correct monitor NQL query with conditions:
Use the where
clause to narrow the scope of your monitor to specific locations, applications and other categories.
Use summarize... by
to define the right granularity for the alert context. In the following example, a single alert will be triggered per binary name.
Refer to the Detecting issues impacting multiple devices and Detecting issues impacting a single device or user documentation to learn more about defining the NQL query.
Define the condition that triggers an alert. Use each metric computed in the NQL query to narrow down the condition.
The scheduling frequency determines 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. However, the availability of these timeframes depends of the during past
clause and the events queried with the monitor's NQL query.
See the following examples to understand how setting monitor query determines the available scheduling frequency:
One way to create monitors is by importing them from a previously exported configuration file.
The system does not allow the import of a monitor with the same NQL ID as a deleted monitor if there are events in the system still associated with that deleted monitor. Alert events are kept in the platform for 30 days maximum.
If the NQL ID is already used in deleted monitor with existing alerts message appears during the import of the monitor, please modify the export file to create a new NQL ID.
RELATED TOPICS
Monitored events with during past | Minimum frequency | Maximum frequency |
---|---|---|