I implemented a few businessprocess-checks as services.
In our test environment I have enabled several modules that do not exist, the service check in icingaweb2 executes icingacli businessprocess and so it checks the modules first.
The output of this is also displayed in icingaweb2 as service_output which bothers the normal service_output.
The invalid module may be disabled or removed completely, yes, but the service_state does not change when the service_output displays that error message so it is not visible at first that this services somwhat fail.
I think it were an improvement if there were some parameters that you can choose if you do not want to display this error message in general like “–no-module-check” or sth .
To Reproduce just create a symlink to a non-existing target: /bin/ln -s /tmp/invalid_module /etc/icingaweb2/enabledModules/invalid_module
Icinga Web 2 version: 2.9.5
Used modules and their versions (System - About): businessprocess 2.3.0
and you think this flag will be used how? I doubt that it will be used without anyone encountering this first like you. It also won’t be active by default, otherwise no-one will enable it anymore.
And, yes, disabling or removing the module in question is probably the easiest solution. Changing the configuration of the check to include this flag is the more costly endeavor I suppose.
So, I think you should just disable modules before removing them. This is really only an issue in a workflow of yours. If you correct that, this won’t happen that easily.
If flag is set, than do not do that module validation-check. For one single command like '/usr/bin/icingacli' 'businessprocess' 'process' 'check' it is not necessary to check if all modules are installed correctly.
My thought was that if you recommend this CLI-command to be used as a service check command than it were safer that those outputs were suppressed if necessary, because no one who wants to monitor his business processes is interested in a different validation of modules.
This “automated CLI-execution” over icingaweb2 is only intended to check what I specify over the parameters, nothing more.
Sure, it’s fine to question the need to run this check for every single command. And I do recommend this check, but I also don’t recommend to leave modules enabled that got removed.
But still, doesn’t this just clutter the output? You’ve wrote in the OP that the service state does not change. This cannot be true, the state in inferred by the exit code of the plugin, not the output. Since these are just warnings, the exit code shouldn’t change.
So that this “automated CLI-execution” over icingaweb2 can provide you what you’re asking for, it has to load the modules. The check is just a consequence of that. The only thing I could see here is a way to suppress warning messages completely.
True, inexistent modules / symlinks shall be removed, I aggree. As I admitted, it was in our test environment because we do some developments there. Someone forgot to disable that module, so I found this “false-positive” and I thought that you were interested in that.
The warning “inexitent module blabla” is only visible in the service_output, the service_state does not change. If we had not seen that service in the icingaweb2 we would have noticed that there was an inexistent module. A change of the service_state like WARNING or UNKNOWN would have shown that earlier. I thought you were interested in this because it is somehow important to the users that there is an error in “their” service and it is not soooo much recognizable when you do not have a dashboard for somehow weird service_outputs (because service_state does not change when there is an inexisting module).
Or a “do you want to see module-warnings, yes or no”-parameter when executing that command, so everyone can choose it for themselves
I see. But maybe now you’ll see why I’m not convinced of your suggestion. The output has nothing to do with the service state and the warning about inexistent modules also isn’t something that should influence the state at all.
So, the state doesn’t change and the output has still all the important details. Just not in the first line as usual. Yes, it clutters the output, which isn’t ideal, that’s why I think it’s more beneficial to silence all warnings. They’re only warnings after all. Warnings about the program execution, not the check.
UNKNOWN is only reported by plugins if the actual state couldn’t be determined, which isn’t the case here.
.