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, Bash, 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.

Creating a Plugin

A plugin consists of two files placed inside a dedicated folder. The folder name, script filename, and JSON configuration filename must all share the same base name. No spaces or special characters are allowed; use hyphens only.

plugins/
├── disk-health/
│   ├── disk-health.sh       <-- script (must match folder name)
│   └── disk-health.json     <-- configuration

Cloudmon automatically discovers the plugin the next time the agent scans the plugins directory, which happens every 5 minutes. There is no manual registration step.

The Script

The script can be written in Bash (.sh), PowerShell (.ps1), or Python (.py) depending on the agent OS. When executed, the script must print a single JSON object to standard output. Four fields are required in every output:

Any additional fields returned alongside these four become the plugin's metrics. Numbers are tracked as time-series charts. Strings appear as textual data. Arrays are displayed as tables and must include a name field in each object. Two optional fields help organise how metrics appear in the UI:

• tabs – groups related metrics into named sections with a defined display order.
• units – attaches a unit label (such as MB, percent, or ms) to each numerical metric.

A minimal valid script output looks like this:

{
  "status": 0,
  "message": "Host: web-01 | CPU: 42% | RAM: 6.1/8.0 GB",
  "version": 2,
  "heartbeat": true,
  "cpu_load": 42,
  "ram_used_gb": 6.1,
  "ram_total_gb": 8.0,
  "units": {
    "cpu_load": "percent",
    "ram_used_gb": "GB",
    "ram_total_gb": "GB"
  },
  "tabs": {
    "performance": {
      "order": 1,
      "tablist": ["cpu_load", "ram_used_gb", "ram_total_gb"]
    }
  }
}

The JSON Configuration File

The JSON file tells Cloudmon how to execute the script and which targets to monitor. Each entry under instances becomes a separate plugin instance in the UI, named plugin-name-instance-name. The structure of the instances block differs depending on whether the plugin runs locally on the agent machine or connects to a remote device.

Local agent – the script runs on the same machine being monitored and needs no connection parameters. The instance value is left empty:

{
  "command": {
    "linux": "bash",
    "win32": "powershell.exe -ExecutionPolicy Bypass -File"
  },
  "instances": {
    "local": {}
  }
}

Probe monitoring a remote device – the script SSHes or uses WMI to reach a separate target. Connection details are defined per instance and passed to the script as arguments at runtime. Fields listed in encrypt_keys are automatically encrypted by Cloudmon after the first successful execution so credentials do not remain in plain text. Adding multiple entries under instances allows a single script to monitor several devices without duplicating any code:

{
  "encrypt_keys": ["SSH_PASSWORD"],
  "command": {
    "linux": "bash",
    "win32": "powershell.exe -ExecutionPolicy Bypass -File"
  },
  "instances": {
    "server-01": {
      "SSH_HOST": "192.168.1.10",
      "SSH_USER": "monitor",
      "SSH_PASSWORD": "yourpassword",
      "SSH_PORT": "22"
    },
    "server-02": {
      "SSH_HOST": "192.168.1.11",
      "SSH_USER": "monitor",
      "SSH_PASSWORD": "yourpassword",
      "SSH_PORT": "22"
    }
  }
}

Agent Types and Script Formats

The correct script format depends on where the Cloudmon agent is running and what it needs to reach:

Plugin Directory Location

Place the plugin folder in the Cloudmon plugins directory on the agent machine:

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.

Editing a Plugin

Plugins are discovered automatically as soon as their script runs and reports data, so there is no manual Add step. To adjust an existing plugin's settings, open the plugin from the list and click Edit. The Edit Plugin panel is organized into three sections: Monitor Details, Configuration Details, and Alert Settings.

Monitor Details: basic identification details for this plugin.

Configuration Details: timeout, interval, and tags.

Alert Settings: configure alarm rules, user groups, and third party services.

Click Save to apply the changes.

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. To apply an alarm rule to a specific plugin, open its Edit panel and select the desired profile from the Alarm Rule field under Alert Settings. Learn more.

Troubleshooting