Alex Corcoles wrote:
On Mon, Nov 11, 2019 at 3:48 PM Rob Crittenden <rcritten@redhat.com mailto:rcritten@redhat.com> wrote:
Jones, Bob (rwj5d) via FreeIPA-users wrote: > If you’re making these sorts of changes, might I suggest a flag to generate Nagios safe output that is just a summary of how many warnings/errors were found like the way checkipaconsistency does it? Otherwise we will have to come up with a wrapper to parse the output and create the correct output format. I don't know what you mean by "nagios-safe output". Are you suggesting a sort of --summary option that just reports the number and types of output?
I think the idea is to follow the Nagios plugin API:
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/pluginap...
Strictly speaking, the output of a Nagios plugin is not so important- unless you manage to output "valid" perfdata, Nagios will chug along (maybe it will not show pretty service status) and things will just work IFF the return code from the process follows the Nagios standards (0: OK, 1: WARNING, 2: CRITICAL, 3 or other: UNKNOWN).
IMHO, if the tool provides structured output like it currently does (JSON), writing a Nagios wrapper should be "easy" and it wouldn't be significantly worse than implementing "Nagios"-mode within ipa-healthcheck.
OTOH, Nagios is probably one of the most popular monitoring solutions right now, IIRC, it's the only monitoring solution that RedHat packages in RHEL and a lot of other monitoring solutions can use Nagios plugins, so it would be very nice if yum install freeipa-server automatically installed a Nagios check.
I looked at this prior to writing healthcheck and managed to write a generic Nagios handled that slurped in the healthcheck JSON output and generated items for each one. It was just a POC to see if I was heading in the right direction but it seemed to work.
I didn't expect that ipa-healthcheck return value would be all that useful other than "the tool itself blew up"
rob