--- GW IMAGE NOT DISPLAYED --- Advanced Configuration – Defining Groups

Copyright 2006 GroundWork Open Source, Inc. (“GroundWork”).
All rights reserved. Use is subject to GroundWork commercial license.


Defining Groups

--- GW IMAGE NOT DISPLAYED --- How Do I Define and Manage Groups?

New Group

  1. Select Groups from the Configuration menu options.
  2. Select New.
  3. The New Group screen will be displayed.
  4. Enter a Group Name. As Hosts are assigned to Groups they will be found in files named <group_name>_hosts.cfg and their Services will be found in <group_name>_services.cfg. Group names must therefore conform to file naming standards.
  5. Select Add to go to the next screen, Manage Group.

    Figure 5.11.1a. New Group


Manage Group – Detail

  1. In the Detail tab, enter the properties (see Table 5.11.1b. below).
  2. Select Save to add the new Group. Delete will remove the Group. Select Rename to change the name of the current Group. The Close option exits the Manage Group screen without saving.

    Figure 5.11.2a. Detail


    Table 5.11.1b. Detail

    Name Group name.
    Description [Optional] Store comments or instructions here.
    Contact Groups Contact Groups assigned to Groups provide the default Contact Group for Hosts and Services where no Contact Group has been defined at the Host Group, Host, or Service levels. With Nagios®, Contact Groups are assigned separately to Hosts and to Services or Host Groups. GroundWork still allows the Nagios® 1.2 method of assigning Contact Groups to Host Groups. Even when they share the same Contact Group it still requires administration at two points. Setting the Contact Group on a Group eliminates this redundancy.

    Note: Contact Groups defined on a Group WILL OVERRIDE the Contact Groups defined on Host Templates and Service Templates. Also, Contact Groups assigned to Child Sub Groups will in turn override Contact Groups on a Parent Group.

    Group Status Setting the Group to inactive will remove the member Hosts and their Services from the Nagios® GUI’s and place them in the _Inactive Host Group in Status Viewer (GroundWork Monitor), while preserving their configurations. Hosts can be reinstated by simply removing them from the Group with the inactive setting, or removing the inactive setting for the Group.
    Multiple Instances –
    Build Instance Properties:
    Build Folder
    Multiple Instances – Groups provide the means to centrally administer Multiple instances of Nagios®. Each instance is a Group and a Group can be a Parent to a Group of Child Sub Groups. Note that with each Group, the left tree navigation provides links to its own Nagios® CGI configuration, its own main Nagios® configuration and its own set of Nagios® resource Macros. GroundWork does not at this time officially sanction a method of deployment. The Build Instance option will generate the appropriate set of files for the instance in the writable folder specified, and then call the deployment module MonarchDeploy.pm. There is also the option to simply export these files.

    Tree Menus

    • Nagios® CGI – Use this option to configure this instance’s Nagios® CGI configuration.
    • Nagios® CGG – Use this option to configure this instance’s main Nagios® configuration.
    • Resource CFG – Use this option to configure this instance’s Nagios® resource macros.
    • Pre flight test – This option does a Nagios® pre flight test (nagios –v) of the group or instance.
    • Build instance and Deployment – Use this option to generate the Nagios® configuration files for this instance, and to call the Deployment module.
      You will find the MonarchDeploy.pm module in the monarch/lib folder of your installation (Note: if you are using the stand alone version this is the installation path /lib). The module is called from the Build instance option under the group, and left unmodified is does nothing. There are some sample subroutines in the module with documentation. You will likely need at least some Perl skills to implement an automated deployment, but you might also simply call a shell script.
    • Export – This option generates a downloadable set of Nagios® configuration files for thei instance.

    Build Instance Properties; these are located on the Detail tab of Manage Group and include the following Build Folder, Nagios® etc Folder, Force Hosts, and Force Checks. If you are not administering Multiple Instances of Nagios® ignore these properties. They are not necessary to run a pre-flight check against a Group.

    Build Folder – This is a web account (nobody on GroundWork installations) writable folder used to stage builds. When Build instance is executed, this is the folder where the Nagios® files are written. Enter the web service writeable folder for this distribution. An incorrect entry or a folder with the incorrect permissions will cause the build instance to fail.

    Nagios® etc Folder This is the folder on the target Nagios® Host where the configuration files reside. The nagios.cfg file will be built using this path. Enter the path of the Nagios® configuration folder on the target Host. The value here will only be used to generate the nagios.cfg file, but it should reflect the actual location on the target Host where the Nagios® object configuration files will reside.
    Force Hosts Select this option to dictate the list of Hosts to be included in this instance. This option will override the Sub Group Host lists while still applying the Macros from those Groups where common members reside.
    Force Checks Use this option to override the values set on Hosts, Services and their Templates. Typically, in a multi-instance Nagios® implementation, the Parent monitoring Host runs with Passive Checks while the Child monitoring Hosts run with Active Checks. Depending on how your Hosts are currently configured, enable Force Checks and select the appropriate Active/Passive option.

Manage Group – Host Assignment

Hosts and Services are written to Nagios® configuration files based on Group Names. By default all Hosts are written to hosts.cfg and all Services are written to services.cfg. As previously mentioned, as Hosts are assigned to Groups they will be found in files named <group_name>_hosts.cfg and their Services will be found in <group_name>_services.cfg. Group names must therefore conform to file naming standards.

If you are using Groups to distribute Hosts and Services into different Nagios® configuration files you will want to use Host Groups where Host members don’t overlap, or add Hosts individually to each Group. The draw back to the latter option is that with each new Host you will need to assign it manually to a Group, whereas Host assignment with Host Groups is automatic (e.g. When the Host is assigned to the Host Group). Where Host membership overlaps one or many Groups, the Host is assigned to the file of the last Group read. Groups are read in dictionary sorted order.

  1. In the Hosts tab, check a box for Host Assignment by Hosts individually or by Host Group. The preferred method is to assign Host Groups as new Hosts will be included here when they are assigned to the Host Group.

    Figure 5.11.3a. Host Assignment


Manage Groups – Sub Groups

Sub Groups are useful only in special circumstances, in particular to build multiple instances of Nagios®. Should one find the need for them bear in mind that Hosts and Services will be assigned to the file of last dictionary sorted Child Group in which they are found. Conversely, where Macros overlap the value is taken from the first dictionary sorted Parent Group. In other words, once a match has been made and the Macro replaced, it will no longer be recognized as a Macro when subsequent Groups are processed.

  1. In the Sub Groups tab, select from the bottom list of existing Groups and select Add Group(s) to assign Groups. Select from the top list and select Remove to un-assign Groups.

    Figure 5.11.4a. Sub Groups


Manage Groups – Macros

The following steps and figures will walk you through an example of a Service Check that is performed through multiple proxies (WMI proxies in our example).

Step 1 – Commands

  1. Group Macros extend the Nagios® $ARG#$ Macros on Service Checks. The next two screens show how the Macro %PROXY% extends the definitions from the Command syntax through the Service Check.

    Figure 5.11.5a. Command Properties


Step 2 – Services

  1. By creating a Service and using a Macro in place of the Proxy argument, you can apply the Service to multiple Hosts and each Host will inherit the value from the Group to which it is assigned. Normally you would assign real values to Command arguments in Service Checks. Group Macros allow you to set and manage these values at the Group level.
  2. Here we replace the previous Command line with Macros with the Group Macro%PROXY%.
  3. For our example, you will need to create Host Groups; Windows HostGroup1 and Windows HostGroup2 with Hosts Windows1 and Windows2 assigned, respectively.

    Figure 5.11.5b. Service Check


Step 3 – Service to Host Assignment

  1. In the Service tab of Manage Host you can add, modify, and remove Services for the current Host. Note: Managing Services from this page will in all likelihood put the Host out of sync with its Service Profiles. After making changes, use caution when applying Profiles to this Host. Continuing with our Proxy example we add the Service wmi_exchange_mailbox_sendq to the Hosts Windows1 and Windows2.

    Figure 5.11.5c. Service to Host Assignment


    Figure 5.11.5d. Service to Host Assignment


Step 4 – Add Macro

  1. Here we will create our Group Macro %PROXY%. Enter a Name, Description, and Value for the Macro, then select Add New Macro.

    Note: Great care needs to be taken in Macro names. Do not use any names from the list of Nagios® macros for instance. Use names that are unique and not likely in the least to match some other part of the Check Command string. For example, a naming scheme that uses a special character such as % in the prefix and suffix of the name will likely maintain uniqueness, so a proxy Macro might be named %PROXY%. It is not a good idea to use $ as that is the special character Nagios® uses in Macros.

    Figure 5.11.5e. Add Macro


Step 5 – New Group, Assign Host Group, Set Macros (Group 1: Windows_WMI_Proxy1)

New Group (Group 1: Windows_WMI_Proxy1)

In the next set of steps we will create our new Groups (Windows_WMI_Proxy1 and Windows_WMI_Proxy2), assign a Host Group to our Groups (Windows1_HostGroup and Windows2_HostGroup), and set the %PROXY% Macro to each Group.

  1. Select Groups from the Configuration menu options.
  2. Select New.
  3. The New Group screen will be displayed.
  4. Enter the Group Windows_WMI_Proxy1.
  5. Select Add to go to the next screen, Manage Group.

    Figure 5.11.5f. New Group Windows_WMI_Proxy1


Assign Host Group (Host Group 1: Windows1_HostGroup)

  1. Select the Hosts tab.
  2. Select Windows1_HostGroup from the list of Host Groups at the bottom of the screen.
  3. Select Add HostGroup(s), you will see the Group now listed at the top of the screen.
  4. Continue with Set Macros below.

    Figure 5.11.5g. Host Assignment


Set Macros (Group 1: Windows_WMI_Proxy1)

  1. Select the %PROXY% Macro from the list at the bottom of the screen and click Add Macro(s) to assign it to the Window_WMI_Proxy1 Group.
  2. Adjust the values as needed and select Save to apply it to the Group. Well keep the value
  3. To use the Label option you must select Enable label and enter a value, then click Save to apply it to the Group. The value is appended to the Service description on Services where the Macro is found, so we suggest using an underscore as the first character.

    Note: The Enable Label option can be useful where there is a need for redundant Checks. To illustrate, using our Proxy example, it may be beneficial to run the Checks through a second proxy as a failover measure. Using this option eliminates the necessity of creating a second set of Services. By assigning the a Host to two Groups, each with the %PROXY% Macro but assigned different values, enabling the label option and assigning a value will generate a second set of Checks on Services where the %PROXY% Macro is found. The Label is appended to the Service description on the second set of Checks, so we suggest using an underscore at the start of the Label value.

  4. Repeat the last three steps for the second Group starting with New Group (Group2: Windows_WMI_Proxy2) below.

    Figure 5.11.5h. Set Macro


New Group (Group 2: Windows_WMI_Proxy2)

  1. Create the Group Windows_WMI_Proxy2.

    Figure 5.11.5i. New Group Windows_WMI_Proxy2


Assign Host Group (Host Group 2: Windows2_HostGroup)

  1. Assign the Host Group Windows1_HostGroup to the Group Windows_WMI_Proxy2.

    Figure 5.11.5j. Host Assignment


Set Macros (Group 2: Windows_WMI_Proxy2)

  1. Assign the %PROXY% Macro to the Window_WMI_Proxy2 Group.
  2. Adjust the values as needed and select Save to apply it to the Group. Well change the value to
  3. Figure 5.11.5k. Set Macros


Step 6 – Export

Tools Export (Group 1: Windows_WMI_Proxy1_services.cfg)

Macro values are substituted during a Pre flight test, Commit, and Export; in each case, Nagios® reads them from the files that have been generated. Group Macros are virtually unlimited but unlike Nagios® Macros, they can only be used on Service Checks and not in Command definitions.

Figure 5.11.5l. Windows_WMI_Proxy1_services.cfg


Tools Export (Group 2: Windows_WMI_Proxy2_services.cfg)

Figure 5.11.5m. Windows_WMI_Proxy2_services.cfg


Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment