GDMA has a lot of features, and one of the newest ones is "Auto-Setup". What this feature does is detect configuration of systems through a variety of means, and then sets up the GDMA client to monitor that configuration. It is done at the host level, so while your auto-setup "instructions" can be the same for all hosts, every host can be configured and monitored differently. You can "trigger" auto-setup to update the configuration whenever you like, so you can get very, very close to fully automated monitoring.
As of this writing, the auto-setup instructions are still being reviewed, so there's no extensive documentation yet. That's no reason not to get started with a useful example, so in this tech tip, we will go over how you set up your Windows hosts to use auto-setup to detect the drive letters on your systems and monitor them.
If you don't have GroundWork Monitor 7.2.1 installed yet, you will want to do that first. This tech tip assumes a fully-patched (as of this writing) 7.2.1 system. So, go ahead and download the latest version of GroundWork Monitor, run through all the technical bulletins, especially the Rollup Patch Installer, and download the latest GDMA 2.6.2 (recommended) version. The GDMA version 2.6.2 was released after the GWME 7.2.1 version and therefore will not be available locally on your 7.2.1 system.
We are attaching a new gdma?win?host host profile and gdma?windows service profile to this tech tip. This is a more generalized version of the gdma?21?windows service profile. Its name is different, so it won't conflict with the default, and the main difference besides the profile name is a new service called "gdma_wmi_disk_", along with a service external of the same name. Why the trailing underscore? Well, it's a style choice, but you will see why it makes sense, below.
This will put the three files you need into the Uploaded directory of the profile store.
This example works best on a system with at least two drive letters. Let's say you have drives C: and Q: on your Windows system.
Off by default, this option is in the gdma_auto.conf file starting with the GDMA 2.6.1 release. It must be set in the gdma_auto.conf file; it cannot be set in host externals.
The instructions and trigger files are really short, but it's a good idea to keep them somewhere consistent. This is what we recommend:
You need to name it something that ends with "_instructions". We will use "winpattern_instructions".
Similarly, you need to name trigger files to end with "_trigger", so we will use "winpattern_trigger".
Auto-Setup needs to have the instructions and trigger files in a specific location, and manage them itself. You always install the instructions first, then the trigger. This is so the trigger can be used and then ignored until re-installed (thus triggering another pass of discovery). Here's how you do it, with the autosetup command:
Use the hostname for the Windows host where you have GDMA installed, set to use auto-setup.
Now, whenever you are ready, start GDMA on the client system (net start gdma), and the host will show up in Monarch with the following services:
Run a Control > Commit operation to instantiate the services.
You will have also imported performance definitions with the profile, so all these services should have graphs associated in the Status and Grafana applications.
How does it work? Well, the detected drive letter is found by the auto-setup discovery processing on the Windows host, and passed as a macro to the service definition in Monarch. There, it's used as an instance name for a service instance on the gdma_wmi_disk_ service. (Which is to say, we will end up with monitoring for gdma_wmi_disk_C and gdma_wmi_disk_Q service instances in our example.) That's why we left the trailing underscore, but more importantly, that trailing underscore is something we like to use to signal that the service is intended to be used with auto-setup and instances. You certainly could not do it that way, and instead carry along the underscore in the instructions, like this:
Thus, using the underscore directly in the base service name is a style choice.
You can now apply auto-setup to more hosts. What you will want to do next is add instructions and then triggers for all your hosts. If you have a list of hostnames, you can use xargs to loop over the list, installing the instructions files for all of those hosts in bulk, using a command like the following. Here we assume your list is in a file in the current directory called "listofhosts", with one host per line.
You can use a similar command to install the triggers:
You can check the status of the hosts you prepare in this way with:
See the autosetup ??help command for a nice description of all the options.
|The autosetup ??help output requires your terminal type (the TERM environment variable) to be set properly. This is normally taken care of for you when you log in, say by ssh copying the terminal type from your local terminal window or terminal emulator to the remote login setup, (for logging in from an ordinary Linux terminal these days, xterm?256color is a common terminal type). If you see strange characters in the help text, just adjust your terminal type. You'll want that anyway so other commands like man and vim work properly.|
As of GDMA 2.6.2, there's no option to enable auto-setup automatically when you install GDMA, though we do plan to add that to a future release. For now, just create your own gdma_auto.conf file and supply it as part of your GDMA install, turning on auto-setup in that file as you did above. Just install GDMA without starting it, replace the gdma_auto.conf file, and start GDMA. Auto-Setup will then do the rest.
Questions? Problems? Let us know at GroundWork Support.