Мониторинг лог файлов в Windows

не плохая статья

http://nagios.fm4dd.com/howto/monitor-custom-windows-logfiles.htm

Introduction


Monitoring custom application log files with Nagios is quite a complex task, it deserves a tutorial of its own. I believe there is no turnkey solution and to solve it we need to break the requirement up into functional parts to combine existing software.

In this particular example, I will look at building the Windows log monitoring from the following 3 software components:

  • check_logfiles from ConSol Labs for actually parsing the log
  • NSClient++ written by Michael Medin for kicking off the log parser
  • check_nrpe written by Ethan Galstad for making the remote call from Nagios

Design


Monitoring custom Windows logfiles design

Part 1: Custom log parsing under Windows based on Error and Warn criteria, generating Nagios compatible output


The check_logfiles plugin is needed to parse the log based on freely defined patterns and return a Nagios readable status. It is available as an executable for Windows and integrates with NSclient++. Simply place it in a good home on your Windows server. Either in a directory by itself, or another good place is to place it later into the scripts directory of the NSClient++ home. Next, we create a log parsing configuration file, here I named it check_logfiles.cfg. We set our example log file to be in D:\data\logs\log1.log, and we define example warning and critical strings to search for.

$MACROS = { LOGDIR => 'D:\data' };
@searches = ({
  tag => 'apperror',
  logfile => '$LOGDIR$\logs\log1.log',
  criticalpatterns => [
      'ERROR timestamp appfailure 1',
      'ERROR timestamp appfailure 2' ],
  warningpatterns => [
      'WARN timestamp appwarning 1', 
      'WARN timestamp appwarning 2' ]
});

Next, we run the check_logfiles.exe on the Windows system over our example logfile to test the configuration we just created. In the example below, I inserted a test string into the log file to see if the critical pattern filter matches.

C:\logmonitor> check_logfiles.exe -f check_logfiles.cfg
CRITICAL - (1 errors in check_logfiles.protocol-2011-06-17-15-02-37) - ERROR timestamp appfailure 1 caused by xxx 
|apperror_lines=2 apperror_warnings=0 apperror_criticals=1 apperror_unknowns=0

Part 2: Initiating the log check and transporting the result back to Nagios


Next comes the NSClient++, which is a free monitoring agent written for Windows (32 and 64bit). It collects various standard performance data, and in addition it can call external scripts for custom monitoring such as our check_logfiles.exe plugin. During the installation of NSClient++ we should enable the NRPE server module to listen for check_nrpe service requests. While it is possible to also call NSClient++ with the Nagios-builtin plugin ‘check_nt’, the additional plugin ‘check_nrpe’ is needed to use NSClient++ with external scripts.

After installing the NSClient++ software on the Windows system and the NRPE check plugin on the Nagios server, we test the monitoring connection from Nagios and verify network connectivity works:

susie112:/srv/app/nagios/libexec # ./check_nrpe -H 192.168.103.184
I (0.3.8.75 2010-05-27) seem to be doing fine...

Now we can build the connection between the NSClient++ agent and the check_logfiles.exe plugin on the Windows system. We need to edit the NSClient++ configuration file NSC.ini, enable the line CheckExternalScripts.dll under the [modules] section and add a line describing how we need to call our script in the [External Scripts] section:

check_logfiles=C:\logmonitor\check_logfiles.exe -f C:\logmonitor\check_logfiles.cfg

After that we are ready to try and call the log parsing from our Nagios server with the check_nrpe plugin.

susie112:/srv/app/nagios/libexec # ./check_nrpe -H 192.168.103.184 -c check_logfiles
OK - no errors or warnings|apperror_lines=0 apperror_warnings=0 apperror_criticals=0 apperror_unknowns=0

If this works, the only remaining task is to add the usual Nagios service configuration definitions and test it end-to-end.

Nagios Service Configuration


susie112:~ # vi /srv/app/nagios/etc/objects/command.cfg
# 'define check_nrpe'
define command{
  command_name check_nrpe
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 60
}

nagios@susie112:~> vi /srv/app/nagios/etc/objects/win-logfile-services.cfg
###############################################################################
# Define a servicegroup for Windows log file checks
###############################################################################
define servicegroup{
  servicegroup_name        win-logfile-checks  ; The name of the servicegroup
  alias                    Windows Log Checks  ; Long name of the group
}
###############################################################################
# Define the generic patch check service template
###############################################################################
define service{
  name                          generic-win-logfile
  active_checks_enabled         1
  passive_checks_enabled        0
  parallelize_check             1
  obsess_over_service           1
  check_freshness               0
  notifications_enabled         1
  event_handler_enabled         1
  process_perf_data             0
  retain_status_information     1
  retain_nonstatus_information  1
  is_volatile                   1
  check_period                  24x7
  max_check_attempts            1
  normal_check_interval         5               ; check every 5 minutes
  retry_check_interval          1
  contact_groups                win-admins, security-team
  notification_options          u,w,r           ; notify unknown, warn, recovery
  notification_interval         1               ; ignored for volatile services
  notification_period           24x7
  register                      0
  servicegroups                 win-logfile-checks
}
###############################################################################
# Windows logfile checks
###############################################################################
define service {
  use                           generic-win-logfile
  host_name                     winserver1
  service_description           check_logfiles
  check_command                 check_nrpe!check_logfiles
}

The check_logfiles plugin resports only new alerts for each run. In order to alert for each occurence we need to set the Nagios parameter is_volatile.

Example Screenshots


Windows Log monitoring service state detail

Windows Log monitoring service line example ok
Windows Log monitoring service line example error

Monitoring standard performance data through NSClient++ and NRPE


I mentioned that the Windows monitoring agent NSClient++ can be used to retrieve standard performance data. For completeness, here is a quick example to show how we can get the systems CPU load, making the following call from Nagios:

susie112:/srv/app/nagios/libexec # ./check_nrpe -H 192.168.103.184 -c CheckCPU -a warn=80 crit=90 time=20m time=10s time=4
OK CPU Load ok.|'20m'=0%;80;90; '10s'=12%;80;90; '4'=0%;80;90;

If there is no data returned, please check the NSCLient++ log file and make sure to set the parameter ‘allowed_arguments=1’ in the [NRPE] section of NSC.ini.

Considering alternative solutions


Instead of implementing active monitoring, we could also opt for setting up passive monitoring by scheduling the check_logfiles plugin within Windows and returning the parse result through SNMP traps using the TrapGen program similar to our setup in the Windows Patch Update Monitoring Howto. This would save us the need to install a extra monitoring daemon on Windows. Installing additional network daemons is often a security and support concern.

There is a multitude of software out that make other combinations possible as well. For example, I found that CornerBowls Log Manager software looks promising and it is not expensive. It can do the log parsing and has the SNMP trap send function already integrated. In the end it depends on your preference, network and server envrionment which plugin and method is the best to choose.

Hope this helps in getting started!

Credits, Links and additonal information


  • Nagios and the Nagios community can be found at http://www.nagios.org/
  • Further Nagios documentation is available here http://nagios.fm4dd.com/docs/en/
  • The check_logfiles plugin from ConSol Labs can be found here
  • The NSClient++ Windows monitoring agent can be found here
  • NRPE, the remote plugin execution check for Nagios can be found here



Alarm call from Nagios(звонки с оповещениями из Нагиос)

Вау, тут в общем посидели, покумекали и слепили такую штуку(пока в тестовом режиме) — звонки с оповещениями из Nagios.

в общем, как это настраивается

в исходных данных — Nagios 3.4 на Ubuntu 12

что делаем

  1. качаем пакет wget http://www.pjsip.org/release/2.0./pjproject-2.0.1.tar.bz2 , можно и более новый — если ОС новее (wget http://www.pjsip.org/release/2.6/pjproject-2.6.tar.bz2)
  2. распаковываем
  3. заходим в папку, там
  4.  ./configure
    make dep
    make

заводим аккаунт на Asterisk под это дело

пишем в хостах(если нет DNS имя астериска) 10.10.1.2 — asterisk

дальше сама команда вызова звонка

./pjsua-x86_64-unknown-linux-gnu —duration=20 —auto-answer 200 —auto-play —id sip:ALARM_NUBMER@asterisk —contact sip:ALARM_NUBMER@172.19.7.17 —registrar sip:asterisk —realm asterisk  —username $ALARM_NUBMER$ —password $PASSWORD$ —local-port 5060 —null-audio —play-file long_remedy.wav sip:CALL_TO@asterisk

дальше, нужно что бы

define command{
command_name notify-host-call
command_line echo $HOSTNAME$ $HOSTSTATE$ $NOTIFICATIONTYPE$ «Host» > /tmp/text4wave.txt | text2wave -o /tmp/alert.wav /tmp/text4wave.txt -f 8000 | (sleep 5 && echo q) | /opt/sip/pjsua-x86_64-unknown-linux-gnu
—config-file=/opt/sip/pjsuarc —auto-play —play-file /tmp/alert.wav sip:$CONTACTPAGER$@asterisk
}

 

 

 




MSSQL в Nagios

Появилась задача — мониторинг состояние MSSQL сервера средствами Nagios.

был выбран плагин check_mssql_health (https://labs.consol.de/nagios/check_mssql_health/)

для работы были уставлен модуль Perl

cpan
install DBD::Sybase

на сервера БД был добавлен пользователь nagiosadmin , с паролем nagiosadmin и правами serveradmin

 

В command.cfg добавляем команду проверки:

# ' check_mssql_health' command definition
define command{
command_name check_mssql_health
command_line $USER1$/check_mssql_health --server=$HOSTADDRESS$ --username=nagiosadmin --password=nagiosadmin --mode=$ARG1$ --commit --units=$ARG2$ --warning=$ARG3$ --critical=$ARG4$
}

В проверку хоста добавляем

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL transactions
        check_command           check_mssql_health!transactions!B!40000!50000
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL connected-users
        check_command           check_mssql_health!connected-users!B!150!200
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL cpu-busy
        check_command           check_mssql_health!cpu-busy!B!80!90
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL io-busy
        check_command           check_mssql_health!io-busy!B!80!90
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL full-scans
        check_command           check_mssql_health!full-scans!B!800!900
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL locks-waits
        check_command           check_mssql_health!locks-waits!B!80!90
        }

define service{
        use                     generic-service
        host_name               srv-1c-db01
        service_description     MSSQL total-server-memory
        check_command           check_mssql_health!total-server-memory!GB!80!90
        }

В итоге получаем :




Send Nagios Alert Notification Using WhatsApp

One of the most important feature of the monitoring platform is the notification system; by default  they use the local mail daemon (postfix, mail, exim) installed on the server to send the notifications.

Using local mail daemon has many issues :

  • You need to install and configure your smtp server.
  • Maybe your mail server go down so you can’t receive the alert.
  • Maybe this kind of emails from a not verified source like nagios can be filtered by the same company antispam system.

In order to avoid all issues, In this article I am going to explain how to send alert from monitoring tool Nagios Core using WhatsApp.

This task was not so easy since communicating with WhatsApp through a linux server was requiring to install Yowsup library.

If you still didn’t install Nagios Core , check the following articles.

Introduction to WhatApp

WhatsApp Messenger is a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS.

 

 

WhatsApp Messenger is available for iPhone, BlackBerry, Android, Windows Phone and Nokia and yes, those phones can all message each other! Because WhatsApp Messenger uses the same internet data plan that you use for email and web browsing, there is no cost to message and stay in touch with your friends.

Installing and Configuring Yowsup Under Nagios

Server

Yowsup is an opened WhatsApp service under platforms like Linux, MAC and windows.

Yowsup is a python library that enables you build application which use WhatsApp service. Yowsup has been used to create an unofficial WhatsApp client Nokia N9 through the Wazapp project which was in use by 200K + users as well as another fully featured unofficial client for Blackberry 10.

Yowsup Architecture

A running Yowsup app is a stack of several layers. The previous figure is a breakdown of core Yowsup Stack. A layers is a bidirectional channel that usually transforms the data passing through it before passing it to underlying or the above layer.

Yowsup Installation

Before we start looking under the configuration of nagios we need to install Yowsup library that enables us to send alert using WhatsApp service.

First step to do is to install all dependencies using this command as root user:

apt-get install python python-dateutil python-argparse python-dev python-setuptools

Then download WhatsAPI Yowsup hosted on Github

git clone https://github.com/tgalal/yowsup

Then go to yowsup file and give the script setup.py permission

cd yowsup
chmod +x setup.py

then run this command

python setup.py install

After the command finish the installation you can start your whatsApp configuration by:

chmod +x yowsup-cli

Yowsup Cli client

Yowsup comes with a command line client exposes many yowsup capabilities for quick access in command line. At the moment it supports only a smaller set of yowsup function as it’s still in under heavy development, but eventually it will expose every single yowsup capabilities.

For developers this tool is useful if you’d like to debug some yowsup features and monitor WhatsApp traffic being transmitted. Also useful for developers to see how it implements different types of functionality for use as reference while working on their own project.

For non devs, the tools is also easy to use for quick command line WhatsApp magic.

Yowsup Configuration

Yowsup-cli is a command line interface to Yowsup library. It provides you with the options of registration, and provides a few demos such as a command line client.

First you need to register using yowsup in order to have a valid phone number and password.

./yowsup-cli 
Available commands:
===================
demos, registration, version

Then register your phone number using the command yowsup with the registration option

./yowsup-cli registration --requestcode sms --phone xxxxxxxx --cc 49 --mcc 24 --mnc 07 
INFO:yowsup.common.http.warequest:{"status":"sent","length":6,"method":"sms","retry_after":1805}
status: sent
retry_after: 1805
length: 6
method: sms

WhatsApp Registration options

-m MCC, --mcc MCC Mobile Country Code. Check your mcc here: https://en.wikipedia.org/wiki/Mobile_country_code
-n MNC, --mnc MNC Mobile Network Code. Check your mnc from https://en.wikipedia.org/wiki/Mobile_country_code
-p PHONE, --phone PHONE Your full phone number including the country code you
defined in 'cc', without preceeding '+' or '00'
-C CC, --cc CC Country code. See http://www.ipipi.com/help/telephone-country-codes.htm.

Then you need to finish the registration using this command:

./yowsup-cli registration --register 263-541 --phone xxxxxxxxxxxxxxx --cc 49
INFO:yowsup.common.http.warequest:{"status":"ok","login":"xxxxxxxxxxxxxxx","pw":"0pJj5cLaGSk6pDTa6rJR/5bDiR0=","type":"new","expiration":1471273284,"kind":"free","price":"0,89 \u20ac","cost":"0.89","currency":"EUR","price_expiration":1442376976}
status: ok
kind: free
pw: 0pJj5cLaGSk6pDTa6rJR/5bDiR0=
price: 0,89 €
price_expiration: 1442376976
currency: EUR
cost: 0.89
expiration: 1471273284
login: xxxxxxxxxxxxxx
type: new

Create config file like this example:

nano yowsup-cli.conf

Then add content like in this example:

cc=49 #Your country code
phone=xxxxxxxxxxxx #Your phone number
id= #This is where you insert your IMEI number (not needed)
password=0pJj5cLaGSk6pDTa6rJR/5bDiR0= #your password which you got from registration command

Then you test your configuration by sending sms using this command where “******************” is the receiver number.

./yowsup-cli demos -c yowsup-cli.config -s ************ “test”

Nagios Configuration

Start Nagios configuration by copying the yowsup file to /usr/local/nagios/libexec/.

<span lang="en-US">cp yowsup/ </span><span lang="en-US">/usr/local/nagios/libexec/</span>

After this go under /usr/local/nagios/etc/objects/ and edit the file commands.cfg but that perform a backup of the config file:

cd /usr/local/nagios/etc/objects/
cp commands.cfg commands.cfg.old
Edit the commands.cfg file and you will add two commands ‘notify-host-by-whatsapp and ‘notify-service-by-whatsapp’
notify-service-by-whatsapp
$USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ “$NOTIFICATIONTYPE$ Host : $HOSTNAME$ - Service : $SERVICEDESC$ is $SERVICESTATE$ @ $LONGDATETIME$”

notify-host-by-whatsapp

$USER1$/yowsup/yowsup-cli -c $USER1$/yowsup/yowsup-cli.config -s $_CONTACTWHATSAPP$ “$NOTIFICATIONTYPE$ Host : $HOSTNAME$ is $HOSTSTATE$ @ $LONGDATETIME$”

And we should define the contact under contacts.cfg file like this example

        contact_name                    admin
        use                             generic-contact
        alias                           Admin 
        email                           admin@unixmen.com
        _whatsapp                       xxxxxxxxxxxxxxxxxxxxx
        service_notification_commands   notify-service-by-email notify-service-by-whatsapp
        host_notification_commands      notify-host-by-email notify-host-by-whatsapp

Now the configuration is finished. Before applying the new configuration, run the following command to check for any error or mistake:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

If there are no errors, restart the nagios service:

service nagios restart

And you should get alert notification from nagios like this example:

That all!.

Thanks for reading my article.

 

Send Nagios Alert Notification Using WhatsApp

 




Nagios Check_logfiles

Берем хост под Ubuntu 16.04 server

команды по порядку

sudo apt-get install nagios-nrpe-server nagios-plugins
nano /etc/nagios/nrpe.cfg
allowed_hosts=127.0.0.1, 192.168.1.100
sudo /etc/init.d/nagios-nrpe-server restart

Далее идем сюда https://labs.consol.de/nagios/check_logfiles/index.html#download и качаем архив и распаковываем, я распаковал в /usr/lib/nagios/plugins/check_logfiles-3.7.6.3
потом

./configure 
make 
make install 

Дальше настраиваем по https://kamaok.org.ua/?p=1487
Ок, все стоит. В файл nano /etc/nagios/nrpe.cfg добавляем строки вида

command[check_log_syslog]=/usr/lib/nagios/plugins/check_logfiles-3.7.6.3/plugins-scripts/check_logfiles -t 15 --tag=system --logfile=/var/log/syslog --criticalpattern='OOM killed process'

далее даем права на запись на всю папку /var/tmp/check_logfiles

теперь на сервере Nagios

./check_nrpe -H 192.168.210.91 -c check_log_syslog
OK - no errors or warnings|system_lines=15 system_warnings=0 system_criticals=0 system_unknowns=0



VmWare ESX Monitoring(1)

берем скрипт. ставим пакет и качаем его, подробнее тут — https://habrahabr.ru/company/simnetworks/blog/241605/

Скрипт написан на языке программирования Python, требует библиотеку PyWBEM. Под ОС Linux Debian и Ubuntu она устанавливается через стандартные системные репозитории:
apt-get install python-pywbem

Синтаксис запуска «check_esxi_hardware.py» весьма прост:
check_esxi_hardware.py -H XXX.YYY.WWW.ZZZ -U root -P XXXXXXXX

В ответ вы получите краткий отчет о состоянии здоровья сервера:
OK - Server: Supermicro X9DR3-F s/n: 0123456789 System BIOS: 3.0a 2013-07-31

описание работы самого скрипта тут: https://www.claudiokuenzler.com/nagios-plugins/check_esxi_hardware.php#CommandDefinition

Definition of the parameters

Short Long Description
-H —host Hostname or IP address of ESX/ESXi server
-U —user Username to check (must be a local user on target host)
Note: If you don’t want to use your root user, use this workaround
Use file:/path/to/.file to use first string as username
-P —password Password for given user
Use file:/path/to/.file to use second string as password — this won’t show the password in servers process list
-C —cimport CIM port (default 5989)
-V —vendor (hw_type) Define the vendor of the server: auto, dell, hp, ibm, intel, unknown (default)
auto Plugin tries to determine hardware itself by using CIM entries
dell For DELL servers use dell as hw/vendor type
hp For HP servers use hp as hw/vendor type
ibm For IBM servers use ibm as hw/vendor type
intel For some servers using Intel motherboards this might be needed
unknown If no hw/vendor type was given, unknown will be used (like auto)
-i —ignore Ignore given list (comma separated) of elements
-v —verbose Verbose/detailled output for debugging
-p —perfdata Include server perfdata for graphics like PNP4Nagios or Nagiosgraph
-I —html Add web-links to hardware manuals for Dell servers (use your country extension)

————

Usage

./check_esxi_hardware.py -H esxi-server-ip -U username -P mypass [-C -V -i -v -p -I xx]

./check_esxi_hardware.py —host esxi-server-ip —user username —password mypass [—cimport —vendor —ignore —verbose —perfdata —html xx]

./check_esxi_hardware.py -H esxi-server-ip -U -P file:/path/to/.passwdfile [—vendor —ignore —verbose —perfdata —html xx]

./check_esxi_hardware.py -H esxi-server-ip -U file:/path/to/.passwdfile -P file:/path/to/.passwdfile [—vendor -i -v -p —html xx]

Examples:

./check_esxi_hardware.py -H 10.0.0.200 -U root -P mypass -V dell -p -I de
./check_esxi_hardware.py —host esxiserver1 —user root —password mypass —vendor hp —perfdata
./check_esxi_hardware.py —host esxiserver2 —user root —password mypass —vendor dell —html us
./check_esxi_hardware.py -H esxiserver1 -U root -P file:/root/.esxipass -V dell
./check_esxi_hardware.py -H esxiserver1 -U file:/root/.esxipass -P file:/root/.esxipass -V dell
./check_esxi_hardware.py -H esxiserver1 -U root -P mypass -V dell -i «IPMI SEL»

————

Command definition in your commands.cfg:

# ‘check_esxi_hardware’ command definition
define command{
command_name check_esxi_hardware
command_line $USER1$/check_esxi_hardware.py -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -V $ARG3$
}

Command definition in your commands.cfg with optional parameter:

# ‘check_esxi_hardware’ command definition
define command{
command_name check_esxi_hardware
command_line $USER1$/check_esxi_hardware.py -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -V $ARG3$ $ARG4$
}

Command definition in your commands.cfg with password read from file:

# ‘check_esxi_hardware’ command definition
define command{
command_name check_esxi_hardware
command_line $USER1$/check_esxi_hardware.py -H $HOSTADDRESS$ -U $ARG1$ -P file:$ARG2$ -V $ARG3$ $ARG4$
}

Command definition in your commands.cfg with user and password read from file:

# ‘check_esxi_hardware’ command definition
define command{
command_name check_esxi_hardware
command_line $USER1$/check_esxi_hardware.py -H $HOSTADDRESS$ -U file:$ARG1$ -P file:$ARG2$ -V $ARG3$ $ARG4$
}

————

Service check on a HP Server:

# Check HP Server hardware
define service{
use generic-service
host_name esxi1
service_description Hardware
check_command check_esxi_hardware!root!mypass!hp
}

Service check on a DELL Server:

# Check DELL Server hardware
define service{
use generic-service
host_name esxi2
service_description Hardware
check_command check_esxi_hardware!root!mypass!dell
}

Service check on a DELL Server with perfdata:

# Check DELL Server hardware
define service{
use generic-service
host_name esxi2
service_description Hardware
check_command check_esxi_hardware!root!mypass!dell!—perfdata
}

Service check on a DELL Server with password read from file:

# Check DELL Server hardware
define service{
use generic-service
host_name esxi2
service_description Hardware
check_command check_esxi_hardware!root!/home/nagios/.esxipass!dell
}

Service check on a HP Server with user and password read from file:

# Check HP Server hardware
define service{
use generic-service
host_name esxi1
service_description Hardware
check_command check_esxi_hardware!/home/nagios/.esxipass!/home/nagios/.esxipass!hp
}

Service check on an IBM Server:

# Check IBM Server hardware
define service{
use generic-service
host_name esxi3
service_description Hardware
check_command check_esxi_hardware!root!mypass!ibm
}

Service check on an IBM Server where System Event Log alerts should be ignored :

# Check IBM Server hardware
define service{
use generic-service
host_name esxi3
service_description Hardware
check_command check_esxi_hardware!root!mypass!ibm!-i «IPMI SEL»
}

————

File handling for user and password (for better security!)
Since version 20110505 it is possible to use a file as password-source. The string in the given file is used as password.
Since version 20110614 the file can be used for both username and password.
This is a big security advantage, because the process on the Nagios server won’t show the username or password in cleartext. If no file is used, these values will be shown in cleartext in the processlist.

Please watch out for the correct usage!

Example 1: You want to use a file (/home/nagios/.esxipass) which contains username and password. Note that two strings are separated by a space:

# cat /home/nagios/.esxipass
root mypass123

# ./check_esxi_hardware.py -H 172.17.16.131 -U file:/home/nagios/.esxipass -P file:/home/nagios/.esxipass -V dell

Example 2: You only want to use a file for the password. Note that there is only one string in the file:

# cat /home/nagios/.esxipass
mypass123

# ./check_esxi_hardware.py -H 172.17.16.131 -U root -P file:/home/nagios/.esxipass -V dell

 




check_ilo

берем модуль check_ilo_health.pl

копируем его в /usr/local/nagios/libexec

ставим пакеты

cpan
cpan[6]> install NLEWIS/Net-ILO-0.54.tar.gz