Network Devices Reference

A network device in octoja is a device that carries no agent: a switch, firewall, printer, NAS, UPS, or a virtualization host. You register it once, name a monitoring device that queries it over the network, and from then on it behaves like any other device — it has a page, checks, results, alerts, and a customer. This article explains the model behind it. The registration steps are in Add a Network Device Without an Agent.

Device classes

Every device carries a class. It drives filtering on the Devices page, targeting in config packages and automations, and which checks are offered. Agentless devices use these classes:

Agent-managed devices use the classes Windows Server, Windows Workstation, Linux Server, Linux Desktop, and macOS instead. When you write a condition against the device class in an automation, use the internal value rather than the label — the list is in Create an automation.

The monitoring device

An agentless device has no way of reporting anything by itself, so every one of them points at a monitoring device: a device with the octoja agent that can reach it over the network. That agent runs the checks and sends the results back. Three consequences follow, and they explain most surprises:

• Probing stops when no monitoring device is reachable. Configure fallbacks and add a Device online check on the agents themselves so you notice their outages.
• Reachability is judged from the monitoring device. Enter the address the monitoring device can reach — a LAN or management address, not a public one — and make sure no firewall sits between the two on the port the check uses.
• One monitoring device can serve many. Everything agentless at a site can point at the same machine; there is nothing to install per device.

You can configure an ordered list of monitoring devices instead of relying on one. Failover selects an online candidate when the active agent has stopped reporting for about two minutes; a recovered preferred agent does not displace a healthy active one. If no prober is reachable, the Device online check for a probed network device skips evaluation and keeps its previous result. That old result is not evidence of current health. Monitor the agents themselves so a prober outage is not missed.

Online status

Agentless devices reach their online status differently from agent devices, and the difference is worth knowing before you build alerts on it:

Which checks fit which class

Your own checks join this catalogue under the same rule. A custom script check is offered on a network device once it declares a host or target parameter; octoja hides that field on assignment and fills in the device's address on every run. How to declare it is in Custom Script.

Interpreting port error counters

The Errors (in/out) column shows cumulative receive and transmit errors reported by the device, not a current error rate. Any value above zero is highlighted yellow. Compare readings over time: a rising counter shows that additional errors are occurring.

The port display is not an alert rule. Notifications need a suitable check with an alert configuration, including for a device outage; see Set up offline alerts. Displaying port utilization alone does not trigger an alert after a particular duration.

Tips

• Assign the device to a customer right away. Agentless devices are as tenant-scoped as any other device, and an unassigned one is easy to lose.
• Give SNMP devices their own community string or an SNMPv3 user — the default public is a password everyone knows.
• Checks whose correct value differs per device — the host or IP above all — are awkward to distribute through a config package. The reasoning is in Assign checks with config packages.