Server Monitoring using Plugins

Server Monitoring using Plugins

Servers

Server Monitoring using Plugins

Extend Cloudmon monitoring beyond built-in integrations using custom scripts. Collect metrics from any device, service, or application and surface them alongside your existing monitoring data.

Overview

Plugins allow teams to monitor virtually anything that cannot be covered by Cloudmon's built-in integrations. Each plugin is a script, written in Python or PowerShell, that collects metrics from a target device or service and reports them back to Cloudmon. Once a plugin is registered and running, Cloudmon tracks its availability, surfaces all collected metrics, and makes them available for charting, alerting, and historical analysis, exactly like any other monitored resource.

Navigate to Servers → Plugin to view all registered plugins. The plugin list shows each plugin's name, discovery status, discovery message, version, assigned template, license status, last seen time, and last discovered time. A Tree View groups plugins by their script template, making it easy to see how many instances of each plugin type are running across the environment.

The summary tiles at the top of the list show the total plugin count alongside counts for Down, Unlicensed, Critical, and Discovery Failures, giving an immediate health overview across all plugins.

How Plugins Work

Each plugin is built around a script template, which defines what the plugin collects and how it runs. The script executes on the Cloudmon agent at a configured interval, collects numerical and textual metrics from the target, and returns them to Cloudmon. Cloudmon stores both the current values and the historical time-series data for every metric the script returns.

Because each plugin is driven by its own script, the metrics it collects and the sections available within its detail view are specific to what that script monitors. A GPU monitoring plugin will surface driver versions, memory usage, power draw, and temperature. A database plugin will surface uptime, connection counts, operation latencies, and replication status. A storage plugin will surface volume status and usage percentages. The plugin framework is the same in every case; the content is entirely determined by the script.

Plugin Detail View

Clicking into any plugin opens its detail view, which always includes an availability gauge, downtime count, and the device information panel showing the name, vendor, category, IP address, network, boot time, and last seen time of the device the plugin is running on. The side panel shows the plugin version, discovery message, assigned template, instance name, last seen time, status, and state.

The Current Statistics of Numerical Metrics table shows the latest collected value and unit for every numerical metric the script returns. A Last Polled Data of Textual Metrics section captures string values such as software versions, configuration identifiers, or status labels that cannot be represented as numbers. Beyond these, each plugin exposes additional sections specific to its monitoring scope. Some examples of what this looks like in practice:

  • GPU monitoring provides a Driver Overview with CUDA version, driver version, GPU name, and a real-time GPU utilisation chart, plus a Memory section tracking average memory percentage, per-GPU memory usage, and total memory over time. Hardware details are also captured separately.
  • NTFS Mount Point monitoring tracks the status and usage percentage of each mounted volume on the target machine, with each volume reported as an individual metric.
  • MongoDB monitoring provides dedicated sections for Metrics, Database, Performance, Connection, Cursor, and Replication, covering asserts per second, operation latencies for reads, writes, and commands, cache bytes, total connections created, total databases, and uptime, all tracked as time-series charts.

Other plugins in the environment cover areas such as digital experience measurement, branch office assurance, web server performance, ISP connectivity, retail operations, hospital systems, and IoT device health, each reporting the metrics most relevant to that specific use case.

Log Reports

Every plugin includes a Log Reports section that captures the raw output from each script execution. This is the first place to look when investigating a discovery failure or unexpected metric value, as it shows exactly what the script returned and whether it encountered any errors during collection.

Alarms

Alarm triggers can be configured on any numerical metric a plugin collects, using the same threshold and severity system as all other Cloudmon resources. This means custom script metrics benefit from the same alerting infrastructure as built-in monitoring, with no additional configuration required beyond setting the threshold. Learn more.

Troubleshooting

SymptomLikely CauseFix
Plugin showing as Discovery FailureThe script encountered an error during execution or could not reach its targetReview the Log Reports section for that plugin to see the raw script output and identify the error
Metrics showing stale or missing valuesThe agent is not running, or the script is failing silently without a discovery errorConfirm the Cloudmon agent is active on the host and check the Log Reports for recent execution output
Plugin showing as DownThe target device or service the script monitors is unreachable or has gone offlineVerify the target device is online and accessible from the agent host, then check the discovery message for detail
Plugin showing as UnlicensedThe plugin count has exceeded the licensed limit for the Cloudmon accountReview the active plugin count and contact Cloudmon support to adjust the license if needed
    • Related Articles

    • Configuring Alarm Rules for Plugins

      Server Monitoring Configuring Alarm Rules for Plugins Set up threshold-based alarms for any plugin running on your monitored servers or devices, so Cloudmon notifies your team or triggers automated remediation the moment a plugin metric or status ...
    • Server Monitoring

      Servers Server Monitoring Monitor servers, virtual machines, and Windows infrastructure across your environment. Cloudmon supports agent-based and agentless monitoring, giving you the flexibility to cover every server regardless of how it is managed. ...
    • Agent Vs Agentless Monitoring in cloudmon

      Attribute Agent-based Monitoring Agentless Monitoring – SNMP, WMI, TCP, ICMP Methodology Deploy the Cloudmon Agent on each server that requires monitoring. Cloudmon uses Probes to monitor IP network endpoints and devices in the network such as ...
    • Server monitoring using Agent

      Agents Server monitoring using Agent Monitor the availability, performance, and health of all physical servers managed by Cloudmon agents. Track CPU, memory, disk, and network metrics in real time across your entire server fleet. Overview Servers are ...
    • Why is monitoring server response times important?

      Monitoring server response times is crucial for ensuring a positive user experience, optimizing performance, detecting issues early, and maintaining cost-effective resource allocation.