Статьи Система мониторинга Nagios Система мониторинга на основе Nagios
| Main Menu | |||||
|---|---|---|---|---|---|
|
Система мониторинга на основе Nagios |
| Написал Бешков Андрей | ||||||
| Пятница, 01 Апреля 2005 | ||||||
Page 3 of 4 Давайте осмотрим содержимое директории конфигурационных файлов. # cd /usr/local/nagios/etc В названии каждого файла есть фрагмент -sample, значит, все вышеперечисленные файлы являются не полноценными конфигурациями, а всего лишь примерами. На случай, если нам вдруг захочется посмотреть, что там у них внутри, скопируем их в директорию sample. Может быть, когда-то они нам еще пригодятся. # mkdir sample Переименовываем все файлы, отсекая цепочку символов -sample. Таким образом, мы готовим файлы к тому, чтобы Nagios смог их заметить и правильно воспринять. В результате должно получиться что-то вроде: # ll К сожалению, файлы все еще не готовы к употреблению. Nagios даже не сможет стартовать, если мы попытаемся его запустить. Разобраться в содержимом файлов примеров, созданных во время инсталляции, довольно сложно. Самым лучшим выходом из подобной ситуации будет уничтожение всех конфигурационных данных и создание их вручную под моим чутким руководством. Такой подход принесет более глубокое понимание используемой методики настройки. Обнуляем все необходимые файлы. # cp /dev/null hosts.cfg services.cfg contacts.cfg contactgroups.cfg hostgroups.cfg Начиная с версии 1.0b2, в Nagios появилась возможность использовать шаблоны внутри конфигурационных файлов. Такая методика настройки позволяет многократно снизить время создания рабочей конфигурации. Перед нами стоит задача описать два хоста mail.firma.ru и proxy.firma.ru. Каждый сервер, находящийся под наблюдением, должен быть описан в файле хостов. Поэтому первым делом заполняем именно этот файл. Содержимое файла hosts.cfg # Описываем шаблон хоста define host{ name generic-host # Имя шаблона - будем ссылаться на него позже при описании каждого хоста notifications_enabled 1 # Включаем уведомления event_handler_enabled 1 # Включаем обработчик событий flap_detection_enabled 1 # Включаем обнаружение мерцания process_perf_data 1 # Собирать статистику об эффективности работы процесса retain_status_information 1 # Сохранять статусную информацию между перезагрузками программы retain_nonstatus_information 1 # Сохранять нестатусную информацию между перезагрузками программы register 0 # Указываем, что все вышеописанное - это шаблон. Запрещаем регистрировать # это описание как хост } # Описываем хост по имени mail define host{ use generic-host # Ссылка на используемый шаблон host_name mail # Имя хоста alias Mail Server # Псевдоним хоста address mail.firma.ru # Имя хоста в формате fqdn или его адрес check_command check-host-alive # Команда проверки хоста выполняется обычно с помощью ping. Подробнее можно # почитать в файле checkcommands.cfg max_check_attempts 10 # Количество попыток повторного тестирования после того, как одна из попыток # возвратила ошибочный статус. notification_interval 120 # Интервал в минутах, по прошествию которого нужно повторно отсылать # уведомление, если сервер все еще не работает. notification_period 24x7 # Период времени, в течение которого серверу разрешено беспокоить администратора # своими уведомлениями. В данном случае это круглые сутки. Подробнее о периодах # можно почитать в файле timeperiods.cfg. notification_options d,u,r # Список событий, при наступлении которых необходимо отсылать # уведомления. Соответственно d,u,r (DOWN, UNREACHABLE, RECOVERY) # означает события "работает", "недоступен", "восстановлен". } # Описываем хост по имени proxy define host{ use generic-host host_name proxy # Имя хоста. Также стоит обратить внимание на изменившиеся записи alias и address. alias Proxy Server address proxy.firma.ru check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } Каждый хост должен состоять хотя бы в одной группе хостов. Опираясь на группы хостов, Nagios сможет определить, какую из групп администраторов нужно оповещать. Данные, полностью описывающие группы хостов, находятся в файле hostgroups.cfg. Формат этого файла настолько прост, что механизм шаблонов применять смысла нет. Посмотрим, чем заполнен этот файл. Содержимое файла hostgroups.cfg define hostgroup{ hostgroup_name firma-servers # Имя группы alias Firma Servers # Псевдоним группы contact_groups firma-admins # Список групп контактов, которые нужно уведомлять members mail proxy # Список серверов, принадлежащих к группе } Пришло время вплотную заняться описанием сервисов, за которыми нужно наблюдать. Как и во всех остальных конфигурационных файлах, первым делом необходимо создать шаблон сервиса. Мы разберем его подробно. Затем, второй и третьей записью, будут описаны сервисы HTTP и PING, базирующиеся на хосте proxy.firma.ru. Соответственно, далее мы работаем с mail.firma.ru, на котором у нас базируются SMTP и IMAP. Содержимое файла services.cfg # Описываем шаблон сервиса define service{ name generic-service # Имя шаблона active_checks_enabled 1 # Включить активные проверки passive_checks_enabled 1 # Принимать результаты пассивных проверок parallelize_check 1 # Активные проверки лучше выполнять паралельно, # такой подход повышает скорость работы obsess_over_service 0 # Эту опцию стоит включать только при создании распределенной # системы мониторинга. check_freshness 0 # Следить за свежестью результатов проверок. По умолчанию отключено notifications_enabled 1 # Уведомления включены event_handler_enabled 1 # Включить обработчики событий flap_detection_enabled 1 # Использовать обнаружение мерцания process_perf_data 1 # Собирать данне об эффективности выполнения проверок retain_status_information 1 # Сохранять информацию о статусе между перезапусками Nagios retain_nonstatus_information 1 # Сохранять нестатусную информацию между перезапусками Nagios register 0 # Запрещаем регистрировать это описание как сервис } # Описываем сервис HTTP для хоста proxy.firma.ru define service{ use generic-service # Имя используемого шаблона hostname proxy.firma.ru # Имя хоста service_description HTTP # Описание сервиса is_volatile 0 # Для стандартных сервисов лучше оставить значение 0 # К нестандартным сервисам стоит относить те сервисы, которые # после каждой проверки автоматически возвращаются в состояние "ОК" # вне зависимости от режима, в котором они находились до проверки. check_period 24x7 # Период, в течение которого можно выполнять проверки max_check_attemps 3 # Максимальное количество повторных проверок normal_check_interval 5 # Интервал между нормальными проверками retry_check_interval 1 # Интервал между повторными проверками. Применяется, если # нормальная проверка завершилась неудачно contact_groups firma-admins # Группа контактов, используемая для оповещения notification_interval 120 # Интервал (в минутах), после которого нужно послать повторное уведомление, # если сервис так и не восстановился notification_period 24x7 # Период, в течение которого можно производить отправку уведомлений notification_options w,u,c,r # Список событий, при наступлении которых необходимо # отсылать уведомления. check_command check_http # Имя команды, выполняемой для проверки сервиса } # Описываем сервис PING для хоста proxy.firma.ru define service{ use generic-service # Имя используемого шаблона hostname proxy.firma.ru # Имя хоста service_description PING # Описание сервиса is_volatile 0 check_period 24x7 # Период, в течение которого можно выполнять проверки max_check_attempts 3 # Максимальное количество повторных проверок normal_check_interval 5 # Интервал между нормальными проверками retry_check_interval 1 # Интервал между повторными проверками. Применяется, если # нормальная проверка завершилась неудачно contact_groups firma-admins # Группа контактов, используемая для оповещения notification_interval 120 # Интервал (в минутах), после которого нужно послать повторное уведомление, # если сервис так и не восстановился notification_period 24x7 # Период, в течение которого можно производить отправку уведомлений notification_options w,u,c,r # Список событий, при наступлении которых необходимо # отсылать уведомления. check_command check_ping # Имя команды, выполняемой для проверки сервиса } # Описываем сервис SMTP для хоста mail.firma.ru define service{ use generic-service hostname mail.firma.ru service_description SMTP # Описание сервиса is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups firma-admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_smtp # Имя команды, выполняемой для проверки сервиса } # Описываем сервис IMAP для хоста mail.firma.ru define service{ use generic-service hostname mail.firma.ru service_description IMAP # Описание сервиса is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups firma-admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_imap # Имя команды, выполняемой для проверки сервиса } Как Вы, возможно, сумели догадаться, имена команд, вызываемых для выполнения проверки того или иного сервиса, определяются параметром check_command. Сами же команды описываются в файле checkcommands.cfg. По странному стечению обстоятельств команда check_imap в этом файле не описана, несмотря на то, что среди модулей, установленных в директорию /usr/local/nagios/libexec/, файл check_imap присутствует. Видимо, это еще одна ошибка программистов Nagios. Ну и ладно, нам не привыкать делать все собственными руками. Разместим в любом месте файла checkcommands.cfg следующие строки: # 'check_imap' command definition define command{ command_name check_imap command_line $USER1$/check_imap -H $HOSTADDRESS$ } Стоит отметить что имена хостов в файлах hosts.cfg и services.cfg должны быть идентичны. Мне казалось что это достаточно логично, но некоторые читатели почему то испытывают трудности с осознанием этого файкта. Создав описание сервисов, самое время перейти к определению списка людей, которым система будет отсылать оповещения. В терминологии Nagios каждая запись в файле contacts.cfg описывающая человека - это контакт. Формат записи довольно прост, поэтому и в данном случае шаблоны нам не пригодятся. Содержимое файла contacts.cfg define contact{ contact_name tigrisha # Имя контакта alias Andrei Beshkov # Имя человека service_notification_period 24x7 # Период времени, в течение которого разрешено посылать уведомления # о состоянии сервисов host_notification_period 24x7 # Период времени, в течение которого разрешено посылать уведомления # о состоянии хостов service_notification_options w,u,c,r # Список событий сервисов, при наступлении которых необходимо # отсылать уведомления. host_notification_options d,u,r # Список событий хостов, при наступлении которых необходимо # отсылать уведомления. service_notification_commands notify-by-email, notify-by-epager # Команды рассылки уведомлений о событиях сервиса host_notification_commands host-notify-by-email, host-notify-by-epager # Команды рассылки уведомлений о событиях хоста email # Почтовый адрес pager # Адрес системы пейджинга } define contact{ contact_name amon # Имя контакта alias Dmitry Larin # Имя человека service_notification_period 24x7 # Период времени, в течение которого разрешено посылать уведомления о состоянии сервисов host_notification_period 24x7 # Период времени, в течение которого разрешено посылать уведомления о состоянии хостов service_notification_options w,u,c,r # Список событий сервисов, при наступлении которых необходимо # отсылать уведомления. host_notification_options d,u,r # Список событий хостов, при наступлении которых необходимо # отсылать уведомления. service_notification_commands notify-by-email, notify-by-epager # Команды рассылки уведомлений о событиях сервиса host_notification_commands host-notify-by-email, host-notify-by-epager # Команды рассылки уведомлений о событиях хоста email # Почтовый адрес pager # Адрес системы пейджинга } Каждый контакт должен принадлежать как минимум одной контактной группе. Давайте создадим такую группу для контактов, описанных выше. Содержимое файла contactgroups.cfg define contactgroup{ contactgroup_name firma-admins # Имя контактной группы alias firma.ru Admins # Псевдоним группы members tigrisha amon # Список контактов состоящих в группе } Файл dependencies.cfg отвечает за зависимости между хостами. Ну а файл escalations.cfg, в свою очередь, описывает эскалацию оповещений. В связи с тем, что рассматриваемый нами пример состоит всего из двух хостов, файлы зависимостей и эскалации нам не пригодятся. Отсюда вытекает приятный факт, говорящий, что необходимости заполнять их у нас нет. Возможно, в следующей статье я подробно опишу работу с файлами зависимостей и эскалации. Конфигурирование наконец-то завершено. |
||||||
| Последнее обновление ( Воскресенье, 17 Июня 2007 ) | ||||||
| След. > |
|---|
