I've been thinking about how we can build NRPE style checking into Blue, so I'd like to start a discussion around this.
With the work that I've been doing on the Dynamic Registry, I have created a very thin Blue Agent. This Agent could quite easily be extended to provide a 'NRPE service' which would essentially emulate the NRPE daemon from Nagios. As far as I can see from NRPE it is no more complicated that opening up a socket and listening for reuquests which are in the format
check_alias|check_args_if_allowed
This format seems to work so I don't think we should change it. I am also going to propose that we go with the idea of the check_nrpe plugin. This plugin could simply pass across the name of the plugin to be executed and any args to be used with it. We could also provide an option for the transport to use so that we support as many different network configurations as possible. So I guess the execution would be something similar to
This should also fit nicely with the dynamic registration work that I've been doing as when a Host registers, it could also open a socket listening for NRPE'esque checks at the same time.
For the minute we could provide a distribution of plugins that needs to be installed on each remote host to faciliate remote checking. Looking further ahead I really like the idea of providing a repository through which the remote host can dynamically download plugins as and when required.
Any thoughts on this?
cheers
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As discussed on the mailing list, there is now an initial version of an NRPE-esque daemon checked in. It is part of the Blue Agent code and can be started either as an individual service on the remote host, or can be used in conjunction with dynamic registration to allow for execution of plugins on dynamically registered hosts.
NRPE in Blue follows the same stance as NRPE in Nagios. The first of the components is a plugin called check_remote. The plugin has the following options:
-H = remote host to check
-P = Port of remote host to connect to.
-C = Name of check to execute
-T = transport to use to connect to remote host (currently socket only)
args = anything further is assumed to be args to the remote check.
The plugin is executed as with any other in blue, java -jar check-remote.jar and command defintions within Blue should be reflective of their distributed nature i.e.
With regards to how the command is configured on the remote host, currently it makes use of the configuration files that are associated with the Blue Agent. The configuration of commands is in the following format:
For this to work, the user must enabled allow_command_arguments in the configuration file of the Blue Agent.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-04-12
I agree NRPE and Blue Agent should be the same thing.
I think the repository idea is perfect, and a very very very simple
version of that would be to use http:// or https:// as the location of
the jars. Blue Agent can use http://my-blue-server/plugins/ as the
directory to pull in jar files. I know this is not a real repo
concept, but would work fairly well. JBoss use something like this
concept in one of it's startup modes. Similar to an applet.
Other option use jnlp to launch the agent?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All,
I've been thinking about how we can build NRPE style checking into Blue, so I'd like to start a discussion around this.
With the work that I've been doing on the Dynamic Registry, I have created a very thin Blue Agent. This Agent could quite easily be extended to provide a 'NRPE service' which would essentially emulate the NRPE daemon from Nagios. As far as I can see from NRPE it is no more complicated that opening up a socket and listening for reuquests which are in the format
check_alias|check_args_if_allowed
This format seems to work so I don't think we should change it. I am also going to propose that we go with the idea of the check_nrpe plugin. This plugin could simply pass across the name of the plugin to be executed and any args to be used with it. We could also provide an option for the transport to use so that we support as many different network configurations as possible. So I guess the execution would be something similar to
java -jar blue-check-nrpe -H <host_address> -P <port_of_listening_blue_agent> -T <transport> -A <args> .......
This should also fit nicely with the dynamic registration work that I've been doing as when a Host registers, it could also open a socket listening for NRPE'esque checks at the same time.
For the minute we could provide a distribution of plugins that needs to be installed on each remote host to faciliate remote checking. Looking further ahead I really like the idea of providing a repository through which the remote host can dynamically download plugins as and when required.
Any thoughts on this?
cheers
Rob
All,
As discussed on the mailing list, there is now an initial version of an NRPE-esque daemon checked in. It is part of the Blue Agent code and can be started either as an individual service on the remote host, or can be used in conjunction with dynamic registration to allow for execution of plugins on dynamically registered hosts.
NRPE in Blue follows the same stance as NRPE in Nagios. The first of the components is a plugin called check_remote. The plugin has the following options:
-H = remote host to check
-P = Port of remote host to connect to.
-C = Name of check to execute
-T = transport to use to connect to remote host (currently socket only)
args = anything further is assumed to be args to the remote check.
The plugin is executed as with any other in blue, java -jar check-remote.jar and command defintions within Blue should be reflective of their distributed nature i.e.
define command{
command_name check_remote_time
command_line java -jar blue-check-remote.jar -H $HOSTADDRESS$ -C check_remote_time
}
With regards to how the command is configured on the remote host, currently it makes use of the configuration files that are associated with the Blue Agent. The configuration of commands is in the following format:
command[check_remote_time]=java -jar blue-check-local-time.jar -H europe.pool.ntp.org -w 30 -c 50
when receiving a request to execute a command, the agent will consult it's list of pre-registered commands and then execute them accordingly.
The user also has the ability to pass command arguments to the remote command, so the above command definition could be refactored as follows:
command[check_remote_time]=java -jar blue-check-local-time.jar -H $ARG1$ -w $ARG2$ -c $ARG3$.
For this to work, the user must enabled allow_command_arguments in the configuration file of the Blue Agent.
Rob
I agree NRPE and Blue Agent should be the same thing.
I think the repository idea is perfect, and a very very very simple
version of that would be to use http:// or https:// as the location of
the jars. Blue Agent can use http://my-blue-server/plugins/ as the
directory to pull in jar files. I know this is not a real repo
concept, but would work fairly well. JBoss use something like this
concept in one of it's startup modes. Similar to an applet.
Other option use jnlp to launch the agent?