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