NetCrunch Monitoring Objects
Everything NetCrunch monitors is an object with a state - nodes, interfaces, services, sensors, alerts, and the statuses calculated from them. Knowing which object you are looking at tells you what you can alert on, put on a dashboard, and roll up into a service status.
NetCrunch does not keep a list of devices on one side and a list of checks on the other. It keeps a tree of objects that have a state. Nodes sit at the top; under them are the things being monitored on that node; under those are individual measured values.
This matters in practice because every object in the tree is used the same way. Anything with a state can raise an alert, appear on a map or dashboard, be referenced by a widget, and be folded into a Composite Status. So the useful question when something is wrong is not "which device" but which object - the answer decides where the alert comes from and what the dashboard should show.
Object State
Object state names are designed to reflect their current status accurately:
- Critical, Error, or Down: The element is not functioning or is unresponsive.
- Warning: An issue requires attention, but no immediate action is needed.
- OK, Success: The element is functioning properly.
- Disabled: Monitoring of the element has been intentionally turned off.
- Unknown: The element's state is not determined because it has not been monitored or cannot be monitored.
Unknown is not a kind of failure. It says NetCrunch has no measurement, which is a different thing from having measured something bad. The distinction matters most in a Composite Status: a service built from objects that are merely Unknown is not broken, it is unobserved, and those need different responses.
Nodes
A node is the root that everything else hangs from, and it is a service endpoint rather than a device.
Older monitoring tools were built around hardware: one box, one entry, and the monitoring hung off the box. That model stopped describing reality some time ago. A single server hosts dozens of virtual machines that fail independently. A SaaS platform you depend on has no box you can point at. A reverse proxy answers for a dozen applications on one address, and none of them share a fate.
Because a node is an endpoint, the atlas is not a hardware inventory. One machine can legitimately be several nodes, and a node can correspond to no machine you own. Model what you depend on, not what you can touch - the rest of this page describes the object types that make that possible. See What Is a Node in NetCrunch?.
obj-ip-node
IP Node
The most common type. It represents something reachable at an address, usually identified by a DNS name or an IP address, and it can carry network services, monitors, sensors and interfaces.
Different names are different nodes, even on the same machine.
If shop.example.com and api.example.com resolve to one server, add both. They are separate endpoints and they fail separately: different virtual host, different certificate, different backend pool. A working shop tells you nothing about api, and monitoring only the address they share tells you about neither.
The same applies in reverse - a device answering on a management address and a data address is two endpoints, and the interesting failures are the ones where only one of them stops.
Use one node per name you actually depend on. See Monitoring Web Pages & Data for monitoring the pages behind them.
Telemetry Node
A node for data that is pushed to NetCrunch rather than polled by it. It usually has no address to ping; it exists to receive.
It accepts two things:
- Native NetCrunch REST
- JSON posted to the node's own endpoint, carrying counters, statuses and events. This is the format to use from a script, an application, or anything you control - see Sending Data to NetCrunch.
- OTLP (OpenTelemetry)
- Metrics and logs from any OpenTelemetry client or collector, sent to the OTLP gateway. Use this when the system already speaks OpenTelemetry and you would rather not write an exporter.
Retention is chosen when the node is created, because NetCrunch cannot know how often something will push to it. See Telemetry Node.
Cloud Service
Represents a single monitored cloud service. NetCrunch provides ready-to-use sensors for over 30 services from Azure, AWS, Google and others, so the node models the service itself rather than any machine behind it.
Cluster Node
Represents a cluster as a whole, rather than any of the hosts in it.
NetCrunch creates one when you add a Proxmox VE cluster. The node carries the Proxmox VE Cluster sensor and watches what belongs to the cluster rather than to a member - quorum, shared datastores, and whether a member has dropped out - and it can create the member nodes as it discovers them. See Proxmox VE Monitoring.
obj-composite-status
Composite Status
A node whose state is calculated from other objects instead of measured on a device.
You need one because nothing you monitor is a service. An order page depends on two internet links, DNS, Active Directory and a web server - no single node in the atlas can say whether ordering works. A Composite Status is the node that can, and it answers three questions the parts cannot:
Is the service actually affected? Two internet links where either will do: losing one is a node-level alarm, but the service is fine. Put them in a redundant group and the composite stays OK until the last one fails - the difference between an alert worth acting on and noise.
Who gets told? Alert on the composite and one notification describes the service, instead of five describing its parts and leaving the reader to add them up.
What goes on the dashboard? One tile per service rather than a wall of components. A composite can contain another composite, so a whole tree of services rolls up to a single state.
See Composite Status for how groups are defined, and Business Service Views for the diagram NetCrunch builds automatically from one.
Probe
Represents a remote monitoring engine, not the machine running it. Its state tells you whether that engine is reachable and collecting.
The probe object does not monitor the computer the probe is installed on. If you care about that machine's disk, memory or services - and you should, because everything it monitors depends on it - add it as an ordinary IP node as well. See Distributed Monitoring.
Monitor
A monitor is the shared connection to a technology - SNMP, WMI, VMware, Linux over SSH - holding the credentials and parameters that everything of that kind on the node reuses. It is what gives NetCrunch access to thousands of metrics without configuring each one.
A monitor is deliberately generic, so its state is not worth alerting on. It tells you the connection works, not that anything you care about is healthy. Alert on the monitoring packs and sensors that use it.
Monitoring Pack
A named bundle of alerting rules and data collectors - what to warn about, and what to record for reports - written once for a kind of thing and applied wherever that thing appears.
Monitoring Pack is a group of performance parameters and events monitored and collected for the reports.
This is the unit of reuse in NetCrunch, and the reason you rarely configure alerts on a node. A pack can be attached three ways:
- Automatically, by filter
- The pack states the conditions a node must meet - a Windows Server running LDAP, say - and NetCrunch applies it to every node that matches, including nodes discovered next month. This is how a monitoring policy is expressed rather than maintained.
- Manually
- Assigned to one node, several selected nodes, or a whole atlas view.
- To a sensor type
- With Restrictions set to Sensors only, a pack carries the alerting and reporting for a sensor type wherever that sensor is configured, rather than for a node. The same works for IP SLA and Huawei NQA operations.
Restrictions do double duty: they limit both the events a pack may contain and the devices it can reach - Windows, Linux, macOS, BSD, Solaris, VMware ESXi, Proxmox VE, SNMP, or the sensor-based options above.
Editing a pack changes monitoring on every node using it, which is the point and also the risk: a threshold loosened once is loosened everywhere. NetCrunch ships more than 270 predefined packs, and the predefined ones are replaced wholesale by an Atlas Configuration Upgrade, so copy a predefined pack before adapting it. See Monitoring Packs.
Network Service
A protocol-level check - roughly 70 of them, from HTTP and DNS to SMTP and FTP - run by the NetCrunch monitoring engine on the server or a probe. Each sends the request that protocol expects and confirms the answer looks right, so a service in the OK state means the application replied, not merely that a port was open.
Every service records the same four measurements: Round Trip Time, Check Time, % Failure Rate and % Packets Lost.
Network services matter more than their size suggests, because a node's state is largely their state. That relationship has one behavior worth knowing:
When a node is down, only its leading service is checked.
Rather than retrying every service against a machine that is not answering, NetCrunch falls back to one - the leading service - and uses it to decide when the node is back. That keeps a failed node from generating a burst of identical failures, and it is why the leading service can be checked in seconds rather than minutes: it is the only thing being asked.
Services can be adapted without writing code: duplicate one to run on a different port (an HTTP_8080 for a service behind a non-standard port), define a bare TCP port check where a connection is all you need, or build a full request/response definition from scratch over TCP, UDP or TLS/SSL. See Network Services Monitoring.
Interface
A single network interface on a monitored device, with its own state, traffic and error counters.
Interfaces are worth referring to directly because a device can be entirely healthy while one of its ports is not: the switch answers every check, and the uplink carrying half the building is down or quietly discarding packets. An interface object lets an alert, a widget or a composite status point at that port rather than at the switch. See Monitoring of Network Interfaces.
Sensors
Sensors are focused on specific monitoring needs such as monitoring a process, text log file, pending update, camera, SQL query, or web page.
Monitoring Sensor is a software module focused on monitoring a single object, service, or device (web page, file, folder, query, etc.).
Sensor Status Object
Some sensors publish objects of their own, carrying data as well as a state - Snapshot Image for a camera sensor, Web Page for web monitoring, Process for a process sensor.
These are separate objects because their state can differ from the sensor's. A camera sensor can be connecting and collecting perfectly while the image it returns no longer matches its reference; the sensor is OK and the object is not. Reference the object when you care about what was measured, and the sensor when you care about whether measuring worked.
Active Alert
Alert - the condition being watched for action to react to potential danger or get attention.
An alert's state follows its severity. Informational and minor alerts count as ok, because they exist to be recorded rather than acted on - which is why a node carrying several of them can still be green.
SNMP Value
Available once you add an event for SNMP variable value alert to a node. The object itself is always in a success state and exists to carry the value; the alert attached to it is what has a meaningful state.
IP SLA/NQA Operation
Enable IP SLA or NQA monitoring on a node, add the operations you want, and each becomes an object you can refer to - so a synthetic test running on the device is available to alerts and dashboards like anything measured by NetCrunch itself.
Atlas View
A view can carry a status of its own, calculated from the nodes it contains, so a folder or an IP network can be referred to like any other object - one indicator for "everything in the branch office" without building a composite for it. See Network Atlas Views.