SSH based Monitoring
Click the link above if you are not automatically redirected in 10 seconds.
Overview
Secure Shell (SSH) provides encrypted terminal access to remote hosts, and also provides the ability for users to execute commands on the remote hosts. In simple terms, this means that a user on one host can use SSH to execute commands on another host in the same basic manner as if those commands were being executed locally, with the extra benefit of having the commands and response data being exchanged across a secure communications channel. This article discusses some best practices and general uses of SSH for monitoring. To see how to set this up in GroundWork 8, see How to monitor hosts using SSH.
Nagios provides an SSH plugin that can be used to build a variety of service profiles in GroundWork Monitor 8. In this setup, the administrator defines one or more profiles that describe the commands that need to be executed on the remote hosts, and also defines a global SSH username for remote login purposes. From there, Nagios is able to call the SSH plugin with the necessary parameters as needed, with the plugin establishing a secure connection to the specified host, executing the specified command, and then returning the program output to Nagios for processing.
This model is especially important when you need to monitor something that is only available on the local command line. Locally installed management utilities can often be wrapped by plugins that can be executed over an SSH session.
Apart from specific services that cannot be easily monitored, many administrators also use the SSH plugin to monitor system-level resources by simply copying the entire set of Nagios local commands to a remote host and then using the SSH plugin to login to the remote server and execute those commands. Although this is not technically required (there are several other means of obtaining most of the same data), this route can simplify data collection if an administrator has to use the SSH plugin for other tasks on those systems anyway. SSH is also a commonly allowed protocol (being encrypted helps satisfy security requirements), so this method is often used for convenience.
For these reasons, GroundWork Monitor 8 includes the plugins and profiles needed to execute "check_by_ssh" services.
In GroundWork Monitor 8, there is less of an opportunity to add custom plugins to the GroundWork internal Nagios container, and so custom plugins can be most easily added, run, and maintained separately via this method, via NRPE, or preferably via GDMA. In fact, installing GDMA on the GroundWork server is an easy way to load all the standard plugins and their dependencies, and gives you an easy way to add custom plugins to GroundWork Monitor 8. Combining this with check_by_ssh will let you run your custom plugins with minimal adjustments.
Configuring public key authentication
Once the steps in the above referenced how-to have been successfully completed, the Nagios SSH plugin should be able to seamlessly login to any target host that has the correct username and public key file. From this point forward, you will only need to be concerned with maintaining the key files for access - the passwords do not matter. One good practice is to disable password authentication on the individual systems, since they will not be needed by the plugin, and are not needed by anyone who has a key. Additional measures for further tightening access to the SSH plugin are discussed here http://www.linuxjournal.com/article/8759, if higher levels of security are needed or desired.
Managing remote commands
When Nagios issues a command on a remote server, it tries to ensure that the correct command is being called by looking for in a specific subdirectory under the primary user account's home directory. In order to ensure that the default set of SSH service definitions function as expected, it is necessary to ensure that these commands are copied into the appropriate subdirectory on the remote hosts. By default, this subdirectory is specified in the Nagios user22 macro definition, with the value of libexec (Configuration > Nagios Monitoring > Control > Nagios resource macros).
The GroundWork Distributed Monitoring Agent (GDMA) has an entire set of plugins and dependencies included, and is consistently maintained. These can be used via SSH as well as (or instead of) by the agents poller. GroundWork also provides (much older) downloadable Linux Plugin Packages for SSH Monitoring for both 32 and 64 bit architectures. You may use these packages of compiled plugins for SSH-based monitoring on hosts that you want to monitor with GroundWork. These packages are for generic Linux hosts, and are intended for convenience in monitoring legacy Linux systems. Most Linux variants will work. All the required libraries and Perl modules are included.
If the operating system and/or processor architecture of the target host is not supported by the GDMA or the compiled packages, you may need to download alternate plugins from internet sources, and install them on the target host system. Make sure to put them into the libexec directory under the SSH user account's home directory, and make sure that account has sufficient permission to execute the programs.
Related articles
-
SSH troubleshooting (Knowledge Base)
-
GDMA Monitoring (GroundWork Support 8)
-
Deploying Parent Child (GroundWork Support 8)
-
Cloud Monitoring (GroundWork Support 8)
-
Network Monitoring (GroundWork Support 8)
-
WMIC Monitoring (GroundWork Support 8)
-
Elasticsearch Monitoring (GroundWork Support 8)
-
Nagios Monitoring (GroundWork Support 8)
-
Application Performance Monitoring (GroundWork Support 8)