памяти. У него есть 2 сетевые карты,
. Ставим на него
64.
Для возможности отправлять команды из веб-морды - создаём группу и добавляем в неё пользователей
Собирать можно из исходников руками. Но как тогда обновляться? Тоже руками? Хуюшки. Ставим из портов. Но сначала - чуть поправим Makefile. Добавим в подходящие места:
WWWGROUP=icinga-cmd
--enable-idoutils
и включаем EVENT BROKER:
Ставится Icinga и зависимости.
Зависимости:
/usr/ports/devel/libtool
/usr/ports/graphics/jpeg
/usr/ports/graphics/png
/usr/ports/graphics/gd
/usr/ports/devel/gmake
/usr/ports/devel/libltdl
/usr/ports/www/apache22
Шаблоны
Мне показалось удобным использовать стандартные шаблоны, изменив их.
Изменения таковы:
templates.cfg:
notification_interval 0 - слать уведомления о проблеме только один раз.
В файле winservers.cfg размещаем команды для проверки сервисов, общих для всех windows-хостов:
define service{
use generic-service
hostgroup_name winservers
service_description Uptime
check_command check_nt!UPTIME
}
define service{
use generic-service
hostgroup_name winservers
service_description CpuLoad
check_command check_nt!CPULOAD!-l 5,80,90
}
define service{
use generic-service
hostgroup_name winservers
service_description Drive_C
check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90
}
define service{
use generic-service
hostgroup_name winservers
service_description Memory
check_command CheckMem!80!90
}
далее в файле groups.cfg пишем:
define hostgroup{
hostgroup_name winservers ; The name of the hostgroup
alias winservers ; Long name of the group
members my_win_server, pupkins_workstation
}
my_win_server.cfg:
define host{
use generic-host ; Name of host template to use
host_name my_win_server
alias my_win_server
address 192.168.0.254
}
Все эти три конфига - my_win_server.cfg, groups.cfg и winservers.cfg - находятся, допустим, в директории /usr/local/etc/icinga/custom. Для того, чтобы icinga узнало об этих конфигах - надо в файле icinga.cfg сказать:
cfg_dir=/usr/local/etc/icinga/custom
и тогда при запуске конфиг-файлы будут искаться и в этой директории.
NRPE
Для проверок механизмом NRPE нужна клиентская часть, которая спрашивает серверную, задаёт ей вопросы. Например:
-> CheckMEM?
<- 32Gb всего, 28 занято
или:
-> CheckLOAD?
<- 5,07 3,2 2,8
То есть придётся ставить NRPE-демон на опрашиваемый компьютер.
check_nrpe2 - исполняемый файл на сервере. стоит он там же, где и остальные плагины - /usr/local/libexec/icinga
Nrpe - демон есть в репозиториях любой операционки, либо качается отдельно.
Например, можно поставить его вручную на redhat-подобные:
Качаем руками nrpe*.rpm из репозитория
Распаковываем в /usr/local/nrpe
Копируем загрузочный скрипт в /etc/init.d
Создаём симлинки на скрипт в /etc/rc0.d -> K99nrpe;
/etc/rc3.d -> S99nrpe; /etc/rc5.d -> S99nrpe
Правим /etc/init.d/nrpe: CONFIG="/usr/local/nrpe/nrpe.cfg"
Правим конфиг
/usr/local/nrpe/nrpe.cfg:
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
#server_address=127.0.0.1
nrpe_user=nagios # или какой вам нравится. надо только его ручками создать
nrpe_group=nagios
allowed_hosts=127.0.0.1,192.168.0.253 # хосты, которым можно работать с этим демоном.
dont_blame_nrpe=0 # когда 0 - не разрешать выполнять другие команды, кроме описанных в этом конфиге
# command_prefix=/usr/bin/sudo # можно выполнять команды от рута. например, не в целях мониторинга, а что-то удалённо колхозить руками или по расписанию.
debug=1 # только на время запуска и отладки. так-то лучше 0, чтобы в лог херни не писал.
command_timeout=60
connection_timeout=300
#allow_weak_random_seed=1
#include=<somefile.cfg>
#include_dir=<somedirectory>
# Описание команд, которые может выполнять демон.
# Естественно, файлы должны быть доступны на исполнение и лежать там, где указано.
command[check_users]=/usr/local/nrpe/check_users -w 5 -c 10
command[check_load]=/usr/local/nrpe/check_load -w 15,10,5 -c 30,25,20
command[check_hdd2]=/usr/local/nrpe/check_disk -w 20% -c 10% -p /dev/sdb1
command[check_opt]=/usr/local/nrpe/check_disk -w 20% -c 10% -p /dev/mapper/vg_vmachine-opt
command[check_var]=/usr/local/nrpe/check_disk -w 20% -c 10% -p /dev/mapper/vg_vmachine-var
command[check_zombie_procs]=/usr/local/nrpe/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/nrpe/check_procs -w 150 -c 200
# самодельные скрипты
command[check_mem]=/usr/local/nrpe/check_memory.sh
command[check_swap]=/usr/local/nrpe/check_swap.sh
# запущены ли процессы с такой строчкой? в данном случае - сервер Jetty и ещё один демон на питоне.
command[check_jetty]=/usr/local/nrpe/check_procs -w 1:1 -c 1:1 -a jetty
command[check_python3]=/usr/local/nrpe/check_procs -w 10:10 -c 10:10 -a python3
Шаблон для проверок NRPE выглядит так:
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe2 -H $HOSTADDRESS$ -n -c $ARG1$ -t $ARG2$
}
Для виндов можно заранее настрогать заготовок:
define command {
command_name CheckMem
command_line $USER1$/check_nrpe2 -H $HOSTADDRESS$ -n -p 5666 -c CheckMEM -a MaxWarn=$ARG1$% MaxCrit=$ARG2$% ShowAll type=physical
}
define command {
command_name CheckCPU
command_line $USER1$/check_nrpe2 -H $HOSTADDRESS$ -n -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=15m time=5m time=1m
}
define command {
command_name CheckDISK_C
command_line $USER1$/check_nrpe2 -H $HOSTADDRESS$ -n -p 5666 -c CheckDriveSize -a ShowAll MinWarnFree=$ARG1$% MinCritFree=$ARG2$% Drive=c:
}
Тогда в конфиге хоста надо будет только добавить то, что указано в шаблонах.
NSCLIENT
Nsclient++ - клиент для Windows. Есть для i386 и для i386_64. Среди прочего умеет и nrpe.
Установка как обычно.
Править конфиг лучше при выключенной службе, потом службу запускать заново.
Конфиг в файле C:\Program Files\NSClient++\NSC.ini
Что должно быть, чтобы заработало:
NRPEClient.dll
allowed_hosts=192.168.0.253
use_ssl=0
allow_arguments=1
Можно просто почитать конфиг и поиграть с параметрами - включить ssl и прочее.
EMAIL
Команду для отправки можно не менять.
Настройка почтовика - нужно разрешить отсылать почту без аутентификации для хоста, на котором мониторинг. Или занимайтесь вопросами авторизации самостоятельно :)
Шаблоны для уведомлений:
Например, у нас круглосуточное производство и два админа - дневной и ночной.
define contact{
contact_name admin_night
use generic-contact
alias NightAdminName
email ччч@мейл.ру
}
define contactgroup{
contactgroup_name admins_alternate
alias Icinga Administrators
members admin_day, admin_night
}
define host{
use generic-host ; Name of host template to use
host_name my_win_server
alias my_win_server
contact_groups admins_alternate
address 192.168.0.254
}
И всё, уведомления приходят обоим админам.
SMS -> модем
Представим, что сеть упала нахрен напрочь. И уведомления отправить нельзя. Остаётся только sms-уведомление.
У меня есть COM-портовый модем cinterion. Для него подходит smstools3, есть в портах.
Ставим, настраиваем:
/usr/local/etc/smsd.conf:
devices=GSM1
logfile=/var/log/smsd.log
loglevel=4
USER=icinga
GROUP=dialer
umask=022
PIDFILE=/var/run/smsd/smsd.pid
INFOFILE=/var/run/smsd/smsd.working
[GSM1]
device = /dev/cuau0
incoming = yes
pin = 5452 # pin-код симки
СМС-ки пишутся в файлы в папках в /var/spool/sms/
Нужно убедиться, что на папку выставлены соответствующие права, и демон запускается именно под тем пользователем. Вся отладка есть в логах.
Скрипты отправки СМС:
# 'notify-service-by-sms' command definition
define command{
command_name notify-service-by-sms
command_line /usr/local/bin/sendsms $CONTACTPAGER$ "$NOTIFICATIONTYPE$ $HOSTALIAS$:$SERVICEDESC$ $SERVICEOUTPUT$"
}
# 'notify-host-by-sms' command definition
define command{
command_name notify-host-by-sms
command_line /usr/local/bin/sendsms $CONTACTPAGER$ "$NOTIFICATIONTYPE$ $HOSTNAME$:$HOSTSTATE$ - $HOSTOUTPUT$ - $LONGDATETIME$"
}
Настройки контактов:
define contact{
contact_name admin_ph
alias admin_ph
host_notification_period 24x7
service_notification_period 24x7
service_notification_options c,r
service_notification_commands notify-service-by-sms
host_notification_commands notify-host-by-sms
pager 7********** # прошу заметить - именно так, 7, затем 10 цифр
}
Графики
nagiosgrapher or nagiosgraph?
Подводные камни
Иногда не стартует ido2db - интерфейс к базе. Надо его контролировать. В настройках по умолчанию это есть. (localhost.cfg). Также надо перезапускать его, когда перезапускаешь icinga.
При плановом обслуживании серверов есть возможность задавать downtime сервера - чтобы не ругался мониторинг почём зря.
На случай сбоев самого мониторинга - можно завести ещё один, где-нибудь на виртуалке, чтобы прикрывал основной. То есть 2 icinga, которые смотрят друг за другом.