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 Hinzufügen zu NetCrunch for the full walkthrough of each route.
- Nodes
- Knoten zum Monitoring hinzufügen
- Monitoring targets — services, sensors, monitoring packs
- Ziele zum Monitoring hinzufügen
- Atlas views
- Atlas-Ansichten hinzufügen
- Alerts
- Hinzufügen von Warnungen
Beyond those, three routes bring in more than one thing at a time:
- A configuration you have already worked out, applied to new nodes
- Knotenüberwachungsvorlagen
- Everything an existing PRTG installation monitors
- Migration von PRTG
- Whatever is on the network, found for you
- Automatische Entdeckung
ops-change
Change
- Settings across many nodes at once, rather than node by node
- @managing-multiple-nodes
- The speed an interface's utilization is measured against
- Überwachung von Netzwerkschnittstellen
- Who can see and do what
- Verwalten von NetCrunch-Zugriffsprofilen
- How alert messages read when they arrive
- Verwaltung von Benachrichtigungsnachrichtenformaten
- 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 Überwachen von Netzwerkknoten.
- Outside working hours, or on days a system is not in use
- Zeitbegrenzung Schema
- While something upstream is down, so one failure does not become a hundred alerts
- Verhindern von Fehlalarmen
- For a particular action, under conditions where it should not run
- Aktion Einschränkungen
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 Verwalten von Netzwerkatlasansichten.
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 Knoten for deleting a node or a sensor, and Atlas-Ansichten und Ordner for removing a node from a view.