Tech Tip - Auto Generation of Service Groups and other API fun

You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

This tech tip describes using the sg_autocreate script to automatically create service groups.

The use case for this script is as follows:
You need to generate service groups in the Foundation database so that they show up in the UI.
You have a lot of hosts and services, so using the UI to create these servicegroups is time consuming and tedious.
You have changes to the hosts-service combinations that you want represented in the service groups, and these happen regularly enough that it is desirable to automate the service group creation.

This script will make it possible to create service groups automatically on the commit of the configuration, using data from the existing hosts and services.
While you can run this script at the command line and so integrate it into your existing provisioning systems, we have included an example of calling it from the commit process using the integration module.

The script itself is heavily modular and commented, making it an ideal example for extending to other, similar functions as needed. We welcome your contributions in this regard, as always, and your suggestions for improvement and more use cases.

Here's how to install it and get it going:

Download all the files:

Place the files on the GroundWork server. Put:

in a directory on the GroundWork server where they can be accessed by the nagios user, e.g. /usr/local/groundwork/scripts.
You can lput agent_id in there too, if you like.
Make all the files owned by user nagios

chown nagios.nagios /usr/local/groundwork/scripts/sg_autocreate*

Make sure that the sg_autocreate script is executable:

chmod +x /usr/local/groundwork/scripts/sg_autocreate

Use the agent_id script to generate a unique id for the creation (and deletion) of the servicegroups you make using this script. You can use any string, as long as it is unique, but this makes a nice example.

agent_id = "59e53d98-a526-11e6-a10c-8170f6c82928"

The quoted string is randomized enough to be used as a unique agent identifier in the foundation database. Edit the file /usr/local/groundwork/scripts/sg_autocreate.conf and change the default agent ID to the one you generated, like this:

vi /usr/local/groundwork/scripts/sg_autocreate.conf
agent_id = "59e53d98-a526-11e6-a10c-8170f6c82928"

Also, while editing this file optionally change the application type to one you will recognize later, for example:

application_type = "AUTOGROUP"

Save the changes to the file.

Now you will need to add the application type to foundation. Let's say you used "AUTOGROUP" like the example above, though you can call it anything you like. Log in to the web GUI as an administrative user, and click on GroundWork Administration, chosing the first item in the menu, Foundation. That will show you this screen:

Click on Manage Application Types, then click the grey Add Application Type button, and enter the app type you set in the file, e.g. AUTOGROUP. You should see it listed in the resulting screen.

Next, decide what the membership of the service group will be. You can have multiple services in one group or just one. If you are making use of service instances, you can choose to use the base name of the service or the suffix, depending on what you want. If you use the base name, all instances will be included. If you use the suffix, all services with that suffix will be included.

You make these choices by editing the file /usr/local/groundwork/sg_autocreate_servicegroups.conf. There are examples in the file for you to work from.
For instance, if you wanted a service group called "App_checks", which contained all instances of the service "app_check" on all hosts, then you would put in:

   <service app_check>
        service_group = "App_checks"
        service_group_description = "App checks on all servers"

If you have a service like interface_status with instances named like _01, _02, _03, etc, you could capture them all with the configuration:


<service interface_status>
service_group = "interface_checks"
service_group_description = "interface checks on all systems"

If, however, you have services with instances named _myapp, and the base name of the service might differ, you can create a servicegroup with all the instances named _myapp with:

<service_instance _myapp>
service_group = "Service_checks_for_MyApp"
service_group_description = "All the MyApp checks"

{Note: the restrictions on service group names apply. No spaces are allowed.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.