Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Decouple severity from Nagios plugin return codes #9

Merged
merged 1 commit into from Jan 14, 2016
Merged

Decouple severity from Nagios plugin return codes #9

merged 1 commit into from Jan 14, 2016

Commits on Jan 4, 2016

  1. Decouple severity from Nagios plugin return codes 

    This change is backwards-compatible.

Nagios plugins for non-trivial services will often poke multiple data
points looking for anomalous or undesirable behaviour.  Each data point
is often reflected with its own check Result in nagiosplugin.  If all
data points are within tolerance, we can rely on nagiosplugin to return
an OK result to its parent process.  Similarly, if one or more data
points are outside tolerance, we can rely on nagiosplugin to return a
non-OK (WARNING or CRITICAL) result to its parent process.  This pattern
greatly simplifies plugin development:  plugins may focus on the
monotonous task of data-gathering, leaving the ultimate 'result join' to
the nagiosplugin library.

Life get complicated when one or more data points are unable to be
queried (for whatever reason).  Prior to this change, any single UNKNOWN
Result would have superseded all other batched check Results:  including
other WARNING or CRITICAL Results.  Amongst organisations that do not
treat an individual UNKNOWN result as a pageable event, this behaviour
suppressed actual failures (see #8).

This commit introduces the notion of a 'status policy':  a mapping
between a conventional check status and its severity, relative to other
statuses.  Results are now ordered by severity instead of the fixed
numeric constants defined by Nagios.  Organisations may now prioritise
plugin return codes to match their established monitoring policy.  Unit
tests in check_test.go demonstrate use.

This decoupling is invisible by default.  The default status policy
mimics old behaviour.  To enable alternative severity prioritisation,
the caller must invoke the new NewCheckWithOptions() initialiser.
    Saj Goonatilleke committed Jan 4, 2016
    Configuration menu
    Copy the full SHA
    07fe3c5 View commit details
    Browse the repository at this point in the history