We have a few sets of hosts that, for one reason or another, we’re not able to install the sensu client on. We only have ssh access. Is there any precedent for using a sort of proxy-sensu-client to run standard checks on remote hosts?
For instance, given a list of hosts and a list of processes to check for, is there a “good” way to run check-procs.rb via ssh? My initial thought was to just replace the “command” parameter in the check config to use “ssh $host /path/to/check-procs.rb -p $process -W 1”, but that would of course require making sure that the check-script was available on the remote host.
I’m wondering if anybody has setup something similar, in a dynamic way that centrally manages the check scripts using a git repo or configuration management recipe.
We use saltstack for CM, so I’ll probably manage it that way. Just checking to see if I’m reinventing any wheels here.
I have a similar situation. One way to not reinvent the wheel here is to use NRPE.
You say you have “ssh”, I’m assuming you don’t have root?
Even if not, I’m sure salt can run as non-root, as long as it is managing non-root resources, and nrpe can be run as your own user. (port 5666, or any port)
I use a puppet module to distribute and configure nrpe checks. On the sensu side you would have to make sure the check_nrpe plugin is installed (nagios-plugins-nrpe) and use nrpe as your proxy.
sensu-client check command:
/usr/lib/nagios/plugins/check_nrpe -H remote_host -c check_procs.rb -a $process
remote_host nrpe conf:
dont_blame_nrpe=1
command[check_procs.rb]=/path/to/check_procs -p $ARG$ -W 1
(reduce your security exposure by not passing args, and bake the process into the check command)
Works pretty well, you can use ip based lockdown and you do get over-the-wire encryption. One plus is you don’t have to have your sensu client ssh’ing in, and you get tightly controlled set of commands you can enable to be run. Additionally the check_nrpe plugin will simply pass on the check result and return code, which is sensu-compatible. That would be one way to do it.
No matter how you do it, you will have to run salt or distribute your check commands in some way to your host. NRPE wouldn’t solve that, but it would give you a mechanism by which to execute them.
···
On Mon, Feb 17, 2014 at 7:27 PM, Justin Rush jrush@flightstats.com wrote:
We have a few sets of hosts that, for one reason or another, we’re not able to install the sensu client on. We only have ssh access. Is there any precedent for using a sort of proxy-sensu-client to run standard checks on remote hosts?
For instance, given a list of hosts and a list of processes to check for, is there a “good” way to run check-procs.rb via ssh? My initial thought was to just replace the “command” parameter in the check config to use “ssh $host /path/to/check-procs.rb -p $process -W 1”, but that would of course require making sure that the check-script was available on the remote host.
I’m wondering if anybody has setup something similar, in a dynamic way that centrally manages the check scripts using a git repo or configuration management recipe.
We use saltstack for CM, so I’ll probably manage it that way. Just checking to see if I’m reinventing any wheels here.
Thanks, I hadn’t thought of that. In fact, in my long-ago experience with Nagios, I never used NRPE. I’ll look into it.
I do have root/sudo on these boxes.
···
On Mon, Feb 17, 2014 at 10:09 PM, Kyle Anderson kyle@xkyle.com wrote:
I have a similar situation. One way to not reinvent the wheel here is to use NRPE.
You say you have “ssh”, I’m assuming you don’t have root?
Even if not, I’m sure salt can run as non-root, as long as it is managing non-root resources, and nrpe can be run as your own user. (port 5666, or any port)
I use a puppet module to distribute and configure nrpe checks. On the sensu side you would have to make sure the check_nrpe plugin is installed (nagios-plugins-nrpe) and use nrpe as your proxy.
sensu-client check command:
/usr/lib/nagios/plugins/check_nrpe -H remote_host -c check_procs.rb -a $process
remote_host nrpe conf:
dont_blame_nrpe=1
command[check_procs.rb]=/path/to/check_procs -p $ARG$ -W 1
(reduce your security exposure by not passing args, and bake the process into the check command)
Works pretty well, you can use ip based lockdown and you do get over-the-wire encryption. One plus is you don’t have to have your sensu client ssh’ing in, and you get tightly controlled set of commands you can enable to be run. Additionally the check_nrpe plugin will simply pass on the check result and return code, which is sensu-compatible. That would be one way to do it.
No matter how you do it, you will have to run salt or distribute your check commands in some way to your host. NRPE wouldn’t solve that, but it would give you a mechanism by which to execute them.
On Mon, Feb 17, 2014 at 7:27 PM, Justin Rush jrush@flightstats.com wrote:
We have a few sets of hosts that, for one reason or another, we’re not able to install the sensu client on. We only have ssh access. Is there any precedent for using a sort of proxy-sensu-client to run standard checks on remote hosts?
For instance, given a list of hosts and a list of processes to check for, is there a “good” way to run check-procs.rb via ssh? My initial thought was to just replace the “command” parameter in the check config to use “ssh $host /path/to/check-procs.rb -p $process -W 1”, but that would of course require making sure that the check-script was available on the remote host.
I’m wondering if anybody has setup something similar, in a dynamic way that centrally manages the check scripts using a git repo or configuration management recipe.
We use saltstack for CM, so I’ll probably manage it that way. Just checking to see if I’m reinventing any wheels here.