sni / check_vmware_esx Goto Github PK

check_vmware_esx.pl
===================

chech_vmware_esx.pl - a fork of check_vmware_api.pl


General
=======

Why a fork? According to my personal unterstanding Nagios, Icingia etc. are tools for

a) Monitoring and alarming. That means checking values against thresholds (internal or handed over)
b) Collecting performance data. These data, collected with the checks, like network traffic, cpu usage or so should be
   interpretable without a lot of other data.

Athough check_vmware_api.pl is a great plugin it suffers from various things.
a) It acts as a monitoring plugin for Nagios etc.
b) It acts a more comfortable commandline interfacescript.
c) It collects all a lot of historical data to have all informations in one interface.

While a) is ok b) and c) needs to be discussed. b) was necessary when you had only the Windows GUI and working on Linux
meant "No interface". this is obsolete now with the new webgui.

c) will be better used by using the webgui because historical data (in most situations) means adjusted data. Most of these
collected data is not feasible for alerting but for analysing performance gaps.

So as a conclusion collecting historic performance data collected by a monitored system should not be done using Nagios,
pnp4nagios etc.. It should be interpreted with the approriate admin tools of the relevant system. For vmware it means use
the (web)client for this and not Nagios. Same for performance counters not self explaining.

Example:
Monitoring swapped memory of a vmware guest system seems to makes sense. But on the second look it doesn't because on Nagios
you do not have the surrounding conditions in one view like
- the number of the running guest systems on the vmware server.
- the swap every guest system needs
- the total space allocated for all systems
- swap/memory usage of the hostcheck_vmware_esx.pl
- and a lot more

So monitoring memory of a host makes sense but the same for the guest via vmtools makes only a limited sense.

But this were only a few problems. Furthermore we had

- misleading descriptions
- things monitored for hosts but not for vmware servers
- a lot of absolutely unnesseary performance data (who needs a performane graph for uptime?)
- unnessessary output (CPU usage in Mhz for example)
- and a lot more.

This plugin is old and big and cluttered like the room of my little son.  So it was time for some house cleaning.
I try to clean up the code of every routine, change things and will try to ease maintenance of the code.

The plugin is not really ready but working. Due to the mass
of options the help module needs work.

See history for changes

One last notice for technical issues. For better maintenance (and partly improved runtime)
I have decided to modularize the plugin. It makes patching a lot easier. Modules which must be there every time are
included with use, the others are include using require at runtime. This ensures that only
that part of code is loaded which is needed.


Installation
============

First install the VMware Perl SDK.
----------------------------------

- Download the SDK from vmware.
  - Go to www.vmware.com->Downloads->All downloads,drivers & tools
  - Search for "Perl SDK"
  - Download the appropriate Perl SDK for your release (the SDK is free but you have to register yourself for this).
  - Install it. (Installation guide can be found here: http://www.vmware.com/support/developer/viperltoolkit/)
  

Second install the plugin
-------------------------
  
- Download the archive (.zip from github or .tar.gz/.tgz from other locations) and unpack it in a location suitable for you.

It is recommended not to merge third party plugins with plugins deliverd by Nagios/Icingia/Shinken etc.. So it is a good practice
to have seperate directories for your own and/or third party plugins.

Ensure the the path to the perl interpreter in the program is set to the right perl executable on your system.

-> Adjust the path for the modules directory (use lib "modules") to fit your system (for example: use lib "/usr/local/libexec/myplugins/modules")
-> If using a session file adjust the path for the sessionfile ($plugin_cache in variable definition)


HTML in output caused by --multiline
====================================

The option --multiline sets a <br> tag instead of \n. This must be filtered out
before using the output in notifications like an email. sed will do the job:

sed 's/<[Bb][Rr]>/&\n/g' | sed 's/<[^<>]*>//g'

Example:
--------

# 'notify-by-email' command definition
define command{
	command_name	notify-by-email
	command_line	/usr/bin/printf "%b" "Message from Nagios:\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTNAME$\nHostalias: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $SHORTDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n$LONGSERVICEOUTPUT$" | sed 's/<[Bb][Rr]>/&\n/g' | sed 's/<[^<>]*>//g' | /bin/mail -s "** $NOTIFICATIONTYPE$ alert - $HOSTNAME$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
	}


Using a sessionfile
===================

With version 0.8.13 the authentication system was rewritten. From that version on using a seesionfile for authorization works as expected.

The sessionfilename is given over to the program using the commandline switch  --sessionfile=<filename>. To have a uniq
identifier the IP address of the adresses host/vcenter server is placed in front of the given name.

Example:
--------
192.168.10.12_duck

But a string like "duck" may not be a unique identifier. You can use any senseful Nagios macro for this in the command definition but beware
to use things like the service description in case the description contains blanks. In this case you will create a filename
with blanks in it. Quite stupid.

Optional a path different from the default one can be set with --sessionfilename=<directory>.


Storage
=======

The module host_storage_info.pm (contains host_storage_info()) is a extensive rewrite. Most of the code was rewritten.
It wasn't tested with iSCSI. Normally it should work but I couldn't test it because I have no iSCSI. Please test it an give me feedback.


Help
====

A lot of general options is listed more than once. Why? The help is very complex and large. By having all options for a a select/subselect listed
nearby we avoid scrolling up/down and minimize confusion which (general) option is valid.