Remote Monitoring
Administrators have the capability to utilize RMM (Remote Monitoring and Management) tools to monitor real-time usage of infrastructure and software operations, such as operating systems, CPU activities, and network processes.
By continuously monitoring workstations, the system can detect and alert on any suspicious activities or potential security threats in real-time. This allows for immediate action to mitigate risks and prevent potential breaches.
Within Absolute you can create a customized RMM packages for automated alerts and notifications of system failures, security breaches, performance issues, and other critical events, enabling quick response and resolution.
The ability to monitor system performance metrics and generate alerts for potential issues allows IT teams to take proactive measures to address issues before they escalate into major problems. This can help in minimizing downtime and ensuring smooth operations.
It's important to pay attention to resource utilization when configuring monitoring workflows, especially if adjustments involve more frequent checks or intensive operations.
For instance, shifting the CPU check frequency from default (e.g., 30 minutes) to a shorter interval (e.g., 2 minutes) could lead to increased resource consumption, particularly if devices are already nearing their limits (e.g., 90% CPU usage).
It's essential to consider RAM usage, particularly due to LiteDB file caching. Proceed with caution to prevent excessive resource usage and potential performance issues.
Guided walk-through: How to Modify RMM ChecksGuided walk-through: How to Modify RMM Checks
❶ |
Click the Monitoring tab within the console sidebar > Monitors > Choose the existing template of checks and actions from the list |
❷ |
Next you will be moved into the Evaluation workflow canvas. This canvas is familiar to Automated Workflows drag-and-drop canvas. The set of actions on the right sidebar is the same as for Security Posture workflows. Detection: Initial step in a chain. The primary function of this step is to assess if a specific check or action is necessary based on predetermined requirements. Example : Determine if the device is Windows Server. RMM system will proceed with executing or scheduling further checks only for non-server devices. Subsequent Checks: Once a detection confirms the compliance with predefined parameters, the system initiates further checks. Example 1: Use CPU Usage Action to monitor the CPU Usage of a system and generate alerts based on the detected severity levels. Use the action's properties to set the severity levels (Low, Medium, High, Critical), e.g.:
Based on the set severity in the action properties, the system will determine the threshold for each alert level. Example 2: Use Event Viewer Action to review recorded events associated to applications on your system. The default Application log examines records in the Windows Event Viewer. Use the actions's properties to set the conditions, e.g.: if it identifies at least 10 events within the last 24 hours at a critical or error level, an alert will be triggered. |
❸ |
Scheduling the check Each check is executed based on its triggering settings, which can be accessed and modified under the 'Settings' gear icon on the right. Recurrence
Schedule Settings
Please be aware of an existing limitation for the Detection - it is temporarily not configured for scheduling. Currently, it is designed to operate just once and does not support recurring activations. |
❹ |
RMM Settings Go to Settings on the upper toolbar for more configurations:
|
❶ |
To create a customized monitoring check click '+Create' on the upper toolbar of Monitoring, set the Name (obligatory step) and Description (optional) |
❷ |
You will be moved to the same workflow canvas where you can configure your own set of checks and detection criteria. Drag and drop the necessary actions to the canvas. Each action can be configured according to specific requirements via Properties, e.g. while checking Disk space health the severity of each level can be set. If necessary, more actions can be added to the workflow, e.g. 'Send Email' action to notify user about open alert. |
❸ |
Check to trigger Alert If required, add an On Open Alert or On Close Alert action to your workflow. These actions allow you to trigger alerts when a specific condition is met or resolved. Click on the selected action and define the condition that should trigger the alert. Example Monitoring a Windows Service (e.g., DCOM Server Process Launcher) Add a Service Status action to monitor the status of a Windows service and define the conditions as follows:
To achieve the Restart Service if stopped functionality, add a Start Service action to the Open Alert workflow:
Such action is useful to ensure essential services are always running. Windows systems are underpinned by Windows Services - these services provide crucial functions to users, machines and applications network-wide. The Windows Services Check monitors the selected Windows Services and fails where a service is in the stopped state. During the installation process the Agent queries the device for any Windows Services that are set to start automatically, it then compares any discovered services with the services.ini file and where a match is found a Check is automatically added for the service(s). Additional Windows Service Checks can be added manually either in the Agent (during and post-installation) as well as from the Dashboard (post-installation). |
Guided walk-through: How to Enable RMM ChecksGuided walk-through: How to Enable RMM Checks
❶ |
Select default or created RMM package from the list and click 'Publish Policy' |
❷ |
From the settings pop-up window, choose the desired target device. Options include targeting Sites, Queries, Device Groups, Active Directories or individual devices. |
❸ |
After publishing a policy, it becomes accessible for review. Within the Policies overview section, users can observe all targeted devices alongside the status of each conducted check.
The 'Refresh' button on the top toolbar updates the chart with the latest results. The last check time and data within the Policy are refreshed only in case of change in the Alert status—specifically, when an alert is opened or closed. Example: If you check CPU Usage and it reaches 90%, an Alert is triggered. This information is recorded in the Policy, along with the time it occurred. These data points will not be updated until CPU Usage falls below 90%, and the alert is closed. During this entire time, the device may have CPU Usage fluctuating between 90% and 99%, but the Policy will continue to show 90%. The Outage tab provides the history of alerts on the device: their status, date and reason. |
❹ |
The same information is also displayed on a dashboard in the Overview. Open Alerts are also available for review under Device inventory (View Inventory-Health-Alerting) |