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 Dodawanie do NetCrunch'a for the full walkthrough of each route.
- Nodes
- Dodawanie węzłów do monitorowania
- Monitoring targets — services, sensors, monitoring packs
- Dodawanie celów do monitorowania
- Atlas views
- Dodawanie widoków atlasu
- Alerts
- Dodawanie alertów
Beyond those, three routes bring in more than one thing at a time:
- A configuration you have already worked out, applied to new nodes
- Szablon monitorowania węzła
- Everything an existing PRTG installation monitors
- Migracja z PRTG
- Whatever is on the network, found for you
- Autowykrywanie
ops-change
Change
- Settings across many nodes at once, rather than node by node
- Zarządzanie ustawieniami wielu węzłów
- The speed an interface's utilization is measured against
- Monitorowanie interfejsów sieciowych
- Who can see and do what
- Zarządzanie profilami dostępu użytkowników NetCruncha
- How alert messages read when they arrive
- Zarządzanie formatami komunikatów alarmowych
- What a monitoring pack applies to
- Pakiety Monitorowania
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 Monitorowanie węzłów sieci.
- Outside working hours, or on days a system is not in use
- Harmonogram ograniczeń czasowych
- While something upstream is down, so one failure does not become a hundred alerts
- Zapobieganie fałszywym alarmom
- For a particular action, under conditions where it should not run
- Ograniczenia dla akcji
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 Zarządzanie widokami atlasu sieci.
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 Węzły for deleting a node or a sensor, and Widoki i foldery Atlasu for removing a node from a view.