Hi,
the problem with the command path is that it contains multiple elements, you cannot simply add a space in the middle of strings. Icinga takes care of shell escaping and as such, /usr/bin/python2.7 /usr/lib/nagios/plugins/check_... is treated as a whole string resulting in '/usr/bin/python2.7 /usr/lib/nagios/plugins/check_...'.
execvpe() takes that as a first argument, whose lookup fails. Thatâs what the error says. With providing two argument items, it will work again.
Base Command
I would also recommend to rename Python into PythonBin to give it a more descriptive name.
const PythonBin = "/usr/bin/python2.7"
Note the array elements separated with the comma.
command = [ PythonBin, PluginDir + "/check_fujitsu_eternus_dx.pyc"]
Arguments
The command arguments need to be put into the arguments attribute, just like you had if before. I would recommend to follow the guidelines for integrating a new CheckCommand object though. This includes using the commandâs name as parameter prefix.
Also, extract the parameter description from the plugin, and add it next to value. That allows to identify the parameter easier later on.
arguments = {
"--host" = {
value = "$fujitsu_eternus_dx_address$"
}
"--user" = {
value = "$fujitsu_eternus_dx_user$"
}
"--verbose" = {
value = "$fujitsu_eternus_dx_options$"
description = "1 - general mode, 2 - detail mode"
}
}
Btw - I highly recommend to close the brackets in the same tab indent where the attribute is defined. Nagios used a different style guide with a tab indent there, which is sort of creepy and hard to read.
ARG1?
The remaining question is what you would pass into ARG1 from the old monitoring world. Is that a free form list of parameters, which additional oneâs are possible for the plugin?
Found it, next time please add an URL to it.
https://www.fujitsu.com/global/support/products/computing/storage/download/nagios-plugin.html
The manual also says that --user2 is available, add that to the generic CheckCommand object.
"--user2" = {
value = "$fujitsu_eternus_dx_user2$"
}
Looking at page 25, the plugin developers added quite a few more parameters to the plugin, but were too lazy to write command definitions and docs explaining each parameter again. I wouldâve expected this in the base table for the command parameters, but anyways.
Extra Arguments
Instead of putting in a list of extra arguments, I would modify that into optional arguments you can define.
The list in the PDF has:
--warning--critical- Various check types prefixed with
--chk
--uom--performance--remoteboxid
The different check types are sort of a problem, since they are hardcoded into the parameter key, not sent as extra value.
I see two options:
- Specify the type as String in the service and automatically âgenerateâ the parameter based on this.
- Add boolean parameters with set_if to only set them on-demand when specified in the service
For simplicity I would recommend the second option.
object CheckCommand "fujitsu_eternus_dx" {
command = [ PythonBin, PluginDir + "/check_fujitsu_eternus_dx.pyc"]
arguments = {
"--host" = {
value = "$fujitsu_eternus_dx_address$"
}
"--user" = {
value = "$fujitsu_eternus_dx_user$"
}
"--user2" = {
value = "$fujitsu_eternus_dx_user2$"
}
"--verbose" = {
value = "$fujitsu_eternus_dx_options$"
description = "1 - general mode, 2 - detail mode"
}
"--warning" = {
value = "$fujitsu_eternus_dx_warning$"
description = "Warning threshold"
}
"--critical" = {
value = "$fujitsu_eternus_dx_critical$"
description = "Critical threshold"
}
"--performance" = {
value = "$fujitsu_eternus_dx_performance$"
description = "Performance mode, available options: P" //TODO: Add more options
}
"--uom" = {
value = "$fujitsu_eternus_dx_uom$"
description = "Set the required unit of measurement for performance data metrics."
}
//Add all available modes and set the parameters whenever enabled in the service.
"--chkvolumes" = {
set_if = "$fujitsu_eternus_dx_chkvolumes$"
description = ""
}
"--chkraids" = {
set_if = "$fujitsu_eternus_dx_chkraids$"
description = ""
}
"--chkrecpaths" = {
set_if = "$fujitsu_eternus_dx_chkrecpaths$"
description = ""
}
//TODO for you: Add more chk parameters based on the docs.
// Special handling for remoteboxid - only add the parameter with the value when the specific command type is used
"--remoteboxid" = {
value = "$fujitsu_eternus_dx_remoteboxid$"
description = ""
set_if = "$fujitsu_eternus_dx_chkrecpaths$"
}
}
}
A typical Service definition is rather short and readable, without those parameter hacks after the ! character. Typically errors in check execution source from free form arguments, thatâs why Icinga 2 follows a different approach with generic check command objects.
apply Service "eternus-raids" {
check_command = "fujitsu_eternus_dx"
vars.fujitsu_eternus_dx_chkraids = true
vars.fujitsu_eternus_dx_warning = "N1"
vars.fujitsu_eternus_dx_critical = "M1"
vars.fujitsu_eternus_dx_performance = "P"
assign where host.vars.vendor == "fujitsu" && host.vars.hw_type == "eternus"
}
The rest is more or less up to you. Write the CheckCommand just one time in a good generic way, and always have readable parameter definitions. You can also hide these parameters into service templates if you want.
Cheers,
Michael
