...A place where sharing IT monitoring knowledges

Showing posts with label Nagios plugins. Show all posts
Showing posts with label Nagios plugins. Show all posts

Thursday, 12 October 2017

Plugin Of The Month: Checking UPS alarms

NOTE: This post covers a Nagios/Icinga/Centreon Core compatible plugin addressed to monitor the active alarms. If you are interested in the background information that supports the plugin, see the post Monitoring UPS Devices: UPS-MIB.

Background

Monitoring the UPSs health is critical when trying to keep alive your ITC infrastructure. One of the most supported ways of monitoring UPSs, instead of using proprietary solutions, is SNMP via the MIB UPS (RFC 1628), widely supported by most of the devices in the market.

Specifically, MIB UPS (RFC 1628) supports an active alarms table in the managed device (OID upsAlarmTable, 1.3.6.1.2.1.33.1.6.2). Each table input stores:
  • upsAlarmId: An unique active alarm identifier
  • upsAlarmDescr: A reference to an alarm description object
  • upsAlarmTime: The value of sysUpTime when the alarm condition was detected
MIB includes a list of alarms objects called Well-Known-Alarms:

ID OID Description
1 upsAlarmBatteryBad (1.3.6.1.2.1.33.1.6.3.1) One or more batteries have been determined to require replacement.
2 upsAlarmOnBattery (1.3.6.1.2.1.33.1.6.3.2) The UPS is drawing power from the batteries.
3 upsAlarmLowBattery (1.3.6.1.2.1.33.1.6.3.3) The remaining battery run-time is less than or equal to upsConfigLowBattTime.
4 upsAlarmDepletedBattery (1.3.6.1.2.1.33.1.6.3.4) The UPS will be unable to sustain the present load when and if the utility power is lost.
5 upsAlarmTempBad (1.3.6.1.2.1.33.1.6.3.5) A temperature is out of tolerance.
6 upsAlarmInputBad (1.3.6.1.2.1.33.1.6.3.6) An input condition is out of tolerance.
7 upsAlarmOutputBad (1.3.6.1.2.1.33.1.6.3.7) An output condition (other than OutputOverload) is out of tolerance.
8 upsAlarmOutputOverload (1.3.6.1.2.1.33.1.6.3.8) The output load exceeds the UPS output capacity.
9 upsAlarmOnBypass (1.3.6.1.2.1.33.1.6.3.9) The Bypass is presently engaged on the UPS.
10 upsAlarmBypassBad (1.3.6.1.2.1.33.1.6.3.10) The Bypass is out of tolerance.
11 upsAlarmOutputOffAsRequested (1.3.6.1.2.1.33.1.6.3.11) The UPS has shutdown as requested, i.e., the output is off.
12 upsAlarmUpsOffAsRequested (1.3.6.1.2.1.33.1.6.3.12) The entire UPS has shutdown as commanded.
13 upsAlarmChargerFailed (1.3.6.1.2.1.33.1.6.3.13) An uncorrected problem has been detected within the UPS charger subsystem.
14 upsAlarmUpsOutputOff (1.3.6.1.2.1.33.1.6.3.14) The output of the UPS is in the off state.
15 upsAlarmUpsSystemOff (1.3.6.1.2.1.33.1.6.3.15) The UPS system is in the off state.
16 upsAlarmFanFailure (1.3.6.1.2.1.33.1.6.3.16) The failure of one or more fans in the UPS has been detected.
17 upsAlarmFuseFailure (1.3.6.1.2.1.33.1.6.3.17) The failure of one or more fuses has been detected.
18 upsAlarmGeneralFault (1.3.6.1.2.1.33.1.6.3.18) A general fault in the UPS has been detected.
19 upsAlarmDiagnosticTestFailed (1.3.6.1.2.1.33.1.6.3.19) The result of the last diagnostic test indicates a failure.
20 upsAlarmCommunicationsLost (1.3.6.1.2.1.33.1.6.3.20) A problem has been encountered in the communications between the agent and the UPS.
21 upsAlarmAwaitingPower (1.3.6.1.2.1.33.1.6.3.21) The UPS output is off and the UPS is awaiting the return of input power.
22 upsAlarmShutdownPending (1.3.6.1.2.1.33.1.6.3.22) A upsShutdownAfterDelay countdown is underway.
23 upsAlarmShutdownImminent (1.3.6.1.2.1.33.1.6.3.23) The UPS will turn off power to the load in less than 5 seconds; this may be either a timed shutdown or a low battery shutdown.
24 upsAlarmTestInProgress (1.3.6.1.2.1.33.1.6.3.24) A test is in progress, as initiated and indicated by the Test Group. Tests initiated via other implementation-specific mechanisms can indicate the presence of the testing in the alarm table, if desired, via a OBJECT-IDENTITY macro in the MIB document specific to that implementation and are outside the scope of this OBJECT-IDENTITY

Plugin description

check_ups_alarms is a Nagios/Icinga/Centreon Core compatible plugin for checking the active alarms in a UPS MIB compliant device.

The alarms to be checked (see table above) can be defined as a list of IDs in the warning and critical plugin arguments. If one of these alarms becomes active, the plugin will return the status associated to the list where the active alarm is defined.
check_ups_alarms  is based on fetching session data using SNMP v1/2c, so it's necessary that the device being checkek supported this protocol and served info managed by the UPS MIB (RFC 1628).

You can get detailed help and usage examples by running the script with the  --help option.

Usage examples

check_UPS_alarms -H 192.168.0.1
Checks the active alarms on a host with address 192.168.0.1 using SNMP protocol version 1 and 'public' as community. Plugin returns always OK.

check_UPS_alarms -H 192.168.0.1 -w 1..4,11 -c 5..10
Similar to the previous example but returning WARNING if alarm(s) with ids 1 to 4 and 11 are active and CRITICAL if alarms with ids 5 to 10 are active

Download

You can download the latest version of the plugin from GitHub.

The development of this plugin, that now is freely released, implies hours of reading technical documentation, programming and testing. I will be more than glad if you support this effort by clicking in some of the interesting advertisements that you can find on this website.

Last but not least, if you find some bug don't hesitate in contacting me for fixing it quickly. Feedback comments are welcome too!

Sunday, 24 September 2017

Plugin Of The Month: Check Cisco VPN active sessions

NOTE: This post covers a Nagios/Icinga/Centreon Core compatible plugin addressed to monitor the VPN sessions open in a Cisco device. If you are interested in the background information that supports the plugin, see the post Monitoring Cisco VPN sessions

Description

check_cisco_cras_sessions is a Nagios/Icinga/Centreon Core compatible plugin for checking the active sessions on a Cisco Remote Access Server (cras) device.

It can check overall or typed sessions supporting email, ipsec, LAN to LAN (l2l), load balancing (lb), SSL VPN Client (svc) and Web VPN sessions. It can also check sessions based on absolute (count) or relative, taking as base the  max sessions supportable by the device. Finally it can totalize (sum) sessions prior to compare against thresholds.

Based on the previous defined capabilities the plugin can be used in different ways:
  • For controlling if a device is reaching its limits by checking all sessions in relative mode, ie, comparing the overall sessions with the max sessions supportable and returning the result as a percent.
  • For controlling if a device is reaching its license limits by checking a given set of session types in a totalized mode (Cisco ASA licensing  restricts the number of SSL VPN Client + Web VPN sessions)
  • Finally for fine controlling sessions by type restricting the type of sessions checked to just one.
check_cisco_cras_sessions is based on fetching session data using SNMP v1/2c, so it's necessary that the device being checkek supported this protocol and served info managed by the ciscoRemoteAccessMonitorMIB MIB.

You can get detailed help and usage examples by running the script with the  --help option.

Usage examples

check_cisco_cras_sessions -H 192.168.0.12
Checks the number of sessions on a host with address 192.168.0.12 using SNMP protocol version 1 and 'public' as community. Plugin returns always OK.

check_cisco_cras_sessions -H 192.168.0.12 -w 30 -c 50
Similar to the previous example but returning WARNING if the number of sessions of any kind is higher than 30 and CRITICAL if it's higher than 50.

check_cisco_cras_sessions -H 192.168.0.12 -s email -s ipsec -w 30 -c 50
Similar to the previous example but just checking the Email and IPSec sessions.

check_cisco_cras_sessions -H 192.168.0.12 -s email -s ipsec -T -w 30 -c 50
Similar to the previous example but totalizing the sessions, ie, returning WARNING if the sum of email and ipsec sessions is higher than 30 and CRITICAL if it's higher than 50.

check_cisco_cras_sessions -H 192.168.0.12 -p -w 30 -c 50
Sessions of any kind are checked and their total is managed as percent over the device max supportable sessions. Thresholds and results are considered as percent.

Download

You can download the latest version of the plugin here.

The development of this plugin, that now is freely released, implies hours of reading technical documentation, programming and testing. I will be more than glad if you support this effort by clicking in some of the interesting advertisements that you can find on this website.

Last but not least, if you find some bug don't hesitate in contacting me for fixing it quickly. Feedback comments are welcome too!

Friday, 2 August 2013

check_esx3/check_vmware_api error "SOAP request error - possibly a protocol issue"


There's a problem in the Perl module Net::HTTP versions 6.05 and 6.06 (at least up to the date of writing this post) that drops this error when running check_esx/check_vmware_api, no matter which version of  VMWare API is being used.

The solution is based on downgrading Net::HTTP to its version 6.03. In order to check the installed module version (and thus determining that the problem matches the previously described), run this command from a shell session:

cpan -D Net::NTTP

... and in order to downgrade it, run this command:

cpan install GAAS/Net-HTTP-6.03.tar.gz

Once done, you could find that, though the error message has changed, you continue getting an error when running the check_esx3/check_vmware_api. That's due because Net::HTTP and libwww-perl Perl modules doesn't match after downgrading the first one, so you have to downgrade libwww-perl too in order to solve the problem. To do it run this command from a shell session:

cpan install GAAS/libwww-perl-6.03.tar.gz



Saturday, 27 July 2013

Monitoring Cisco VPN sessions


Cisco Remote Access Servers (or CRAS) are those devices whose mission is allowing users and devices to access to remote networks, mainly -but not limited to- by building Virtual Private Networks (VPN). Cisco ASA firewalls can be classified into this category.

Taking control over the amount of active VPN sessions on a CRAS device is important for various reasons:
  • Checking that the number of sessions doesn't reach the maximum defined by the device
  • Taking fine control on what kind of sessions (eMail, IPSec, LAN to LAN, load balancing, SSL VPN Client and Web VPN) are being stablished
  • Last but not least, and specifically in Cisco ASA devices with Premium licenses, checking that the number of active sessions doesn't reach the maximum defined by the license (that ranges from 10 to 10,000 active sessions)

How to get it

Cisco Remote Access Server devices (and thus Cisco ASA firewalls) publish the session information via SNMP protocol using the ciscoRemoteAccessMonitorMIB MIB, specifically via the crasActivity group OIDs:
  • crasEmailNumSessions (1.3.6.1.4.1.9.9.392.1.3.23) stores active email sessions.
  • crasIPSecNumSessions (1.3.6.1.4.1.9.9.392.1.3.26) stores active IPSec sessions.
  • crasL2LNumSessions (1.3.6.1.4.1.9.9.392.1.3.29) stores active LAN to LAN sessions.
  • crasLBNumSessions (1.3.6.1.4.1.9.9.392.1.3.32) stores active Load Balancing sessions.
  • crasSVCNumSessions (1.3.6.1.4.1.9.9.392.1.3.35) stores active SSL VPN Client sessions.
  • crasWEBVPNNumSessions (1.3.6.1.4.1.9.9.392.1.3.38) stores active Web VPN sessions.
Additionally,  crasMaxSessionsSupportable OID (1.3.6.1.4.1.9.9.392.1.1.1) from the crasCapacity group stores the maximum supportable active sessions.

Polling these OIDs is possible getting info about the active session in both absolute or relative to the maximum supportable by the device. In order to control the number of sessions restriction that the Cisco ASA Premium  licensing sets, it is necessary to sum the VPN client (OID crasSVCNumSessions) and Web VPN (OID crasWEBVPNNumSessions) active sessions and then comparing the result with the number of active VPN users that the ASA license imposes.

Nagios/Icinga/Centreon compatible plugin

You can download a Nagios/Icinga/Centreon Core compatible plugin addressed to monitor the Cisco VPN session via the post Plugin of the month: Check Cisco VPN active sessions.

The plugin can check a list of session types (-t argument) or all if no session types are defined. Also, it can run in absolute mode returning the number of active sessions, or relative mode (argument -p) returning the percent of active sessions when compared with the maximun supportable active sessions. Finally, the plugin can totalize (argument -T) the checked session types for returning a unique active sessions value.

Getting together these features, the plugin can be used:
  • For getting the overall active sessions (not stating any session type will check all sessions) in absolute or relative (using the -p argument) mode. In both cases the -T argument will make the plugin to return the total of sessions instead of returning a value per session type.
  • For getting active sessions per session type by specifying the session types to check (argument -t)
  • For checking the ASA firewall Premium license limits by setting the plugin to check SSL VPN Client and Web VPN active sessions (-t svc -t webvpn) and totalizing (-T) the result.
Here are some usage examples:

check_cisco_cras_sessions -H 192.168.0.12
Checks the number of sessions on a host with address 192.168.0.12 using SNMP protocol version 1 and 'public' as community. Plugin returns always OK.

check_cisco_cras_sessions -H 192.168.0.12 -w 30 -c 50
Similar to the previous example but returning WARNING if the number of sessions of any kind is higher than 30 and CRITICAL if it's higher than 50.

check_cisco_cras_sessions -H 192.168.0.12 -s email -s ipsec -w 30 -c 50
Similar to the previous example but just checking the Email and IPSec sessions.

check_cisco_cras_sessions -H 192.168.0.12 -s email -s ipsec -T -w 30 -c 50
Similar to the previous example but totalizing the sessions, ie, returning WARNING if the sum of email and ipsec sessions is higher than 30 and CRITICAL if it's higher than 50.

check_cisco_cras_sessions -H 192.168.0.12 -p -w 30 -c 50
Sessions of any kind are checked and their total is managed as percent over the device max supportable sessions. Thresholds and results are considered as percent.



Wednesday, 5 June 2013

check_esx3/check_vmware_api error 'Cannot complete login due to an incorrect user name or password' when upgrading to ESXi5


If you've upgraded your VMWare infrastructure to ESXi5 and you're getting the error 'Cannot complete login due to an incorrect user name or password' when running OP5's check_esx3 or check_vmware_api plugins, bet that you're using a Windows domain username without setting the domain itself.

Up to ESXi5 you could use a domain username in order to login to VCenter/ESX servers without the need of specifying the domain. Starting at ESXi5 you need to set the user domain in two of these ways:
  • user@domain
  • domain\user
So there's a chance that you, as I, were using the OP5 check_esx3.pl / check_vmware_api.pl Nagios plugin in order to get info from your virtualization infrastructure and that the plugin based checks stopped working after upgrading to ESXi5. In order to solve the problem apply the previous rule when setting the -u (--user) argument. 

Have in mind that, since the backslash (\) is a shell special character, you must quote the username value ('domain\user') or escape the backslash (domain\\user) in order to work when using the syntax domain\user.




Wednesday, 13 March 2013

OP5's check_esx3 timeouts when querying VSphere servers


I've been using the fantastic OP5's check_esx3 (now known as check_vmware_api) Nagios Core compatible plugin for years in different systems with success. In one of my last installs I got an strange problem: Plugin froze for minutes, even timed-out, when requesting info from any server (VCenter or ESX).

Debugging the code I saw that it happened when the VSphere API performed an HTTP POST to the  server SOAP webservice querying the properties of an object. Since prior to that operation VSphere API had successfully opened an SSL conection to the server I discarded a problem in the Perl LWP libraries, those that manage the SSL data flow from the monitoring system to the VSphere servers.

The monitoring system was using VSphere SDK for Perl 5.1 and Perl LWP 6.05 module, both the last available releases at the time of writing this post. 

After many tests I solved the problem downgrading Perl LWP from 6.05 to the 5.837 release. I'm not very sure why it happened and I've not tested it with different Perl LWP 6.x releases in order to find a more recent running version. The fact is that now it works like a charm.



 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes