PylonMon

Monitor the devices that will never run an agent

Every network has a tier of hardware you cannot install software on. The printer. The managed switch. The NAS appliance with a locked-down web UI. The badge reader nobody has logged into since it was installed. They are invisible to agent-based monitoring and unreachable from outside, so most of them are monitored by somebody eventually noticing.

Why these fall through the gap

Two kinds of monitoring exist, and this hardware sits between them.

An external checker reaches in from the internet. It cannot see 192.168.10.50, and you should not be port-forwarding a printer to find out whether it is alive.

An agent reports out from the machine. Excellent, when you can install one. You cannot install one on a switch.

The way through is to stop thinking of the agent as reporting on its own machine. It already sits inside the network with a route to everything else on it. Let it do the checking on their behalf.

Three lines of config

Any machine already running the agent — a Linux box, a Windows server, a Raspberry Pi in the corner — can check other addresses. Each entry is a name, a kind and a target:

/etc/pylon-beacon/beacon.conf
[probes]
nas = tcp 192.168.10.20:445
printer = ping 192.168.10.50
switch = ping 192.168.10.2
intranet = http http://intranet.corp.local/health
door_reader = tcp 192.168.10.77:4370 5

The trailing 5 on the last line is a timeout in seconds, for a device that answers slowly.

Each of those becomes its own monitor, with its own history, its own alerts and its own place on a status page. The devices themselves are untouched — nothing installed, no configuration changed, no credentials needed.

Picking the right kind

KindUse it whenWatch out for
pingYou only need to know the device is powered on and on the network.Plenty of gear answers ping long after the service on it has died. “It pings” is the weakest claim available.
tcpA specific port must be open — 445 for SMB, 631 for printing, 22 for SSH.The target needs a port. A hostname on its own is rejected rather than guessed at.
httpThe device has a web interface or a health endpoint that should return a page.If you leave off the scheme it is treated as http://. Say https:// explicitly when you mean it.

Prefer tcp over ping wherever a port exists. A NAS that responds to ping while its SMB service is dead is exactly the outage your users will report and your monitoring will miss.

Latency is measured where it matters

The response time recorded is wall time from the agent — that is, from inside your network, on the same LAN as the device. That is the number you want. An external checker’s idea of latency is dominated by the internet path and tells you nothing about whether the switch is struggling.

It makes the slow decline visible too. A printer that answered in 3 ms for a year and now takes 400 ms is telling you something before it stops answering entirely.

Where to run the probes from

The agent doing the probing becomes a dependency of everything it checks, so choose it deliberately:

That last point is worth sitting with. A pile of probes that all fail together is nearly always the prober, not the fleet.

The honest limits

What this gets you

A tier of hardware that was previously monitored by complaint now has uptime history, latency trends and alerts — for the cost of a few lines on a machine you already run. It is the cheapest monitoring coverage available in most networks, because the infrastructure to do it is already installed.

The agent is open source, and the free plan includes three machines, so one of them probing a dozen devices is a realistic way to try it.

Agent documentation · Servers with no public IP · Going deeper with SNMP