Set policies to monitor and alert you about specific endpoint issues
Monitor policies allow you and your team to keep an eye on the health and well-being your devices. Create a monitor policy and target tags assigned to your devices. Once a monitor policy has been created and assigned to tag(s), it's as simple as adding the tag to the devices you wish to monitor and stay alerted to.
Video Walkthrough
Monitor policies
In order to start receiving alerts regarding the state of your devices, a monitor policy must first be created. Monitor policies can be found under Policies > Monitor. This page will show the list of policies. From here policies can be edited or created.
The monitor policy list contains total monitor counts and targeted devices
The monitor policy page gives you the ability to see all of the policies you currently have as well as the devices they currently monitor through their assigned tags. See tags for more details on Level's dynamic tagging system.
A policy contains many monitors to keep an eye on device health
A policy contains a few modifiable parameters:
Recipients: Email addresses for alert notifications.
Targets: Assign one or more tags here and all the devices assigned to the tags will receive the Monitor Policy.
Monitors: One more device attributes to be watched. When a threshold is exceeded, then an alert will be triggered.
A monitor policy can have many monitors attached, even multiple of the same type. This gives you complete granular control over thresholds, severity, and which monitors you and your team actually need to be alerted on.
Monitors
Monitors allow you to fine-tune parameters for effective system management. Each monitor gives control over the following options
Monitors can be fine-tuned to meet your needs
A monitor gives you control over several parameters:
Monitor Name: A descriptive name for the monitor, e.g., "Windows Reboot Required."
Monitor Type: Defines the type of monitoring performed. In the example, "Run Script" is selected, but there are other types as well.
Severity: Set the importance level for the alert—e.g., Informational, Warning, Critical, or Emergency.
Type-Specific Parameters: These will change depending on the selected Monitor Type. For example, when "Run Script" is chosen, you can specify the script to run, check the script output, and set the trigger conditions.
Value: Set the value that the monitor checks to trigger an alert. In the example, the script checks if the output contains "ALERT."
Auto-Resolve Alert: Toggle whether alerts should automatically resolve once the threshold is no longer exceeded.
Remediation Automation: Assign an automation for remediation, e.g., "Ask User To Reboot." Automations will soon replace remediation scripts (optional).
Run Script: Select a script to run automatically when the monitor is triggered (optional). (Scripts will be deprecated in an upcoming release.)
Send Notification on Alert: Enable sending notifications when the threshold is breached.
Send Notification on Resolution: Enable sending notifications when the alert is resolved.
Note: Scripts will be deprecated in an upcoming release. Use Remediation automations instead
Monitor types
There are several monitor types:
CPU: Monitor CPU level
Measured in percent used
Connection: Monitor when an agent is unable to check-in with Level servers. When Level sees no check-in, then the device is considered offline. This can be caused by an internet/network outage, a system problem, a power event, a reboot, etc.
Measured in minutes offline
Disk Usage: Monitor disk usage. Can choose to only monitor the system drive or all drives.
Measured in either GB free or percent free
Event Log: Monitor system logs for specific event IDs.
Triggered by number of occurences inside a specified duration. For example once in a minute, or 3 times in an hour.
Memory Usage: Monitor memory/RAM usage.
Measured in percent used
Process: Monitor if a process is running or not running.
The exact process name is needed
Service: Monitor if a service is running or stopped.
The service name (not Display Name) is needed
Run Script: Run a script and evaluate the returned output.
Learn more about script-based monitors below.
Best practices and recommendations
While a monitor policy can have many monitors, do not attempt to cram all monitors into a single policy.
Split out application monitoring from resource monitoring. For example, it's typically best to monitor CPU, hard drives and memory in one policy and services and processes in a different policy.
Use monitor policies modularly based on roles. For example, create monitor policies for domain controllers, file servers, Exchange servers, etc. In those polices, only monitor the processes and services specific to that role.
Assign tags to devices that are also specific to roles, and when possible, use the same name for monitor policies and their tags. For example if you have a tag called Domain Controllers that you have assigned to all domain controllers, then a Monitor Policy called Domain Controllers (which only monitors domain controller functions) is an obvious pairing.
Only leave auto-resolve unchecked if you want a technician to investigate the root cause of an alert. If auto-resolve is unchecked, a tech must manually clear the alert which may create unnecessary administrative overhead.