Operations
A task index for everyday work — bringing something into monitoring, changing how it is monitored, and taking it back out again.
Most day-to-day work in NetCrunch is one of three things: you are adding something, changing something, or stopping something. This chapter is an index organized that way. It points at the topic that covers each task rather than repeating it.
ops-add
Create or Add
Adding has a chapter of its own — see Adding to NetCrunch for the full walkthrough of each route.
- Nodes
- Adding Nodes to Monitoring
- Monitoring targets — services, sensors, monitoring packs
- Adding Targets to Monitoring
- Atlas views
- Adding Atlas Views
- Alerts
- Adding Alerts
Beyond those, three routes bring in more than one thing at a time:
- A configuration you have already worked out, applied to new nodes
- Node Monitoring Templates
- Everything an existing PRTG installation monitors
- Migrating from PRTG
- Whatever is on the network, found for you
- Auto Discovery
ops-change
Change
- Settings across many nodes at once, rather than node by node
- Managing Multiple Node Settings
- The speed an interface's utilization is measured against
- Monitoring of Network Interfaces
- Who can see and do what
- Managing NetCrunch Access Profiles
- How alert messages read when they arrive
- Managing Alerting Message Formats
- What a monitoring pack applies to
- Monitoring Packs
ops-stop
Remove or Disable
Stopping monitoring is rarely one action. Usually you want it to stop for a reason, and NetCrunch has a distinct mechanism for each reason — which is why a node that is not being monitored always reports why. Start from the state the node is showing: the Disabled state and its causes are listed in Monitoring of Network Nodes.
- Outside working hours, or on days a system is not in use
- Time Restriction Scheme
- While something upstream is down, so one failure does not become a hundred alerts
- Preventing False Alarms
- For a particular action, under conditions where it should not run
- Action Restrictions
Actually Removing Something
NetCrunch separates two operations that sound alike. Remove takes a node out of a view. Delete from Atlas takes it out of NetCrunch entirely.
Removing a Node From a View
Select the node or nodes, then Node menu Node Actions Remove
The node stays in the atlas and stays monitored; only the view changes. On a filtered view there is nothing to take out — membership is decided by the filter — so NetCrunch adds the node to that view's exclusions instead, which is how it stops matching.
Deleting a node from an IP Network View deletes it from the atlas. That is not a change of view membership, it is a deletion — removing a node from other kinds of view only changes what the view contains. See Network Atlas Views.
Deleting a Node From the Atlas
Select the node or nodes, then Node menu Node Actions Delete from Atlas and confirm with Delete
Everything the node carried goes with it, and there is no undo. Multiple nodes can be deleted in one operation.
The confirmation offers to add to discovery exclusions, and on a network NetCrunch scans you almost always want it.
Deletion does not tell discovery anything. The next scan finds the address again and adds the node back, which reads as the deletion having silently failed. The exclusion is what makes it stick.
Two nodes cannot be deleted at all: the NetCrunch node itself and the NetCrunch Server Data node. The menu explains rather than simply refusing.
Through the REST API
The API covers deletion explicitly: see Nodes for deleting a node or a sensor, and Atlas Views and Folders for removing a node from a view.