Я не получаю уведомления по электронной почте, используя Nagios Core 4
У меня проблема с автоматическим уведомлением по почте в Nagios Core 4, установленном на сервере Ubuntu 12.04 LTS (Precise Pangolin)...
Я попытался отправить почту пользователю nagios и пользователю root с помощью команды:
echo "test" | mail -s "test mail" support@xxxx.eu
И я получил письмо правильно... Но я не получаю никакого автоматического почтового уведомления. Как я могу решить эту проблему?
Это мои файлы конфигурации (commands.cfg, contacts.cfg, nagios.log, mail.log):
commands.cfg
(Путь /usr/bin/mail - правильный путь)
# 'notify-host-by-email' command definition
define command{
command_name notify-host-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
}
# 'notify-service-by-email' command definition
define command{
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
# 'process-host-perfdata' command definition
define command{
command_name process-host-perfdata
command_line /usr/bin/printf "%b" "$LASTHOSTCHECK$\t$HOSTNAME$\t$HOSTSTATE$\t$HOSTATTEMPT$\t$HOSTSTATETYPE$\t$HOSTEXECUTIONTIME$\t$HOSTOUTPUT$\t$HOSTPERFDATA$\n" >> /usr/local/nagios/var/host-perfdata.out
}
# 'process-service-perfdata' command definition
define command{
command_name process-service-perfdata
command_line /usr/bin/printf "%b" "$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEATTEMPT$\t$SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$\n" >> /usr/local/nagios/var/service-perfdata.out
}
contacts.cfg:
define contact{
contact_name supporto
alias Supporto Clienti DEA
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email supporto@xxxx.eu
}
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members supporto
}
nagios.log:
[1401871412] SERVICE ALERT: fileserver;Current Users;OK;SOFT;2;USERS OK - 1 users currently logged in
[1401871953] SERVICE ALERT: backups;Nagios Status;WARNING;SOFT;1;NAGIOS WARNING: 36 processes, status log updated 541 seconds ago
[1401872133] SERVICE ALERT: backups;Nagios Status;OK;SOFT;2;NAGIOS OK: 36 processes, status log updated 180 seconds ago
[1401872321] SERVICE ALERT: posta;Swap Usage;CRITICAL;SOFT;1;CRITICAL - Plugin timed out after 10 seconds
[1401872322] SERVICE ALERT: fileserver;Current Users;CRITICAL;SOFT;1;CRITICAL - Plugin timed out after 10 seconds
[1401872420] SERVICE ALERT: archivio;Disk Space;CRITICAL;SOFT;1;CRITICAL - Plugin timed out after 10 seconds
[1401872492] SERVICE ALERT: fileserver;Current Users;OK;SOFT;2;USERS OK - 1 users currently logged in
[1401872492] SERVICE ALERT: posta;Swap Usage;OK;SOFT;2;SWAP OK: 100% free (1984 MB out of 1984 MB)
[1401872590] SERVICE ALERT: archivio;Disk Space;OK;SOFT;2;DISK OK
[1401872931] Auto-save of retention data completed successfully.
[1401873333] SERVICE ALERT: backups;Nagios Status;WARNING;SOFT;1;NAGIOS WARNING: 36 processes, status log updated 402 seconds ago
[1401873513] SERVICE ALERT: backups;Nagios Status;OK;SOFT;2;NAGIOS OK: 36 processes, status log updated 180 seconds ago
mail.log
(Я думаю, что проблема здесь, но я не знаю, как ее решить.)
Jun 4 10:00:01 backups sm-msp-queue[6109]: My unqualified host name (backups) unknown; sleeping for retry
Jun 4 10:01:01 backups sm-msp-queue[6109]: unable to qualify my own domain name (backups) -- using short name
Jun 4 10:20:01 backups sm-msp-queue[7247]: My unqualified host name (backups) unknown; sleeping for retry
Jun 4 10:21:01 backups sm-msp-queue[7247]: unable to qualify my own domain name (backups) -- using short name
Jun 4 10:40:01 backups sm-msp-queue[8327]: My unqualified host name (backups) unknown; sleeping for retry
Jun 4 10:41:01 backups sm-msp-queue[8327]: unable to qualify my own domain name (backups) -- using short name
Jun 4 11:00:01 backups sm-msp-queue[9549]: My unqualified host name (backups) unknown; sleeping for retry
Jun 4 11:01:01 backups sm-msp-queue[9549]: unable to qualify my own domain name (backups) -- using short name
Jun 4 11:20:01 backups sm-msp-queue[10678]: My unqualified host name (backups) unknown; sleeping for retry
Jun 4 11:21:01 backups sm-msp-queue[10678]: unable to qualify my own domain name (backups) -- using short name
Я на последнем шаге и хочу закончить это ядро Nagios!:)
Определение хоста (на этом хосте диск почти заполнен, и он находится в тяжелом состоянии, но без уведомления):
define host{
use generic-host ; Name of host template to use
host_name posta
alias Server Posta ESA
address 10.10.2.102
parents xen1, xen2
icon_image redhat.png
statusmap_image redhat.gd2
}
Определение сервиса:
define service{
use generic-service
host_name xen1, maestro, xen2, posta, nas002, serv2, esasrvmi02, esaubuntumi
service_description Disk Space
check_command ssh_all_disks!10%!5%
}
Уведомление разрешено для определения контакта, которое вы дали, но также разрешено ли оно на уровне обслуживания?
Извините, но я этого не понимаю!:(
3 ответа
От твоего nagios.log Я вижу только мягкие ошибки состояния. Nagios не отправляет никаких уведомлений о состоянии SOFT, только в случае состояния HARD. Из документации Nagios:
Мягкие состояния
Мягкие состояния возникают для сервисов и хостов в следующих ситуациях...
1) Когда проверка службы или хоста приводит к состоянию, отличному от OK, и она еще не была (повторно) проверена количество раз, указанное параметром в определении службы или хоста. Давайте назовем это мягким состоянием ошибки...
2) Когда служба или хост восстанавливается из состояния мягкой ошибки. Это считается мягким восстановлением.
События Soft State
Что происходит, когда служба или хост находятся в состоянии "мягкой" ошибки или происходит "мягкое" восстановление?
1) Мягкая ошибка или восстановление регистрируется, если вы включили опции log_service_retries или log_host_retries в основном файле конфигурации.
2) Обработчики событий выполняются (если вы их определили) для обработки мягкой ошибки или восстановления для службы или хоста. (Перед выполнением любого обработчика событий макрос $STATETYPE$ устанавливается в "SOFT"). Nagios не отправляет уведомления ни одному контакту, потому что нет (или было) никаких "реальных" проблем со службой или хостом.
Как видно, единственное важное, что действительно происходит во время мягкого состояния, - это выполнение обработчиков событий. Использование обработчиков событий может быть особенно полезно, если вы хотите заранее попытаться устранить проблему, прежде чем она перейдет в сложное состояние.
Тяжелые состояния
Жесткие состояния возникают для хостов и сервисов в следующих ситуациях:
1) Когда проверка хоста или службы приводит к состоянию не UP или не OK, и было (повторно) проверено количество раз, указанное параметром max_check_attempts в определении хоста или сервиса. Это серьезная ошибка.
2) Когда хост или служба переходит из одного состояния жесткой ошибки в другое состояние ошибки (например, ПРЕДУПРЕЖДЕНИЕ к КРИТИЧЕСКОМУ).
3) Когда проверка службы приводит к состоянию, отличному от OK, и соответствующий хост имеет значение DOWN или UNREACHABLE.
4) Когда хост или сервис восстанавливается из состояния жесткой ошибки. Это считается трудным восстановлением.
5) Когда получена пассивная проверка хоста. Пассивные проверки хостов рассматриваются как HARD, если не включена опция passive_host_checks_are_soft.
Следующие вещи происходят, когда хосты или службы испытывают изменения состояния HARD:
1) Состояние HARD регистрируется. 2) Обработчики событий выполняются для обработки состояния HARD. 3) Контакты уведомляются о проблеме хоста или сервиса или восстановления.
Итак, из того, что мы видим в журнале, который вы приводите в качестве примера, Nagios не нужно было отправлять почту. Вы должны создать условие ошибки в одной из отслеживаемых служб, пусть это условие существует некоторое время и посмотреть, действительно ли вы получаете почту, когда состояние изменяется на HARD в nagios.log.
Последнее, что я заметил, в тесте командной строки вы отправляете почту support@xxxx.eu в то время как в вашем contacts.cfg определенный адрес электронной почты supporto@xxxx.eu (возможно, у вас есть псевдонимы, определенные на ваших почтовых серверах, а может и нет).
Добавлено после добавления логов на вопрос В nagios.log что вы показываете, нет строки УВЕДОМЛЕНИЕ ОБСЛУЖИВАНИЯ, поэтому даже когда ошибка находится в состоянии HARD, Nagios даже не пытается сделать уведомление. Чтобы уведомления работали в Nagios, недостаточно четко определить контакты, группы контактов и команды уведомлений. Вы должны настроить для каждой службы и хоста, если вы хотите отправить уведомление в случае ошибки и, конечно, какой контакт (ы) и / или контактную группу (ы), чтобы отправить это уведомление. Например, это определение сервиса с настроенным и работающим уведомлением:
define service {
name generic-service
first_notification_delay 0
notification_interval 0
notification_options w,u,c,r
notifications_enabled 1
check_period 24x7
notification_period 24x7
contact_groups admins
}
В приведенном выше определении notification_enabled установлен на 1 (true) и группа контактов, как было дано для отправки уведомления. Кроме того, мы определяем, какой тип уведомления отправлять - w(arning), u(неизвестно), c(ритуально) и r(обнаружение).
Приведенное выше определение используется в качестве шаблона всеми моими службами:
use generic-service
присутствует во всех моих определениях услуг. Таким образом, если мне нужно изменить параметры уведомления, мне просто нужно изменить generic-service определение. В вашем случае ваш конфиг показывает, что ваш сервис использует шаблон под названием generic-service, Я бы посоветовал проверить его определение, чтобы увидеть, настроены ли уведомления, как в примере, который я привел выше. Его определение может быть помещено в файл с именем services-templates.cfg но это может варьироваться.
Спасибо Бенуа за ваш ответ. Я хотел бы добавить пару вещей, немного поиграв с ним:
Легко узнать, где вы находитесь со всеми этими шаблонами и переопределениями, если вы просматриваете файл кэша, который является вычисленным результатом всех конфигураций: /usr/local/nagios/var/objects.cache
После того, как я был там, меня поразило... мой сервис настроен на отправку уведомлений только в рабочее время, что оказалось для меня немного неправильным, потому что я нахожусь в другом часовом поясе по сравнению с сервером. Изменение на 24x7 заставило все работать как шарм.
Я надеюсь, что это поможет кому-то.. Потратил часы, чтобы выяснить все это.
Ура!
Самая полезная информация заключалась в том, чтобы перепроверить содержимое/usr/local/nagios/var/objects.cacheдля проверки всех наследств всех .cfg.
Теперь это также решало мои проблемы.