On Mon, Nov 11, 2019 at 3:48 PM Rob Crittenden
<rcritten(a)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/plugi...
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