Documentation forSolarWinds Platform Self-Hosted

Nested groups

Groups can contain groups as members. These are called nested subgroups. Creating groups with nested subgroups can be a complicated task if not properly planned. Planning and some insight into the behavior of the Manage Groups interface can help speed the creation of groups and minimize troubleshooting. For example, let’s say I want to add all devices in a remote site called building 7, but I also want to group these devices by floor. I could create a group for Bldg 7 and assign all devices in Bldg 7 to the group, perhaps by using a dynamic query returning the Location field.

This will add all managed nodes that have the Location in their config set to Bldg 7. The location OID in MIB2 is a field Orion automatically polls and stores for all managed objects. This will work if all of the managed nodes in building 7 have exactly the same OID value of Bldg 7. If some were added with Build 7 or Bld 7 or a number of other nonstandard location indicators, they will be omitted. While dynamic queries can be a powerful method of managing group membership, they can cause great trouble if misapplied.

Let’s examine some more information about building 7. We find in the IP scheme that building 7 was designed to have one 10.7.X /24 subnet for each of its floors. The first floor is 10.7.1.0 /24, the second is 10.7.2.0 /24 and the third is 10.7.3.0 /24. This IP scheme is enforced in the routing protocol and by ACLs. With this information we can create the groups for building 7 and all the subgroups quite easily. Here are the steps:

  1. Create an empty group called Bldg 7.
  2. With the Bldg 7 group checked add a group called Bldg 7 1st floor.
  3. Create a dynamic query for the Bldg 7 1st floor using IP Address begins with 10.7.1. (Be sure to use the trailing dot, otherwise the query is equally valid for .10 and .100, which are not valid first floor systems according to our schema)
  4. Repeat steps 2 and 3 for all other floors, changing the group name and IP address query to match the floor number.

Once all the above steps are completed, we have created a group for building 7 containing a subgroup for each floor. There is no need to add each individual node directly to the Bldg 7 group as they are all members of Bldg 7 by being members of one of the subgroups. This can be helpful in minimizing duplicate alerts and duplicate report entities and saves the time that would be used to add items to the Bldg 7 group and then to the proper subgroup.