NPC Sites and Groups 3 of 7: Building the Groups

Part of a series of posts.  To see all posts, click here.

Back when NPC underwent a dramatic set of upgrades, one of the new features was the group tree. Administrators could now create groups of monitored objects that could be applied to pages as filters. Recently, the NPC developers added a context page so that users could actually drill into a site. Instead of applying a filter, NPC would take the user to a set of pages specifically designed to show a set of site overview reports for the objects in the group. These site groups are crucial to implementing the best group structure.

Calling back to a Best Practice document written by NetQoS several years ago, NPC administrators should create five groups under the root, /All Groups: All Sites, Regional, Line of Business, Reporting Groups, and zExcluded Items. Optionally, a sixth group could be added, zRetired Groups, where groups that should no longer be used can be retired without actually deleting them.

All Sites Group
This is possibly the most important group and should be built based on the Sites/Networks list. When creating these groups, create each group as a ‘Site’ type group. This will ensure that whenever NPC shows the site name, it will be a link to the Site context pages. You can also add other metadata about each site, such as location (think address or City if that information is not already in your site naming standard), latitude, and longitude (hopefully this information will be used in future revisions of NPC to plot your sites on a map). I suggest putting detailed information in the description field (i.e. LOB, Region, network subnets, site administrator, etc.).

After actually creating the site, you need to ensure that everything that is monitored at that site is included in the site group. First, make sure the ‘Include the children of managed items’ option is checked (found on the group properties tab). NPC includes a rules feature that can automatically add items to groups based on item properties like address. Make use of this feature to include everything that is monitored at the remote site.

Add Devices by IP Address
Create a rule to add devices based on the IP address. This rule should catch all devices discovered by NetVoyant, all servers monitored in SuperAgent, all servers monitored in UCMonitor and all routers sending NetFlow to ReporterAnalyzer. One rule should suffice for all the subnets, even if the site uses multiple non-contiguous IP address blocks.

Figure 1: Add Devices by IP Address Rule 

A little about rules: each group can contain multiple rules. All rules are OR’ed together, meaning that if an item matches any of the rules, it will be added to the group. Each rule can contain multiple filters. Filters are AND’ed together, meaning that an item will have to match all the filters in order to match the rule. Each filter can contain multiple arguments. Arguments are OR’ed together, meaning that an item only has to match one of the arguments to match the filter. So, (ready for this?) if an item matches at least one of the arguments, of all the filters, of any of the rules for a group, it will be added to the group. 

Using multiple arguments for this rule will allow you to create one single rule that will include all devices by their IP address. The nice thing about this method is that it simplifies your configuration but also catches all devices at that site (even if the device isn’t SNMP capable, since the only information required to match this rule is IP address which is obtained without SNMP capability). 

Add Devices by Name 

Adding a rule to include devices by name is optional. It would be best if the rule adding devices by IP address were enough. However, there may be circumstances in which a rule adding devices by name is advantageous. In this situation, add a rule that matches on name using ‘is like’ as the filter operator and a unique portion of the FQDN as the argument(s), as shown below: 

Figure 2: Add Devices by Name Rule 

There is one caveat to keep in mind if the FQDN contains numbers for the sites: if the FQDN for your sites contains site number, remember that two sites, named XYZ1 and XYZ10, will both match a filter where the argument is ‘XYZ1’. The way to prevent devices from XYZ10 from showing up in XYZ1 will depend on your FQDN naming standard, but can usually be accomplished by including the next character in the FQDN, which might be a dot (‘.’). 

Add Networks by IP Address 

Now that devices are added to the site group, we should have all devices from NetVoyant and ReporterAnalyzer added to our site group. We should have all servers from SuperAgent and UCMonitor added as well. However, we still need to add the SuperAgent networks to our group. Add a rule to add networks by ‘Network Subnet’. This type of rule matches the subnet definition in SuperAgent with a subnet provided as an argument of the filter. 

Figure 3: Add Networks Rule

I’ll go into detail later on how we’ll use the information from the Sites/Networks list to generate the subnets that will match these arguments.

Add VoIP Locations by Name 
Building rules to collect UCMonitor locations into the site group requires the locations be setup in UCMonitor a specific way. I’ll talk later on about what to put into each of those locations. For now, suffice it to say that the Sites in NPC and the Locations in UCMonitor should have a 1-to-1 relationship. Therefore, it would be best if the names of the locations in UCMonitor matched, at least in part, the names of the sites in NPC. If this is the case, a simple rule can be built to ensure that the UCMonitor locations for that site are included in the site group based on the name.

Figure 4: Add VoIP Locations Rule

Regional and Line of Business Groups
Now that site groups have been created, the /All Groups/Sites group should be considered the permanent home for these groups. In fact, it might not be a bad idea to name the group /All Groups/All Sites so that it appears near the root of the tree. The All Sites group now contains the building blocks to build other standard reporting groups. Based on the information in the Sites/Networks list, groups can be created grouping sites based on geographical location and/or line of business. NPC allows referential copies of existing groups to be added to new groups. Instead of rebuilding groups for each of the sites, copy the existing site groups into their regional groups. Based on the example Sites/Networks list, the regional and line of business grouping would be built as shown below:

Figure 5: Regional Group Structure	Figure 6: Line of Business Group Structure

Reporting Groups
Again calling back to a Best Practice document published by NetQoS several years ago, a group should be created to contain groups that must be created for specific reporting purposes. Usually, these reports would include objects that span multiple sites. For example, a group may be created called /All Groups/Reporting Groups/Telecom which might contain only the devices involved in telecom. Some sites might have dedicated Voice routers, while others may piggy back on the WAN router to provide VoIP to the site. Neither of these situations precludes the existence of other routers in the same site group. The Telecom group may or may not be populated using rules, depending on the situation.

Another example of a reporting group would be to group several LOB’s together to compare against each other. Using our example company, this could be a group to compare Data Centers against all other LOB’s (Sales and Corporate). The new group could be called /All Groups/Reporting Groups/DC vs Non-DC and have two subgroups: Data Center (which would simply be a referential copy of /All Groups/Line of Business/Data Center group) and a new group (/All Groups/Line of Business/Non Data Center) containing referential copies of /All Groups/Line of Business/Corporate and /All Groups/Line of Business/Sales Office.

Figure 7: DC vs Non-DC Reporting Group

Since we used the LOB groups, which contain the Site groups, which are built on rules, we shouldn’t have to update the DC vs Non-DC group very often.

zExcluded Items
Since rules are used, there needs to be a way to check to make sure the rules worked. This is where the zExcluded Items group comes in. This group uses rules to find items not included in the All Sites group. Making this group is fairly easy, given the allowable rule options. The rules used for this group check for items that are not members of another group, specifically, the All Sites group.

Figure 8: Finding Devices not found by the All Sites Rules

Adding other rules to find SuperAgent Networks and UCMonitor Locations not found by the All Sites rules should give a comprehensive list of what objects are not being properly assigned to an existing site. Membership in this group can also indicate new sites that have come online that don’t adhere to the group standards defined in the Sites/Networks list.

NPCCmd and XML
NPCCmd is a utility built into NPC that allows for group definition import and export via XML. Using the site list and a Microsoft utility called the XML Notepad 2007, anyone can create an XML file to import into NPC that will add/modify group definitions.

To be continued...