What is the "nonsense check" strategy?

[wsw70]

I am slowly going through an attempt to write a remote, ssh-based monitor and it leaves quite a lot of freedom in the configuration. This is because the kind of check (free space, process, ...) is not defined^* and therefore requires the user to provide their local call (ls -l), their interpretation of the result (.*\s(d+).....) and finally their assessment ("equal", "grater_than", ...).

This may lead to two nonsensical checks

• the ones that will catastrophically fail with a Traceback → this is good because one will not miss it
• the ones that will silently fail because of an error somewhere, but that makes sense in Python → this one is complicated

My general question is what is your @jamesoff strategy you want to enforce:

• the user must think before configuring and if they use the wrong check (that does not crash) then bad luck
• or the module must check precisely the outputs and do whatever is possible to limit the damage
• or something in between
• or something different

I am particularly interested in your opinion for the monitor I am writing because this is one where I have a hard time checking all edge cases (or cases in general, taking that there is a command + regex + interpretation left to the user). My uninformed position is that this is a monitoring software, so people using it will know what they want and not blow the world up.

---

^* the rationale for this approach is that (to take the example of a free space check) it

• either require to have python on the target (with the correct modules) and use a python-based check (shutil.disk_usage(), psutil.disk_usage(), ...)
• or check for the 17 zillion different possible outputs depending on the target

[jamesoff]

My gut feel agrees with your final point - it's up to the user to configure a semantically valid check, and SimpleMonitor can enforce that it's syntactically valid - so things like the regexp at least compiles and so on (although that might just be the limit of it!). The Monitor can report itself as failed based on anything else going wrong when the test runs, like the command failing when it actually gets invoked on the remote host etc.

As long as any useful info about the failure shows up in the logs or the failure message so it can be investigated that sounds good to me. Maybe include a note in the docs about recommending people validate their commands/regexp do/match the things they expect in both success and failure conditions just to highlight the point.

IMO this fits in the position of this being a monitoring tool for sysadmins or at least sysadmin-minded folk (not general end-users), and has "simple" in the name :)

[wsw70]

Cool, you will ultimately judge anyway :)