CPU, RAM and Disk Monitoring Setup Guide

Before you start

There is no installable HostTracker agent for this check type, and no per-monitor Monitoring Locations picker either. The poll runs from HostTracker's own private checking infrastructure, not the distributed public network. The check works the other way round: your server exposes one small endpoint that answers with a single number, and HostTracker requests it on schedule. There are three ways to provide that endpoint, chosen with the Value provider setting below, and whichever you pick has to be deployed and reachable before you create the monitor:

• Write the endpoint yourself (the custom option). It answers a small JSON object, which is the option many teams prefer since nothing they did not write themselves ever runs on their server.
• Deploy HostTracker's ready-made PHP collector on a Linux/Unix web server.
• Deploy HostTracker's ready-made ASP.NET 4.0 handler on an IIS/Windows server.

A host with no inbound access at all cannot be polled. What has to be exposed is one read-only URL that returns a number, not a management port, but it does have to be exposed to HostTracker's checkers.

Monitoring Source

No screenshot is available for this section, but every control in it still needs explaining, since it is what makes this check type different from the rest of the panel.

• Value provider - a dropdown with three choices. Value provider - your own web service (custom): your endpoint answers {"v": 12.34, "e": "error text", "vs": "version string"}, and at least a value or an error string has to be present, so an endpoint returning just {"v": 42.5} reports 42.5 on every check. HostTracker collector - PHP, for *nix web servers: needs shell_exec enabled in php.ini (it shells out to top, free and df), plus the mysql/mysqli extensions for a MySQL connect-time reading. HostTracker collector - ASP.NET 4.0, for IIS/Windows: the application pool's identity needs rights to read performance counters and the registry, and Network Service is usually enough. Both ready-made collectors download from this section and must be deployed on the target server manually; HostTracker never pushes anything to your server automatically.
• The monitor URL field just below is labelled Full monitor url for the custom option (the exact endpoint address, dialled as-is) or Base monitor url for a ready-made collector (the site root the collector script was deployed under; HostTracker appends the collector's own filename to it).
• Once a ready-made collector is selected, a Counter type dropdown appears: CPU usage %, RAM usage %, Disk or file system usage %, Port connection time (ms), MySQL connection time (ms), and, ASP.NET only, SQL Server connection time (ms) and Windows performance counter. Each brings its own field: a disk letter or *nix path, a host and port, a connection string (with an example-format link), or a category / name / instance triple for a performance counter (instance can be blank for the default, often _Total).

Main Settings

Main Settings for this type has no dedicated screenshot, so here is every control in it:

• Interval - from 1 minute up to 24 hours, plus a cron-schedule alternative. One minute suits a business-critical machine; 5 or 10 minutes is plenty for a slower trend like disk usage.
• Tags - free-form labels for grouping and filtering monitors.
• Full Log - saves every individual polled value instead of only grouped summaries.
• Open Stats - makes this monitor's statistics and log page shareable, including with people who are not signed in.
• Retry on connect fail - a switch, on by default, that retries once before marking a fetch failure as an outright error.
• The Value provider, monitor URL and Counter type controls described under Monitoring Source above also live in this group in the panel.

Response Validation

This is where you turn a raw reading into an alert, and it is where readers tend to struggle. A threshold set too tight fires on every ordinary spike, and one set too loose never fires until it is too late to matter.

• Error condition - shown in the screenshot at its default, no condition, which means the monitor only reports the value with no Down verdict. Choosing equals, not equal to, less than or greater than reveals one number field for the limit; choosing inside range or outside range reveals two, a bottom and a top limit.
• Overloads before Down - appears once any condition other than "no condition" is selected. It is a slider from 0 to 20: the number of consecutive checks that must already be breaching the condition before the monitor flips to Down. At 0, a single breaching reading counts immediately; at 3, for example, three checks in a row over the limit are needed. HostTracker evaluates this centrally, not the machine being watched, and it decides whether the monitor is useful or constantly crying wolf. A server with a CPU load that spikes for a few seconds several times an hour needs a debounce above 0, or every ordinary spike becomes an alert.

Picking the threshold itself is a judgement call specific to what you are watching. There is no single right number, so give it real attention rather than leaving the default in place. One useful property of this check: a fetch failure (the collector is unreachable, times out, or returns something unparseable) is reported as an error immediately and is never counted toward the debounce above, so a flaky connection to the collector cannot satisfy a consecutive-overload count meant for genuine resource pressure.

Alert Subscriptions

Choose which contacts hear about this monitor and for which events: Up, Down, and Repeat (a repeated reminder while the check stays down). A single switch subscribes every contact to Up/Down at once, or pick individual contacts and events from the table below it.

Report Subscriptions

Separately from alerts, choose who receives periodic reports for this monitor - Daily, Weekly or Monthly - by email.

Worked example

Watching disk space on a Linux server already running PHP: unpack the ready-made PHP collector onto the server and confirm it is reachable at its own URL. Set Value provider to the PHP collector option, the monitor URL to the site's base address, Counter type to Disk or file system usage %, and the file system path to /dev/sda1. Set Error condition to greater than, with a limit of 90 (percent), and Overloads before Down to 3, so three consecutive readings above 90% are required before an alert fires. A brief spike from a backup job will not trigger one, but a sustained fill-up will. The interval is 10 minutes, and CPU and RAM get their own separate monitors on the same server with the same collector.

Troubleshooting

• The collector is unreachable. A host with no inbound access at all cannot be polled. Confirm the endpoint answers from outside your own network, on an unguessable path if you are concerned about exposure, since it accepts no commands and changes nothing.
• The monitor alerts on an obviously wrong number. The check reports whatever the collector reports. Fix the endpoint, and consider having it report the optional error string instead of a bad number when something goes wrong on its side.
• Alerts fire on every minor spike. Raise Overloads before Down rather than the threshold itself. Leaving it at 0 makes any single spike count.
• The PHP collector reports "shell_exec is denied on server." CPU, RAM and disk readings all shell out to system commands, so confirm shell_exec is not in the disabled-functions list in php.ini.
• A Windows performance counter check errors out. The application pool identity needs rights to read performance counters and the registry; if it is not already Network Service, try setting it to that.

Related

• All monitoring guides - the hub for every HostTracker check type.
• What is server monitoring - what these readings are for and how they fit alongside availability checks.
• Server monitoring: CPU, RAM and disk - the product page for this check type.
• SNMP monitoring guide - the alternative route to the same metrics on hardware that cannot run a collector, such as routers and switches.
• Database query monitoring - for watching a database's queries and results directly, beyond a connect-time number.
• Database check guide - another check that runs from HostTracker's private infrastructure.
• Free port check tool - a quick way to confirm a port is reachable before wiring a full connect-time monitor around it.
• Assertion mode and response-validation rules - the response-validation rule language used elsewhere in HostTracker.