Server Monitoring

Overview

Server monitoring uses the Pingniner agent, a small program you install on the machine. Once running, it reports every minute with a full picture of the host: CPU, load average, memory, swap, filesystems, disk I/O, network throughput, running services, processes, Docker containers and temperatures.

Because the agent pushes data to Pingniner rather than being polled, servers behind a firewall or on a private network work fine — the machine only needs outbound HTTPS access to ingest.pingniner.com.

INFO

Servers count toward your plan's monitor limit, like every other monitor type. See Plans & Limits.

Features

• Full-host metrics every minute, with no polling and no inbound firewall rules.
• Hardware and OS inventory — manufacturer, model, serial, BIOS, CPU, memory modules, disks, graphics and OS version.
• Service monitoring — alert when a named service stops running.
• Docker monitoring — per-container state, CPU, memory and process count.
• Flexible triggers across seven groups, with your choice of comparison operator.
• Cross-platform — Linux, Windows, macOS and BSD.

How to Set Up Server Monitoring

1. Sign in to your Pingniner account and go to Servers.
2. Click "New Server".
3. Enter a Name — a friendly name you will recognise in the list.
4. Choose the Type — Linux, Windows, macOS or BSD. This determines which install command you are given.
5. (Optional) Under Advanced, set a Group, Tags and Notes.
6. Save. The server is created with a status of Unknown until the agent first reports in.
7. Install the agent using the command from the server's Overview page.

Installing the agent

Open the server, then use the Agent action. The panel shows the Server Key, the install command with that key already filled in, the uninstall command, and the agent version currently reporting.

Linux, macOS and BSD:

curl -L -s -o PingninerInstaller.sh https://github.com/pingniner/agent/releases/latest/download/PingninerInstaller.sh \
  && sudo bash PingninerInstaller.sh YOUR_SERVER_KEY server

Windows — run in an elevated (Run as administrator) PowerShell:

Invoke-WebRequest -Uri https://github.com/pingniner/agent/releases/latest/download/PingninerInstaller.ps1 -OutFile PingninerInstaller.ps1 -UseBasicParsing; powershell -ExecutionPolicy Bypass -File PingninerInstaller.ps1 YOUR_SERVER_KEY server

Replace YOUR_SERVER_KEY with the key from the Agent panel. The installer creates a cron entry (Unix) or scheduled task (Windows) that runs the agent every minute.

Data should appear within a minute or two. See The Agent for the full reference, including updating and removing it.

TIP

The server key is the only credential the agent uses. Treat it like a password — anyone holding it can post data to that server record.

Viewing & Managing Servers

Each server has its own sub-navigation: Overview, CPU, Memory, Storage, Network, Apps, Docker, Triggers, Alerts and Maintenance. The Docker tab only appears when the agent reports containers.

Overview

Current status, last seen time, and at-a-glance CPU, memory and disk usage, plus group, tags and notes.

Two actions live here:

• Agent — the server key, install and uninstall commands, and the installed agent version.
• Sys Info — the full hardware inventory: system manufacturer, model, version, serial, UUID, SKU and whether it is virtualised; BIOS, baseboard and chassis; OS; CPU; graphics; memory layout; disk layout; block devices; battery; users; printers; USB; audio; Bluetooth; Wi-Fi; and installed versions.

Edit

Change the name, type, group, tags or notes at any time. Changing the type only affects which install command is displayed — it does not reconfigure an already-installed agent.

History

Per-metric history behind each tab: CPU (load, user, system, nice, idle, IRQ, steal, guest), temperatures, average load, RAM and swap (both including and excluding buffers/cache), filesystem usage, disk I/O, network throughput per interface, ping latency and process count.

How long history is kept depends on your plan — see Plans & Limits.

Triggers

Unlike the other monitor types, server triggers are fully yours to create, edit and delete. A new server starts with a default set; use Reset triggers in the header (or the bulk action on the server list) to return to those defaults.

Available trigger types, grouped as they appear in the form:

Group	Trigger types
System	No Data, CPU Usage %, CPU User %, CPU System %, CPU Steal %, Average Load, CPU Temperature °C, Chipset Temperature °C
Memory	RAM Usage % (Excluding buffers and caches), RAM Usage % (Including buffers and caches), Swap Usage %, RAM Usage MB (Excluding…), RAM Usage MB (Including…), Swap Usage MB
Storage	File System Usage % - <mount>, File System Usage GB - <mount>
Network	Ping Latency (ms), MB/s Received - <interface>, MB/s Transmitted - <interface>, MB/s Total - <interface>
Services	<name> - Service not running
Processes	Processes count
Docker	<name> Docker - Not Running, <name> Docker - Memory Usage MB, - Memory Usage %, - CPU Usage %, - Processes Count

Storage, Network, Services and Docker trigger types are generated from what the agent has actually reported. If you do not see a mount point, interface, service or container in the list, the agent has not reported it yet.

Each trigger has:

• Comparison — == (equal), != (not equal), >= (greater or equal), <= (less or equal), > (greater), < (less), Contains, Does not contain.
• Comparison Value — the threshold to compare against.
• Impact — None, Degraded or Down. This is what the trigger does to the server's status when it fires.
• Occurrences — how many consecutive failing checks before an alert is raised (1–50).
• Contacts — which users get notified.
• Repeating notifications — off, or every 5/15/30 minutes, hourly, 2h, 6h, 12h or 24h.
• Active — whether the trigger is evaluated at all.

No Data, Service not running and Docker Not Running have no comparison or value — they are state checks, so those fields are hidden.

See Triggers & Incidents for a fuller explanation of occurrences, impact and repeating notifications.

TIP

No Data is the trigger that tells you a server has gone away entirely. If you only set one trigger on a new server, set that one.

Alerts

Every incident raised for this server: the trigger that caused it, when it started, when it ended, and when the last notification was sent.

Maintenance

Schedule a window during which triggers and notifications are suppressed. Checks still run and data is still collected — you simply do not get paged for a planned reboot. See Maintenance Periods.

Best Practices

• Always set a No Data trigger. Threshold triggers cannot fire on a machine that has stopped reporting; only No Data catches that.
• Tune occurrences before you tune thresholds. Most alert noise is a brief spike, not a wrong threshold. Raising occurrences from 3 to 5 usually fixes it.
• Set filesystem triggers on percentage, not gigabytes, unless the volume is very large — a 90% rule survives a disk resize, a "50 GB free" rule does not.
• Use Impact deliberately. A full /tmp is Degraded; an unreachable host is Down. Status pages and uptime reports both read this value.
• Group servers by role or environment so the list stays navigable — see Groups & Tags.