Managing a large number of monitored elements is a challenging task. It's easy to start with some simple solutions based on configuring simple sensors or agent scripts.
Yes, it is simple at the beginning. IT systems were there 20 years ago with authentication management. A growing number of users was the reason for moving from a flat user database (i.e., Windows Domains) to the hierarchical structures with policies (LDAP, AD).
Nowadays, the number of devices and services that need to be monitored has reached the level where managing them one by one is impractical and impossible in most cases. NetCrunch helps many organizations replace multiple monitoring instances controlled by designated people. In effect, these experienced people can be freed out of daunting, repetitive tasks and moved to other essential ones.
The digital transformation requires the same number of people to perform more duties, as usually, IT is growing, and the IT budgets are not.
You can create multiple users, and each user has its custom notification profile. Each profile has its own notification schedule, so you can set to receive SMS messages only on a particular day and time, and otherwise, you can get an email.
It's much easier to manage notifications using groups. You can add and remove users to groups without changing any alerting scripts which always refer to a given group.
NetCrunch allows creating complex notification schemas through escalation such as
Because every member of the group has a custom profile, he will receive a notification when he wants and the way it has been specified to be delivered.
You can manage access to the NetCrunch program, its views, and even particular nodes. Because the Atlas is a hierarchical structure, the rights are inherited from top to bottom.
Top alert setting levels are
There are three access rights:
deny- access is denied even if it is granted at a higher level
access- this is read-only access to the element
manage- the user can manage settings of the element
Read more at Managing NetCrunch Users and Notifications
You can assign any node to the given organization. The people assigned to a given organization group will see only nodes from their organization group.
Imagine you need to set access for each view and node to different organizational groups - it's going to be a daunting task.
You can assign nodes and persons to the organization groups, and all node views will accordingly display the filtered nodes.
There are two meta groups -
<root> visible to the top-level administrators and
<public> visible to anybody.
When you are a top-level administrator, you can select the organization filter from a combo box.
Reusability is essential in keeping control over complex settings. You can use the same rules and rule sets (Monitoring Packs) to avoid duplication and mistakes.
NetCrunch uses Monitoring Packs to control the monitoring settings. The settings consist of alerting rules and Data Collectors, which are mainly used for collecting data needed for reports.
These settings are assigned to nodes manually or by the node filtering rule.
Monitoring Packs are real policies. Unlike simple settings templates, they work as the policy, which means that regardless of how they are associated with the node (by the rule or manually), any change in the monitoring pack is automatically applied to the relevant nodes.
The changes to alerting rules or actions can override inherited policy settings.
You can also turn any existing Atlas views into policy by adding alerting rules to them and avoiding creating duplicated node groups.
Besides creating filtered views, NetCrunch allows building multiple views grouped by specific attributes and located in one folder.
This NetCrunch feature allows creating many pre-defined views which you can treat as examples of what you can do.
The folder requires a filtering condition, such as any dynamic view. In fact, the folder can be a single view when there are no groups.
Now we can define how to group the nodes to build each view. We need to select the grouping attribute (it doesn't need to be part of the filtering condition) and a minimum number of nodes required to create a separate view.
Templates are another kind of policy that goes beyond the single monitor and Monitoring Pack scope.
Monitoring templates allow a higher level of monitoring settings management than Monitoring Packs because they combine each monitor (a section) and sensor or Monitoring Pack.
Monitoring template nodes allow defining multiple setting sections of the node and then applying them to nodes. You can see settings for SQL Server node with parameters for Windows machine services and node status on the screen below.
These templates can be partially applied to the node, and any section can be overridden on the node level.
We have added these features to a separate module as they are targeted at the advanced monitoring system users with multiple administrators' teams and many monitored elements.
We will continue to add more configuration features to this module, thus managing infrastructures with tens of thousands of elements.