Monitoring of Network Nodes

Read about node state evaluation and node monitoring settings.

As the node represents a single network endpoint (not the device), a primary monitoring subject, everything else in monitoring depends on the node state.

Node State

NetCrunch defines the following node states:

OK: Everything is fine - the node and its services are responding.
Warning: There is some problem with a service or the Monitoring Engine on the node. Monitoring Issues also turn node into a Warning state.
DOWN: Node is not responding - in this state, only the leading monitoring target is monitored to bring the node back to the normal monitoring state.
Unknown: Node state can't be determined - for example, the node has no IP address or has not been monitored yet.
Disabled: Node monitoring is disabled for some reason. There are many reasons why the node is disabled, such as: by Atlas, by Time Restrictions, by the User, or by Dependency.

leading-target

Leading Monitoring Target

Something has to decide whether a node is up or down. That object is the Leading Monitoring Target, set on the node's Status Monitor tile.

Node SettingsMonitoringStatus Monitor

It used to be a network service, and for most nodes it still is — but a node is not always best judged by a service. A device with no monitored services, or one whose real health lives in a monitoring engine, needs something else to speak for it. The leading target can be any of three kinds of object, and the picker groups them exactly that way:

Network Services: Any monitored network service on the node.
Monitors: The node's monitoring engine — SNMP, Windows, Linux, BSD, macOS, Solaris, ESX Server, Proxmox VE Node, Proxmox VE Virtual Machine, or Hyper-V VM. A monitor cannot lead while its engine is disabled.
Sensors: Only sensors whose type is capable of leading. This is a property of the sensor type, not of how you configured it — see below.

The object currently leading is marked on its own tile, so you can see at a glance what the node's state is resting on.

Automatic Selection

The default is <Auto>, where NetCrunch chooses for itself in this order:

A network service, if the node has one
Otherwise a monitor
Otherwise a sensor

Auto also re-resolves when the ground shifts. Disable the monitor that was leading and Auto moves to whatever is next in the order, rather than leaving the node with nothing deciding its state. When Auto has resolved, the picker shows what it landed on alongside the <Auto> label.

Few sensors can lead. Being able to determine node state is declared by the sensor type, not enabled per sensor, and most sensor types do not declare it. In this release the sensors that can be a leading monitoring target are Static Status and Meraki Wireless.

A sensor must also be enabled to be offered.

When setting the leading target on several nodes at once, you can only choose an object that exists on all of them.

node-status-policy

Node Status Policy

The leading target decides what is watched. The Node Status Policy decides what that means — how the node's own state is derived. It sits on the same Status Monitor tile.

For the DOWN state, one of:

Down when all services are down, and the leading monitoring target is not responding
Down when the leading monitoring target is not responding
Never down

The first is the usual choice for a node with monitored services: a single failing service does not condemn the node, but losing all of them together with the leading target does. The second suits a node whose services are incidental, or which has none — the leading target alone decides. The third takes the node out of DOWN reporting entirely.

For the Warning state, one of:

Warning when any element is in error or critical state
Warning when any element is in warning, error or critical state
Warning when any network service is down, OS monitor has problem or node has critical alert
Never in a warning state

While a node is DOWN, monitoring of everything else is suspended and only the leading target continues to be checked — which is what brings the node back when it recovers, without polling a device that is not answering.

Simplified Monitoring

The program determines only a node and a service state by checking network services availability (PING) without tracking performance metrics.

Extended Service Monitoring

In some cases, the status of the node can be determined in the second interval.

Read more about Network Services Monitoring

Monitoring Dependencies

The monitoring of each node can depend on its parent node (network switch or router). This causes an automatic disabling of node monitoring in case the parent link or device is DOWN.

Prioritization and Event Suppression

In large networks with remote intermediate routers, NetCrunch organizes monitoring by priorities. By default, the nodes being closer to NetCrunch Server and intermediate routers are monitored before others.

Event Suppression is the technique of preventing false alarms caused by network intermediate connection failure.

Monitoring Time Mask

When a node is active in certain hours or days, you might limit monitoring to a given time range and weekdays.