Tech Tip 5 - Auto Generate Service Groups

compared with
Version 16 by Bren Eckles
on Apr 15, 2019 10:42.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (45)

View Page History
h1. This tech tip describes using the sg_autocreate script to automatically create service groups.
h1. Tech Tip 5 (11/2016) - 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 MonarchCallOut.pm 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.

h24. Here's how to install it:

Download all the files:{attachments:patterns=sg_autocreate,sg_autocreate.conf,sg_autocreate_servicegroups.conf,agent_id,MonarchCallOut.pm}
{attachments:patterns=sg_autocreate,sg_autocreate.conf,sg_autocreate_servicegroups.conf,agent_id,MonarchCallOut.pm}

Place the files on the GroundWork server. Put:
*sg_autocreate_servicegroups.conf*

in a directory on the GroundWork server where they can be accessed by the nagios user, e.g. */usr/local/groundwork/scripts*. This directory is where it is set up to go, so if you use something else, you will need to change the paths in the config files.
You can put *agent_id* in there too, if you like. You only need to run it once, usually, as part of setup.

Make all the files owned by user nagios:
chmod +x /usr/local/groundwork/scripts/sg_autocreate
{code}
Do the same for the *agent_id* script.

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.
{code}
./agent_id
application_type = "AUTOGROUP"
{code}
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, choosing the first item in the menu, Foundation. That will show you this screen:\\ \\
!GW-fa.jpg!
!GW-fa.jpg|thumbnail,border=1!

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:\\ \\
!GW-fa2.png|thumbnail,border=1!

!GW-fa2.png!
h4. Choose your service group members

h2. Choose your service group members
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.

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:

{code}

<service app_check>
service_group = "App_checks"
{code}

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

{code}

<service interface_status>
service_group = "interface_checks"
{code}

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:

{code}
{note} the restrictions on service group names apply. No spaces are allowed. {note}

h4. Run the script and create the groups

h2. Run the script and create the groups

Once you have it looking the way you want, you can run the script as user nagios:
{code}
{code}

Then check the Status view for your new service groups. They will be there within a few seconds.

h4. Cleaning up and formalizing

h2. Cleaning up and formalizing

If you want to *remove* any of the groups you create in this way, just comment them out of the /usr/local/groundwork/sg_autocreate_servicegroups.conf file. They will be removed the next time you run the script.
{note}The agent ID and application type are associated with these groups in the database. If you overwrite these values in the config file, removing the groups with the script will no longer work, and you would need to remove them by modifying the database directly. {note}

{noformat}

Now whenever you run a commit, you will see the output from the script at the end. This will add some processing time. Depending on the size of your deployment, you may or may not want to do it this way.\\ \\
!GW-mc.png|thumbnail,border=1!

!GW-mc.png!
h4. See also

h3. See also

The APIs we are using are all documented here:
* [dassMonarch|https://kb.groundworkopensource.com/display/DOC67/Perl+API+Monarch]
* [Foundation REST API|https://kb.groundworkopensource.com/display/DOC71/RESTful+API+Documentation]

We hope you find this useful and informative. Thanks for reading\!