Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
AKCP SensorProbe (check_akcp2.pl)
Current Version
1.1
Last Release Date
2018-06-30
Compatible With
- Nagios 3.x
- Nagios 4.x
Owner
Hits
6548
Files:
| File | Description |
|---|---|
| check_akcp2.pl | Version 1.0 |
| check_akcp2.pl | Version 1.1 |
An enhanced version of check_akcp which focuses specifically on temperature and humidity probes only. Leverages full capabilities of nagios to apply warning and critical thresholds to any type or combination of sensors, or leverages built-in thresholds defined on the AKCP. Also uses both temp/humid readings to calculate dewpoint and "dewpoint delta" values as well. Much of the temp/humid code was "borrowed" from my check_cdu.pl plugin.
NAME
check_akcp2 - Check temperature, humidity and dewpoint from an AKCP
device.
VERSION
This documentation refers to check_akcp2 version 1.0
APPLICATION REQUIREMENTS
Several standard Perl libraries are required for this program to function. Namely, Net::SNMP,
Getopt::Std, Getopt::Long, Nagios::Plugin::Threshold
GENERAL USAGE
check_akcp2.pl -H -C [--timeout SNMP timeout] [--port SNMP port]
REQUIRED ARGUMENTS
Only the hostname and community are required. Timeout will default to 2 seconds, port 161.
THRESHOLDS
I opted to use the Nagios::Plugin::Threshold class to handle thresholds. In general I do
not prefer Nagios::Plugins objects, but I just simply could not avoid using the Threshold
class. I apologize for the added dependency, I just could not afford re-inventing the wheel.
The benefit is that the threshold logic used in this plugin follows the standard used in
many other plugins. For reference, here are the general threshold guidelines:
Range definition Generate an alert if x...
10 < 0 or > 10, (outside the range of {0 .. 10})
10: < 10, (outside {10 .. ?})
~:10 > 10, (outside the range of {-? .. 10})
10:20 < 10 or > 20, (outside the range of {10 .. 20})
@10:20? 10 and ? 20, (inside the range of {10 .. 20})
10 < 0 or > 10, (outside the range of {0 .. 10})
Read: http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT
For the full, official, documentation
FULL DOCUMENTATION
check_akcp2 is intended to provide extremely flexible and extensive monitoring support for
AKCess Pro networked environmental monitoring solutions. In general the workflow for this application
follows this procedure:
1. Pull in an entire SNMP table using a Net::SNMP session and get_table().
2. Renumerate these "flat" values into a structured hash
3. Evaluate any options or thresholds passed on the command line by the user.
4. Process the command line options against the data collected from the AKCP
5. Exit appropriately given the status results
This workflow is generally followed in four slightly different ways depending on the desired options.
Environment
A popular sensor used on an AKCP device is either a temperature or temperature/humidity probe.
This plugin supports any number of these probes on just about any type of AKCP device.
Prior to running any checks for temperature or humidity, this plugin will check the T/H probe
status. The following states will result in an WARNING return:
offline(2)
This applies to both temperature and humidity. When a sensor is offline(2) there are several
additional status items that may be reported, including:
noStatus(1),
normal(2),
highWarning(3),
highCritical(4),
lowWarning(5),
lowCritical(6),
sensorError(7)
In its simplest form, the environment checks will query all available T/H probes connected to the
system. The AKCP has internal High/Low thresholds configured for both Temperature and Humidity, and
this is done on a per sensor basis. Without any arguments, this plugin will honor those values.
A basic invocation would resemble:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid
OK - N180D East MAT(0): 78.20F, N180D East MAT(0): 42%, N180B West MAT(1): 77.00F,
N180B West MAT(1): 44%, N180 Space(2): 67.60F, N180 Space(2): 70%
The various objects queried are returned in a comman separated list. For temperature and humidity
probes, the sensor Name is returned along with the ID in parantheses. If names haven't been set,
the defaults will still be displayed. Finally the value is listed for each sensor. The temperature
scale is automatically determined from the TempDegreeType object provided via SNMP. For instances
where the AKCP is configured for one scale, but the user desires the plugin to report in another
scale, the --fahrenheit and --celsius options are quite handy:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --celsius
OK - N180D East MAT(0): 25.50C, N180D East MAT(0): 40%, N180B West MAT(1): 24.78C, N180B West MAT(1): 43%
--fahrenheit works in a similar fashion. If a scale is passed to the plugin and the T/H probe is already
configured for that scale, no error will occur. The values will be reported in the native scale for
that sensor.
Expanding on this basic functionality is the --ths option. --ths allows the user to select
which sensors to query, based on the sensor ID (not the name!). --ths will automatically determine
if the sensors exist, and exit WARNING if they were not found. All of the regular sensor status
checks are still performed.
$ check_cdu.pl -H 192.168.0.1 -C public --temp --ths 0,1,2 --fahrenheit
OK - N180D East MAT(0): 77.70F, N180B West MAT(1): 76.60F, N180 Space(2): 67.10F
Note I also left out the --humid option. Either option can be specified alone, or both together,
providing maximum flexibility for designing purpose-built nagios service checks.
User supplied WARNING and CRITICAL thresholds can be applied to the temperature and humidity
sensors using the --warning and --critical directives. This overrides the automatic threshold
logic that relies upon the internal AKCP configuration. Either --warning or --critical can be used,
or both can be used together. When querying multiple temperature sensors, a single threshold is
applied across all sensors. The same is true for querying multiple humidity sensors. Both temperature
and humidity can be queried together in the same command, by "chaining" the thresholds together.
Here are a couple examples:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --fahrenheit --ths 0,1 --warning 60:80
OK - N180D East MAT(0): 77.70F, N180B West MAT(1): 76.60F
(Query just the temperature from T/H probes 0 and 1 and apply a warning threshold to alarm if
either sensor falls below 60F or above 80F)
$ check_akcp2.pl -H 192.168.0.1 -C public --humid --ths 0,1 --warning 10:70
OK - N180D East MAT(0): 42%, N180B West MAT(1): 43%
(Query just the humidity from T/H probes 0 and 1 and apply a warning threshold to alarm if
either sensor falls below 10% or above 70% relative humidity)
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --fahrenheit --ths 0 --warning 80,20: --critical 95,10:
OK - N180D East MAT(0): 77.70F, N180D East MAT(0): 42%
(Check just sensor 0, but query both temperature and humidity from this sensor. If the temperature
rises above 80F or the humidity falls below 20% generate a WARNING. If the temperature rises above
95 or the humidity falls below 10% generate a CRITICAL.)
IMPORTANT NOTE: When specifying both --temp and --humid the thresholds are chained together as
temperature_threshold,humidity_threshold regardless of which order --temp and --humid are passed!!
aka the following are equivalent:
'--temp --humid --warning 45,60' , '--humid --temp --warning 45,60'
The following are NOT equivalent:
'--temp --humid --warning 45,60', '--humid --temp --warning 60,45'
Starting in version 1.0 monitoring dewpoint temperature and dewpoint delta is supported. The
AKCP does not natively support dewpoint, but it can be calculated given temperature and humidity.
Dewpoint is calculated using constants from J Applied Meteorology and Climatology and the
dewpoint calculations provided at: http://en.wikipedia.org/wiki/Dew_point#Calculating_the_dew_point
There are two ways to monitor dewpoint. First is with the "--dewtemp" option. This simply
calculates the air temperature dewpoint of any given sensor and applies the user supplied
thresholds to the value. Using the "--dewdelta" directive calculates the differential temperature
between the air temperature and calculated air temperature dewpoint values. This is especially
useful for determining how close a sensor is to reaching the dewpoint temperature, and hence
when condesnsation might start forming within a data center. An example invocation would look like:
$ check_akcp2.pl -H 192.168.0.1 -C public --dewdelta --fahrenheit --ths 0,1 --warning 10: --critical 5:
OK - N180D East MAT(0) Delta: 65.34F, N180B West MAT(1) Delta: 64.90F
This check would initiate a WARNING if the dewpoint is 10F or less from the air temperature and a
CRITICAL if the dewpoint is 5F or less from the air temperature. I believe this would be a typical
use for this function. The dewpoint temperature can never be greater than air temperature, only
less than, or equal to.
Since the AKCP does not have built-in thresholds for dewpoint, it is required to use either
--warning or --critical in conjunction with either --dewtemp or --dewdelta. Like --temp and
--humid options chaining is supported with the dewpoint options. The order of the chained
thresholds is always temp,humidity,dewpoint. You cannot specify --dewdelta and --dewtemp in
the same invocation. An complex example invocation would be:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --dewdelta --fahrenheit --ths 0,1
--warning 80,50,10: --critical 90,80,5:
OK - N180D East MAT(0): 77.50F, N180D East MAT(0): 43%, N180D East MAT(0) Delta: 65.69F,
N180B West MAT(1): 76.40F, N180B West MAT(1): 42%, N180B West MAT(1) Delta: 65.50F
This command checks two sensors for temperature, humidity and dewpoint delta. Temperature
WARNING above 80, CRITICAL above 90. Humidity WARNING above 50, CRITICAL above 80. Dewpoint Delta
WARNING if less than 10 and CRITICAL if less than 5.
Other Sensors
Unfortunately there is currently no support for other sensors, such as water, airflow, 4-20ma, etc.
This script only supports temperature and humidity probes at this time. In the future support may
be added for more sensors as demand for these features increase. My suggestion is to simply use
check_snmp to monitor these types of metrics.
Plugin Termination
Numerous scenarios exist where the plugin will exit abnormally. This could be due to user input error,
or failure to retrieve required SNMP data, etc. In all identifiable cases, the plugin will exit with an
UNKNOWN state and a descriptive message indicating the failure. Users should be aware that if all SNMP
calls fail, monitoring of the AKCP may be effectively rendered useless if UNKNOWN states are not reported
(this is common). This is dissimilar to plugins like check_nrpe that exit CRITICAL if an SSL negotiation
erorr occurs!
Throughout the workflow of the plugin metrics are evaluated against thresholds and the results are placed
into various 'buckets' reflecting OK,WARNING,CRITICAL and UNKNOWN states. At the end of the workflow,
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --dewdelta --fahrenheit --ths 0,1
--warning 80,50,10: --critical 90,80,5:
OK - N180D East MAT(0): 77.50F, N180D East MAT(0): 43%, N180D East MAT(0) Delta: 65.69F,
N180B West MAT(1): 76.40F, N180B West MAT(1): 42%, N180B West MAT(1) Delta: 65.50F
This command checks two sensors for temperature, humidity and dewpoint delta. Temperature
WARNING above 80, CRITICAL above 90. Humidity WARNING above 50, CRITICAL above 80. Dewpoint Delta
WARNING if less than 10 and CRITICAL if less than 5.
Other Sensors
Unfortunately there is currently no support for other sensors, such as water, airflow, 4-20ma, etc.
This script only supports temperature and humidity probes at this time. In the future support may
be added for more sensors as demand for these features increase. My suggestion is to simply use
check_snmp to monitor these types of metrics.
Plugin Termination
Numerous scenarios exist where the plugin will exit abnormally. This could be due to user input error,
or failure to retrieve required SNMP data, etc. In all identifiable cases, the plugin will exit with an
UNKNOWN state and a descriptive message indicating the failure. Users should be aware that if all SNMP
calls fail, monitoring of the AKCP may be effectively rendered useless if UNKNOWN states are not reported
(this is common). This is dissimilar to plugins like check_nrpe that exit CRITICAL if an SSL negotiation
erorr occurs!
Throughout the workflow of the plugin metrics are evaluated against thresholds and the results are placed
into various 'buckets' reflecting OK,WARNING,CRITICAL and UNKNOWN states. At the end of the workflow,
reporting is done based upon the presence or absence of these buckets. If both CRITICAL and WARNING
conditions exist, they are BOTH reported in the plugin_output text, however the state is reported as
CRITICAL. An example of this can be seen in the following output:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --warning :77 --critical :78 --ths 0,1,2
CRITICAL - N180D East MAT(0): 78.80F, , WARNING - N180B West MAT(1): 77.70F
Some options end up producing a large amount of output, and this could easily exceed what Nagios can
accept, or also exceed character limits on various notification devices (maybe you're tweeting your
CDU status for instance ;P) The '--oksummary' option exists to summarize the output for any type of
check being done. If all metrics being checked are in state 'OK' the output supresses the specifics
of these metrics and simply reports 'N metrics are OK' The version and location are also displayed
in the plugin_output.
INCOMPATIBILITIES
None. See Bugs.
BUGS AND LIMITATIONS
None.
If you experience any problems please contact me. (eric.schoeller coloradoDOTedu)
AUTHOR
Eric Schoeller (eric.schoeller coloradoDOTedu)
LICENCE AND COPYRIGHT
Copyright (c) 2015 Eric Schoeller (eric.schoeller coloradoDOTedu).
All rights reserved.
This module is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License.
See L.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
check_akcp2 - Check temperature, humidity and dewpoint from an AKCP
device.
VERSION
This documentation refers to check_akcp2 version 1.0
APPLICATION REQUIREMENTS
Several standard Perl libraries are required for this program to function. Namely, Net::SNMP,
Getopt::Std, Getopt::Long, Nagios::Plugin::Threshold
GENERAL USAGE
check_akcp2.pl -H
REQUIRED ARGUMENTS
Only the hostname and community are required. Timeout will default to 2 seconds, port 161.
THRESHOLDS
I opted to use the Nagios::Plugin::Threshold class to handle thresholds. In general I do
not prefer Nagios::Plugins objects, but I just simply could not avoid using the Threshold
class. I apologize for the added dependency, I just could not afford re-inventing the wheel.
The benefit is that the threshold logic used in this plugin follows the standard used in
many other plugins. For reference, here are the general threshold guidelines:
Range definition Generate an alert if x...
10 < 0 or > 10, (outside the range of {0 .. 10})
10: < 10, (outside {10 .. ?})
~:10 > 10, (outside the range of {-? .. 10})
10:20 < 10 or > 20, (outside the range of {10 .. 20})
@10:20? 10 and ? 20, (inside the range of {10 .. 20})
10 < 0 or > 10, (outside the range of {0 .. 10})
Read: http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT
For the full, official, documentation
FULL DOCUMENTATION
check_akcp2 is intended to provide extremely flexible and extensive monitoring support for
AKCess Pro networked environmental monitoring solutions. In general the workflow for this application
follows this procedure:
1. Pull in an entire SNMP table using a Net::SNMP session and get_table().
2. Renumerate these "flat" values into a structured hash
3. Evaluate any options or thresholds passed on the command line by the user.
4. Process the command line options against the data collected from the AKCP
5. Exit appropriately given the status results
This workflow is generally followed in four slightly different ways depending on the desired options.
Environment
A popular sensor used on an AKCP device is either a temperature or temperature/humidity probe.
This plugin supports any number of these probes on just about any type of AKCP device.
Prior to running any checks for temperature or humidity, this plugin will check the T/H probe
status. The following states will result in an WARNING return:
offline(2)
This applies to both temperature and humidity. When a sensor is offline(2) there are several
additional status items that may be reported, including:
noStatus(1),
normal(2),
highWarning(3),
highCritical(4),
lowWarning(5),
lowCritical(6),
sensorError(7)
In its simplest form, the environment checks will query all available T/H probes connected to the
system. The AKCP has internal High/Low thresholds configured for both Temperature and Humidity, and
this is done on a per sensor basis. Without any arguments, this plugin will honor those values.
A basic invocation would resemble:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid
OK - N180D East MAT(0): 78.20F, N180D East MAT(0): 42%, N180B West MAT(1): 77.00F,
N180B West MAT(1): 44%, N180 Space(2): 67.60F, N180 Space(2): 70%
The various objects queried are returned in a comman separated list. For temperature and humidity
probes, the sensor Name is returned along with the ID in parantheses. If names haven't been set,
the defaults will still be displayed. Finally the value is listed for each sensor. The temperature
scale is automatically determined from the TempDegreeType object provided via SNMP. For instances
where the AKCP is configured for one scale, but the user desires the plugin to report in another
scale, the --fahrenheit and --celsius options are quite handy:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --celsius
OK - N180D East MAT(0): 25.50C, N180D East MAT(0): 40%, N180B West MAT(1): 24.78C, N180B West MAT(1): 43%
--fahrenheit works in a similar fashion. If a scale is passed to the plugin and the T/H probe is already
configured for that scale, no error will occur. The values will be reported in the native scale for
that sensor.
Expanding on this basic functionality is the --ths option. --ths allows the user to select
which sensors to query, based on the sensor ID (not the name!). --ths will automatically determine
if the sensors exist, and exit WARNING if they were not found. All of the regular sensor status
checks are still performed.
$ check_cdu.pl -H 192.168.0.1 -C public --temp --ths 0,1,2 --fahrenheit
OK - N180D East MAT(0): 77.70F, N180B West MAT(1): 76.60F, N180 Space(2): 67.10F
Note I also left out the --humid option. Either option can be specified alone, or both together,
providing maximum flexibility for designing purpose-built nagios service checks.
User supplied WARNING and CRITICAL thresholds can be applied to the temperature and humidity
sensors using the --warning and --critical directives. This overrides the automatic threshold
logic that relies upon the internal AKCP configuration. Either --warning or --critical can be used,
or both can be used together. When querying multiple temperature sensors, a single threshold is
applied across all sensors. The same is true for querying multiple humidity sensors. Both temperature
and humidity can be queried together in the same command, by "chaining" the thresholds together.
Here are a couple examples:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --fahrenheit --ths 0,1 --warning 60:80
OK - N180D East MAT(0): 77.70F, N180B West MAT(1): 76.60F
(Query just the temperature from T/H probes 0 and 1 and apply a warning threshold to alarm if
either sensor falls below 60F or above 80F)
$ check_akcp2.pl -H 192.168.0.1 -C public --humid --ths 0,1 --warning 10:70
OK - N180D East MAT(0): 42%, N180B West MAT(1): 43%
(Query just the humidity from T/H probes 0 and 1 and apply a warning threshold to alarm if
either sensor falls below 10% or above 70% relative humidity)
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --fahrenheit --ths 0 --warning 80,20: --critical 95,10:
OK - N180D East MAT(0): 77.70F, N180D East MAT(0): 42%
(Check just sensor 0, but query both temperature and humidity from this sensor. If the temperature
rises above 80F or the humidity falls below 20% generate a WARNING. If the temperature rises above
95 or the humidity falls below 10% generate a CRITICAL.)
IMPORTANT NOTE: When specifying both --temp and --humid the thresholds are chained together as
temperature_threshold,humidity_threshold regardless of which order --temp and --humid are passed!!
aka the following are equivalent:
'--temp --humid --warning 45,60' , '--humid --temp --warning 45,60'
The following are NOT equivalent:
'--temp --humid --warning 45,60', '--humid --temp --warning 60,45'
Starting in version 1.0 monitoring dewpoint temperature and dewpoint delta is supported. The
AKCP does not natively support dewpoint, but it can be calculated given temperature and humidity.
Dewpoint is calculated using constants from J Applied Meteorology and Climatology and the
dewpoint calculations provided at: http://en.wikipedia.org/wiki/Dew_point#Calculating_the_dew_point
There are two ways to monitor dewpoint. First is with the "--dewtemp" option. This simply
calculates the air temperature dewpoint of any given sensor and applies the user supplied
thresholds to the value. Using the "--dewdelta" directive calculates the differential temperature
between the air temperature and calculated air temperature dewpoint values. This is especially
useful for determining how close a sensor is to reaching the dewpoint temperature, and hence
when condesnsation might start forming within a data center. An example invocation would look like:
$ check_akcp2.pl -H 192.168.0.1 -C public --dewdelta --fahrenheit --ths 0,1 --warning 10: --critical 5:
OK - N180D East MAT(0) Delta: 65.34F, N180B West MAT(1) Delta: 64.90F
This check would initiate a WARNING if the dewpoint is 10F or less from the air temperature and a
CRITICAL if the dewpoint is 5F or less from the air temperature. I believe this would be a typical
use for this function. The dewpoint temperature can never be greater than air temperature, only
less than, or equal to.
Since the AKCP does not have built-in thresholds for dewpoint, it is required to use either
--warning or --critical in conjunction with either --dewtemp or --dewdelta. Like --temp and
--humid options chaining is supported with the dewpoint options. The order of the chained
thresholds is always temp,humidity,dewpoint. You cannot specify --dewdelta and --dewtemp in
the same invocation. An complex example invocation would be:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --dewdelta --fahrenheit --ths 0,1
--warning 80,50,10: --critical 90,80,5:
OK - N180D East MAT(0): 77.50F, N180D East MAT(0): 43%, N180D East MAT(0) Delta: 65.69F,
N180B West MAT(1): 76.40F, N180B West MAT(1): 42%, N180B West MAT(1) Delta: 65.50F
This command checks two sensors for temperature, humidity and dewpoint delta. Temperature
WARNING above 80, CRITICAL above 90. Humidity WARNING above 50, CRITICAL above 80. Dewpoint Delta
WARNING if less than 10 and CRITICAL if less than 5.
Other Sensors
Unfortunately there is currently no support for other sensors, such as water, airflow, 4-20ma, etc.
This script only supports temperature and humidity probes at this time. In the future support may
be added for more sensors as demand for these features increase. My suggestion is to simply use
check_snmp to monitor these types of metrics.
Plugin Termination
Numerous scenarios exist where the plugin will exit abnormally. This could be due to user input error,
or failure to retrieve required SNMP data, etc. In all identifiable cases, the plugin will exit with an
UNKNOWN state and a descriptive message indicating the failure. Users should be aware that if all SNMP
calls fail, monitoring of the AKCP may be effectively rendered useless if UNKNOWN states are not reported
(this is common). This is dissimilar to plugins like check_nrpe that exit CRITICAL if an SSL negotiation
erorr occurs!
Throughout the workflow of the plugin metrics are evaluated against thresholds and the results are placed
into various 'buckets' reflecting OK,WARNING,CRITICAL and UNKNOWN states. At the end of the workflow,
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --humid --dewdelta --fahrenheit --ths 0,1
--warning 80,50,10: --critical 90,80,5:
OK - N180D East MAT(0): 77.50F, N180D East MAT(0): 43%, N180D East MAT(0) Delta: 65.69F,
N180B West MAT(1): 76.40F, N180B West MAT(1): 42%, N180B West MAT(1) Delta: 65.50F
This command checks two sensors for temperature, humidity and dewpoint delta. Temperature
WARNING above 80, CRITICAL above 90. Humidity WARNING above 50, CRITICAL above 80. Dewpoint Delta
WARNING if less than 10 and CRITICAL if less than 5.
Other Sensors
Unfortunately there is currently no support for other sensors, such as water, airflow, 4-20ma, etc.
This script only supports temperature and humidity probes at this time. In the future support may
be added for more sensors as demand for these features increase. My suggestion is to simply use
check_snmp to monitor these types of metrics.
Plugin Termination
Numerous scenarios exist where the plugin will exit abnormally. This could be due to user input error,
or failure to retrieve required SNMP data, etc. In all identifiable cases, the plugin will exit with an
UNKNOWN state and a descriptive message indicating the failure. Users should be aware that if all SNMP
calls fail, monitoring of the AKCP may be effectively rendered useless if UNKNOWN states are not reported
(this is common). This is dissimilar to plugins like check_nrpe that exit CRITICAL if an SSL negotiation
erorr occurs!
Throughout the workflow of the plugin metrics are evaluated against thresholds and the results are placed
into various 'buckets' reflecting OK,WARNING,CRITICAL and UNKNOWN states. At the end of the workflow,
reporting is done based upon the presence or absence of these buckets. If both CRITICAL and WARNING
conditions exist, they are BOTH reported in the plugin_output text, however the state is reported as
CRITICAL. An example of this can be seen in the following output:
$ check_akcp2.pl -H 192.168.0.1 -C public --temp --warning :77 --critical :78 --ths 0,1,2
CRITICAL - N180D East MAT(0): 78.80F, , WARNING - N180B West MAT(1): 77.70F
Some options end up producing a large amount of output, and this could easily exceed what Nagios can
accept, or also exceed character limits on various notification devices (maybe you're tweeting your
CDU status for instance ;P) The '--oksummary' option exists to summarize the output for any type of
check being done. If all metrics being checked are in state 'OK' the output supresses the specifics
of these metrics and simply reports 'N metrics are OK' The version and location are also displayed
in the plugin_output.
INCOMPATIBILITIES
None. See Bugs.
BUGS AND LIMITATIONS
None.
If you experience any problems please contact me. (eric.schoeller
AUTHOR
Eric Schoeller (eric.schoeller
LICENCE AND COPYRIGHT
Copyright (c) 2015 Eric Schoeller (eric.schoeller
All rights reserved.
This module is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License.
See L
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Reviews (0)
Be the first to review this listing!
