 |
|
|
|
Осваиваем Nagios
Осваиваем Nagios Пройдя парадным маршем через установку, настройку и примеры успешного использования Nagios в реальной жизни, мы завоевали для себя довольно просторное место под солнцем. После трех предыдущих статей [1, 2, 3] у читателей накопилось некоторое количество вопросов. Это значит, что, несмотря на все былые успехи, пришло время прекратить расширять свои владения и перейти на интенсивный путь развития. Слегка замедлим свой бег вперед и займемся благоустройством захваченного пространства. Как обычно, в начале статьи хотелось бы упомянуть то обстоятельство, что описываемые действия выполнялись на хосте, работающем под управлением FreeBSD 4.8. Переживать по этому поводу не стоит, так как все обсуждаемые приемы будут отлично работать с любым дистрибутивом Unix-подобных операционных систем, для которых существует версия Nagios. Единственным щекотливым моментом может быть различие в именах директорий, где расположились Nagios и остальное вспомогательное программное обеспечение, необходимое для нашей работы. Первым делом хотелось бы научить Nagios «говорить» на чистом русском языке. Примерно девять месяцев назад я завершил работы по локализации Nagios версии 1.06 beta. Затем, по мере выхода новых версий продукта, та же судьба постигла официальные релизы 1.0 и 1.1. Методика русификации для всех версий одинакова, поэтому я буду описывать ее на примере версии 1.1 как наиболее свежей и, надеюсь, наиболее распространенной. Итак, что же нам нужно сделать? Первым делом скачиваем дистрибутив версии Nagios, которая установлена у вас с официального сайта http://www.nagios.org. Здесь берем соответствующие файлы локализации: http://onix.opennet.ru/files. Распаковываем дистрибутив и пакет локализации в любое удобное место, например в директорию /tmp. # tar zxvf nagios-1.1.tar.gz # tar zxvf nagios_rus_1_1.tar.gz Копируем все необходимые файлы из пакета локализации в распакованный дистрибутив и затем, как обычно, проводим конфигурирование. # cp –R /tmp/nagios_rus_1_1/* /tmp/nagios-1.1/ # cd nagios-1.1 # ./configure --prefix=/usr/local/nagios --with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/ --with-nagios-user=nagios --with-nagios-grp=nagios --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include/gd? Я думаю, объяснять назначение ключей команды configure смысла нет. Поэтому сразу же переходим к компиляции. /usr/local/etc/nagios.sh stop После того как этот процесс завершится успешно, останавливаем демона Nagios. Все-таки резать по живому не очень хорошо, и подобные действия могут вызвать разнообразные сбои в функционировании системы мониторинга. # make install Вот теперь можно спокойно выполнять инсталляцию. # make all В результате файлы из директории дистрибутива должны заменить те файлы, которые Nagios использовал до сегодняшнего дня. Таким образом, файлы из /tmp/nagios-1.1/html должны попасть в /usr/local/nagios/share/, а скомпилированные файлы из /tmp/nagios-1.1/cgi в /usr/local/nagios/sbin/. Снова запустив Nagios и обратившись к веб-интерфейсу, должны увидеть что-то вроде такой картинки:
Судя по всему, русификация прошла без сучка без задоринки. Следующая проблема, нуждающаяся в исправлении, – неработающая карта сети. При попытке воспользоваться пунктами «Карта сети» (statusmap.cgi) и «3D карта сети» (statuswrl.cgi) на экране вместо карты обычно появляется такое меню:
Причин этому может быть две. Первая – не работает библиотека GD, которую мы установили вместе с Nagios. И вторая – в используемом нами браузере отсутствует или неправильно работает подключаемый модуль для отображения vrml. Итак, начнем с первой проблемы. Если вы помните, перед компилированием Nagios мы использовали команду configure. Следует обратить особое внимание на параметры --with-gd-lib и --with-gd-inc, которые указывают на директории, где в нашей системе находятся заголовочные и библиотечные файлы пакета GD. Команда configure пытается автоматически подключить нужные файлы к проекту, но ей не всегда это удается. Обычно в процессе конфигурирования на экран выводятся соответствующие сообщения, но вся проблема в том, что туда же сыпется довольно много прочих диагностических сообщений, и поэтому найти и понять то, что нам нужно в этом винегрете, довольно сложно. Для более точного диагностирования проблемы очистим дистрибутив от файлов конфигурации, созданных во время предыдущей компиляции командой: # make clean Затем перенаправим все сообщения команды configure в файл make.log c помощью следующей конструкции: # ./configure --prefix=/usr/local/nagios --with-cgi-url=/nagios/cgi-bin --with-html-url=/nagios/ --with-nagios-user=nagios --with-nagios-grp=nagios --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include/gd > make.log? Если во время компоновки gd не найден, то внутри файла make.log среди всего прочего будут вот такие надписи:
Ну а в случае, если вам повезло и вы нашли в указанном выше файле вот такое:
значит с GD у вас все в порядке, и вы можете спокойно пойти попить кофе, пока я расскажу остальным, как избавиться от проблем с этой неуловимой библиотекой. По традиции начинаем с FreeBSD. Посмотреть, устанавливалась ли библиотека GD в эту систему стандартными средствами, то есть с помощью пакетов или портов, можно командой: # pkg_info | grep gd
Теперь мы знаем полное название пакета. Смотрим, куда установились его файлы. # pkg_-L gd-1.8.4_6
Итак, судя по выводу, параметры команды configure, относящиеся к библиотке GD, должны выглядеть так: --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include/gd Давайте посмотрим, как можно добиться подобного эффекта для Linux-систем, основанных на rpm. В качестве примера возьмем ALT Linux. # rpm -qa | grep gd
В отличие от FreeBSD, в Linux-системах библиотека GD обычно разделена на два отдельных пакета. Судя по всему, нас интересуют rpm-файлы libgd2 и libgd2-devel. Первый содержит динамически загружаемые библиотеки, ну а второй, соответственно, заголовочные файлы. # rpm -ql libgd2
# rpm -ql libgd2-devel
Ну и наконец, универсальный способ, подходящий для любой Unix-подобной операционной системы. Им можно воспользоваться в случае, если все предыдущие попытки не дали никаких результатов. Нужно самостоятельно отыскать, где находятся файлы libgd.* и gd.h. #find / -name libgd.*
#find / -name gd.h
Теперь вы можете уверенно сказать, чему должны быть равны параметры --with-gd-lib и --with-gd-inc команды configure. Выполняем ее со всеми необходимыми настройками и, как описано выше, проверяем, найдена ли библиотека GD. И наконец, проводим компиляцию и инсталляцию, не забыв остановить демона Nagios. После этого карта сети (statusmap.cgi) должна приобрести вид, примерно похожий на этот:
Теперь все те, кто ушли пить кофе, могут возвращаться. Сейчас мы начнем починку 3D-карты. Не работает она по причине того, что ваш браузер не знает, что делать с vrml-файлом, который возвращается в ответ на запросы к скрипту statuswrl.cgi. Для того чтобы все заработало как положено, нужно установить в используемый браузер модуль для работы с vrml или отдельную программу, предназначенную для тех же целей. Программного обеспечения, подходящего для этого, написано воз и маленькая тележка. Как обычно, пальма первенства по количеству экземпляров принадлежит Windows. Затем идет MAC OS и, наконец, бронзовое третье место занимает Linux. Итак, начнем с фаворита. При необходимости работать под управлением Windows и MAC-систем я предпочитаю использовать Cortona VRML Client по той простой причине, что он совместим с большинством наиболее распространенных браузеров, к числу которых несомненно относятся Internet Explorer, Netscape Navigator, Mozilla, iCab. Интересным фактом является то обстоятельство, что этот подключаемый модуль можно использовать даже из офисных приложений Microsoft PowerPoint, Microsoft Word. К сожалению, разработчики Cortona почему-то решили полностью проигнорировать Linux. Скачать дистрибутив можно с сайта http://www.parallelgraphics.com/products/cortona/download. Что делать после совершения этого сакраментального действа, мы обсудим немного позднее. Следующая достойная нашего внимания программа, называемая Cosmo player, живет по адресу: http://ca.com/cosmo/html. Работает в виде отдельного приложения и, конечно же, только под Windows и MAC. ExpressVR – конкурент Cortona для всем известной яблочной платформы. Под другими операционными системами не живет, попыток экспансии не предпринимает и, судя по последним тенденциям, скорее всего через некоторое время будет окончательно вытеснен своим многофункциональным противником. Предназначен только для Netscape Navigator и Internet Explorer. Скачать дистрибутив можно отсюда: http://members.aol.com/maxmac/vrml/download.html. FreeWRL – отдельное приложение, работающее в качестве самостоятельного vrml-браузера. Функционирует на платформах Linix и MAC и располагается по этому адресу: http://www.crc.ca/FreeWRL. Следующий экземпляр в нашем списке называется VRwave и проживает тут: http://www.iicm.edu/vrwave. Предназначен для Linux и Windows. Замыкает стройные ряды vrml-клиентов OpenVrml, обитающий сугубо под Linux: http://sourceforge.net/project/showfiles.php?group_id=7151 &release_id=192066. Кстати, стоит сделать маленькую ремарку по ходу изложения. Практически все программы, которые мы назвали предназначенными под Linux, теоретически должны работать и под другими Unix-подобными системами, в состав которых входит графический сервер X11. На самом деле программ, подходящих для наших целей, гораздо больше, чем вы могли бы подумать. Я постарался упомянуть лишь наиболее известные из них. Если же вы хотите непременно огласить весь список, то вам нужно провести поиск по слову vrml на следующих серверах, в народе ласково называемых софтомогильниками: А здесь: http://www.chuvsu.ru/download/vrml/browsers можно найти очень неплохую подборку vrml-клиентов для Windows. Надеюсь, что среди подобного разнообразия вы сможете самостоятельно подобрать себе инструмент по вкусу. Теперь сделаем перерыв в изучении теории и попрактикуемся в том, как правильно провести инсталляцию и использование Cortona VRML Client в связке с браузером Microsoft Internet Explorer. Сделать это можно двумя способами. Начнем с самого простого. С помощью браузера идем по адресу: http://www.parallelgraphics.com/products/cortona/download и, выбрав нужный тип браузера, пользуемся кнопкой «online install».
Обратите внимание на пустой прямоугольник в центре страницы. Его появление означает, что в вашем браузере нет vrml-модуля. Нажимаем на кнопку «Install Now». После того как процесс скачивания закончится, перед нами появится следующее окно:
Жмем «Yes» в знак того, что мы доверяем цифровой подписи ParallelGraphics LTD. Подобный механизм цифровых подписей для всех скачиваемых программ помогает избежать подмены или порчи дистрибутива во время его путешествия через сеть. На следующем экране выставляем во всех окошках галочки. Таким образом, мы назначаем vrml-клиента программой по умолчанию для обработки файлов wrl, wrml и wrz.
По окончании инсталляции текущая страница в браузере должна обновиться. И в центре нее появится вращающийся куб.
На этом первый способ инсталляции можно считать оконченным. Если в процессе выполнения этих инструкций что-то пошло не так, как должно было, и установка завершилась неудачно, то огорчаться не стоит. Можно выполнить все требуемые действия вручную. Итак, переходим ко второму способу инсталляции. Скачиваем дистрибутив, подходящий для нашего браузера. После запуска принимаем лицензионное соглашение и несколько раз жмем кнопку «Next». После распаковки файлов на экране должно появиться что-то вроде такой картинки:
Система может задуматься на минуту-другую, а затем снова очнется и начнет задавать вопросы.
Требуется уточнить, каким образом мы будем отрисовывать vrml-сцены. Выбирайте один из пунктов в зависимости от программного обеспечения, установленного в вашей системе. Если вы ошибетесь, и у вас нет выбранного компонента, то ничего страшного не произойдет. Система самостоятельно переключит отрисовку в программный режим.
Лично я – человек ленивый, и не люблю читать readme-файлы без нужды, поэтому на следующем экране отключаю такую возможность. А вот во втором окошке галочку лучше оставить нетронутой, потому что это позволит нам проверить, правильно ли работает vrml. Вслед за нажатием кнопки «Next» на экране появится 3D-сцена, изображающая постепенно расцветающую розу.
Если нам не удалось правильно угадать нужный режим отрисовки, то рядом откроется окно консоли с соответствующим сообщением.
Для того чтобы избавиться от этой надоедливой помехи, закрываем окно консоли и щелкаем правой клавишей мыши в середине окна с 3D-сценой.
В открывшемся меню выберем пункт «Preferences». А затем, воспользовавшись вкладкой «Render», выбираем альтернативный механизм рендеринга.
Думаю, вы сможете легко самостоятельно разобраться с настройками и изучить способы перемещения в трехмерном виртуальном пространстве. Теперь можно посмотреть на 3D-карту Nagios.
Выглядит она пока не так уж и красиво, но дайте время, и все еще изменится к лучшему. А теперь вновь одним прыжком вернемся к плоской карте сети statusmap.cgi. Для наглядности давайте представим, что наша система мониторинга наблюдает за сетью, изображенной на следующем рисунке:
У нас есть две отдельные подсети, созданные на основе управляемых коммутаторов 3com. Каждому из них выдан собственный IP-адрес. Таким образом, мы имеем возможность проверять их работоспособность с помощью подключаемого модуля check_ping. Внутренняя сеть включает в себя следующие компьютеры:
Вторая сеть у нас используется как демилитаризованная зона. В нее включены серверы c именами WWW и Mail. Думаю, названия говорят сами за себя, и поэтому неудивительно, что на них запущены сервисы IMAP, POP3, SMTP и HTTP. Между собой сети соединены с помощью машины, фигурирующей под именем Inner_Firewall. Выход в Интернет защищает аппаратный межсетевой экран, называемый Outer_Firewall. В файле 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 } define host{ use generic-host host_name Win_2000 alias Standard Windows Server address bianca parents 3com_Lan check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name Linux alias Linux Server address lira parents 3com_Lan check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name 3com_Lan alias 3COM inner Lan switch address 3com-lan check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name Inner_Firewall alias Firewall PC parents 3com_Lan address inner-firewall check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name 3com_Dmz alias 3COM dmz switch address 3com-dmz parents Inner_Firewall check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name Mail alias Mail Server address mailer parents 3com_Dmz check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name WWW alias WWW Server address web parents 3com_Dmz check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } define host{ use generic-host host_name Outer_Firewall alias Hardware Firewall address outer-firewall parents 3com_Dmz check_command check-host-alive max_check_attempts 10 notification_interval 120 notification_period 24x7 notification_options d,u,r } Я думаю, что цитировать файл services.cfg с описанием сервисов нужды нет, потому что в нем нет ничего интересного, да и для повествования он некритичен, кроме того, каждый из вас может заполнить его нужными сведениями за пять минут. Если же у кого-то из читателей это действо вызывает затруднение, то тогда им прямая дорога в первую статью о Nagios. Прочитать ее можно в [1] либо на моем сайте: http://www.onix.opennet.ru. К сожалению, Nagios пока не умеет строить карту сети, более или менее приближенную к реальному расположению наблюдаемых объектов внутри нее. Несмотря на то что у нас есть две подсети на карте, все машины отображаются так, как будто они находятся в одном и том же сетевом облаке, то есть все свалено в одну кучу. С одной стороны, это упрощает процедуру рисования карты, но с другой – усложняет жизнь администратора. Представьте себе ситуацию, когда из строя выходит машина Inner_Firewall. При следующем цикле выполнения проверок нас засыпет лавина уведомлений о критическом состоянии хостов Inner_Firewall, WWW, Mail, 3com_Dmz и Outer_Firewall. Хотя на самом деле не работает только первый из всех вышеперечисленных компьютеров. Получается, что администратор должен самостоятельно догадаться, что привело к таким массовым сбоям. Для того чтобы впредь избежать подобных неприятностей, нам необходимо объяснить Nagios, как построена наша сеть и каким образом добираться до ее самых удаленных уголков. Делается это с помощью создания отношений «родитель» – «потомок» между всеми нашими хостами. После таких изменений критические уведомления будут приходить только для компьютера Inner_Firewall, все остальные машины, задействованные в данной проблеме, получат статус «недоступно». Согласитесь, это все-таки более соответствует действительному положению вещей в контролируемых сетях. Прародителем всех компьютеров считается машина, на которой работает процесс системы мониторинга. И уже от него строится цепочка.
Для правильной диагностики неполадок иерархия должна выглядеть так, как изображено на предыдущей схеме. С точки зрения Nagios бывают два вида хостов – «локальные» и «удаленные». Локальными считаются те, кто находится в том же сетевом сегменте, что и система мониторинга. Между ними не должно быть ни маршрутизаторов, ни межсетевых экранов. Если бы у нас были неуправляемые коммутаторы, не поддающиеся мониторингу, то локальными хостами считались бы Linux и Win_2000. Но в связи с тем, что между ними есть промежуточное звено в виде коммутатора 3com_Lan, который можно подвергнуть мониторингу, они переходят в разряд удаленных. А единственным локальным становится 3com_Lan. Добиться этого можно применением тега parents в определении хостов. Стоит обратить внимание на тот странный факт, что фирменная документация в разделе «Determining Status and Reachability of Network Hosts» этот тег почему-то называет parent_hosts. Хотя если покопаться в исходных текстах Nagios, то понимаем, что на самом деле должен быть просто parents. Если в описании хостов неукоснительно придерживаться указания использовать тег parent_host, то при попытке сделать nagios reload для того, чтобы применить изменения в конфигурации, получим вот такие ошибки:
Ошибка будет именно на той строке, где впервые появляется тег parent_host. Думаю, других доказательств не нужно. Машины, считающиеся локальными по отношению к Nagios, находятся на одну ступеньку ниже в иерархии, и поэтому не должны использовать тег parents в своем описании. Все остальные машины, относящиеся к группе удаленных, в вышеуказанном теге пишут имя ближайшего родителя. Таким образом, для хостов Inner_Firewall, Linux и Win_2000 родителем является 3com_Lan. В свою очередь, Inner_Firewall указан родителем для 3com_Dmz. А 3com_Dmz выполняет ту же роль для хостов WWW, Outer_Firewall, Mail. Итак, разобравшись с понятием иерархии, посмотрим, как оно влияет на отображение наших сетей на карте.
Думаю, выглядит довольно впечатляюще. Какой из способов отображения карты будет использоваться по умолчанию, указывает параметр default_statusmap_layout. Для трехмерной карты такой параметр называется соответственно default_statuswrl_layout. Оба этих параметра скрываются внутри файла cgi.cfg. Кроме заметного с первого взгляда лоска, мы к тому же приобрели более точное диагностирование сетевых неполадок. Все это, конечно, хорошо, но душа требует чего-то более красивого. Также хотелось бы уметь самостоятельно указывать расположение тех или иных объектов на картах. Такая задача нам по плечу, и сейчас вы научитесь управлять важнейшими параметрами отрисовки сетевых карт. Для начала мы раздадим каждому хосту и сервису по красивой иконке, а затем расположим их так, чтобы они максимально совпадали с нашим рисунком, основываясь на котором мы описывали содержимое наших сетей. Тут нам на помощь приходят два новых файла. Первый из них, hostextinfo.cfg, отвечает за добавочные атрибуты хостов, а второй, serviceextinfo.cfg, выполняет ту же функцию для сервисов. Кстати, не забудьте скачать отсюда: http://nagios.org/download/extras.html файлы с коллекциями иконок, обычно называемые image packs. Итак, начнем с файла hostextinfo.cfg. define hostextinfo{ # Тег, с которого должно начинаться описание хоста host_name 3com_Lan # Имя хоста, к которому относится описание icon_image 3Com.png # Имя файла иконки, которая будет отображаться рядом с именем хоста. Иконка может быть в формате GIF, PNG или JPG. # Может содержать внутри себя прозрачные области. Желательно, чтобы иконки были размером 40x40 пикселей. # Располагаться они должны в директории logos. Обычно эта директория находится в /usr/local/nagios/share/images/logos icon_image_alt 3Com LAN Switch # Надпись, отображаемая, если веб-серверу не удается загрузить иконку vrml_image 3Com.png # Имя файла, который будет использоваться как текстура для куба, изображающего хост на трехмерной карте. Может быть # в формате PNG, JPG, GIF. Картинка не должна содержать прозрачных областей, иначе это будет выглядеть очень странно. # Должна храниться в той же директории, что и иконка, описанная тегом icon_image statusmap_image 3Com.gd2 # Имя файла, где хранится изображение, которое будет использоваться как иконка хоста на плоской сетевой карте. # Может быть в формате PNG, JPG, GIF, но все-таки лучше, если для этого файла будет использоваться формат GD2, # потому что для каждого цикла рисования карты иконка будет снова и снова приводиться к виду, удобному для библиотеки GD. # А это значит, что мы будем зря выполнять одни и те же бесполезные вычисления. Может содержать внутри себя прозрачные # области. Желательно чтобы иконки были размером 40x40 пикселей. Располагаться они должны в директории logos. # Обычно эта директория находится в /usr/local/nagios/share/images/logos 2d_coords 160,99 # Двумерные координаты точки, в которой будет находиться центр иконки хоста на плоской карте. Могут быть только # положительными числами. Рисование карты начинается из точки 0,0 которая является верхним левым углом карты. # Координаты перечисляются в следующем порядке x, y 3d_coords 20.0,32.0,6.0 # Координаты центра куба, символизирующего хост в пространстве трехмерной карты. Могут быть как положительными, # так и отрицательными числами. Размер одной стороны куба 0.5 единиц. Отрисовка карты начинается центра трехмерной карты, # который находится в точке с координатами 0.0, 0.0, 0.0. Координаты перечисляются в следующем порядке x, y, z notes_url http://192.168.80.2/nagios/notes/3com_lan.txt # Ссылка на адрес, по которому лежит файл c дополнительными сведениями о хосте. При щелчке на специальный значок # в браузере будет открыт этот файл. Это полезно для записи различных сведений, которые не вошли в стандартный шаблон # описания хоста Nagios. Например, там можно написать данные, отвечающие на вопрос, кто из администраторов отвечает # за управление этим сервером, к кому обращаться в случае проблем. Обратите внимание на URL, используемый для указания путь # к файлу. Для того чтобы файлы с записками можно было хранить на том же хосте, что и Nagios, я создал директорию # /usr/local/nagios/share/notes, и поэтому мы теперь можем получить к ней доступ именно по такому URL. } define hostextinfo{ host_name Win_2000 notes_url http://listios.lan.domain.ru/Win_2000.html # Кстати, стоит отметить, что добавочные записки о хостах могут хранить не только на том же хосте, где работает Nagios, # но и на любом другом. Главное, чтобы там работал веб-сервер и URL был правильно прописан icon_image win40.png icon_image_alt Windows workstation vrml_image win40.png statusmap_image win40.gd2 2d_coords 163,195 3d_coords 15.0,38.0,6.0 } define hostextinfo{ host_name Linux notes_url http://10.10.5.7/hostinfo.pl?host=Linux1 # В качестве URL для хранения добавочных записок можно использовать даже CGI. В зависимости от данных, переданных в запросе, # вы будете получать сведения о том или ином хосте. icon_image_alt Linux Workstation vrml_image mandrake.gd2 statusmap_image mandrake.gd2 2d_coords 60,198 3d_coords 30.0,38.0,6.0 } define hostextinfo{ host_name Mail notes_url http://192.168.80.2/nagios/notes/mail.html icon_image MailServer.png icon_image_alt Mail Server vrml_image MailServer.png statusmap_image MailServer.gd2 2d_coords 520,183 3d_coords 20.0,44.0,6.0 } define hostextinfo{ host_name WWW notes_url http://192.168.80.2/nagios/notes/www_notes.html icon_image openbsd.png icon_image_alt WWW Server vrml_image openbsd.gd2 statusmap_image openbsd.gd2 2d_coords 439,186 3d_coords 20.0,54.0,6.0 } define hostextinfo{ host_name Inner_Firewall notes_url http://192.168.80.2/nagios/notes/inner_fw_notes.html icon_image freebsd40.png icon_image_alt Inner Firewall vrml_image freebsd40.png statusmap_image freebsd40.gd2 2d_coords 326,96 3d_coords 17.0,55.0,6.0 } define hostextinfo{ host_name Outer_Firewall notes_url http://192.168.80.2/nagios/notes/outer_fw_notes.html icon_image firebox_small.png icon_image_alt Outer Firewall vrml_image firebox_small.png statusmap_image firebox_small.gd2 2d_coords 620,80 3d_coords 16.0,42.0,6.0 } define hostextinfo{ host_name 3com_Dmz notes_url http://192.168.80.2/nagios/notes/3com_dmz.html icon_image 3Com.png icon_image_alt 3Com DMZ LAN Switch vrml_image 3Com.png statusmap_image 3Com.gd2 2d_coords 480,73 3d_coords 14.0,56.0,6.0 } Теперь пришло самое время обсудить содержимое файла serviceextinfo.cfg. Принципы построения обоих файлов довольно схожи. define serviceextinfo{ host_name WWW # Имя хоста, на котором работает сервис service_description HTTP # Имя сервиса из файла services.cfg notes_url http://192.168.80.2/nagios/notes/service_www.html # Уже многократно виденный нами URL для дополнительных записок icon_image apache.png # Имя файла иконки, которая будет отображаться рядом с именем сервиса. Иконка может быть в формате GIF, PNG или JPG. # Может содержать внутри себя прозрачные области. Желательно, чтобы иконки были размером 40x40 пикселей. Располагаться # они должны в директории logos. Обычно эта директория находится в /usr/local/nagios/share/images/logos icon_image_alt Web Service # Надпись, отображаемая, если веб-серверу не удается загрузить иконку, привязанную к сервису } define serviceextinfo{ host_name WWW service_description SMTP notes_url http://192.168.80.2/nagios/notes/service_www.html icon_image apache.png icon_image_alt Web Service } define serviceextinfo{ host_name Mail service_description SMTP notes_url http://192.168.80.2/nagios/notes/service_smtp.html icon_image smtp.png icon_image_alt Web Service } define serviceextinfo{ host_name Mail service_description POP3 notes_url http://192.168.80.2/nagios/notes/service_pop3.html icon_image pop3_imap.png icon_image_alt Web Service } define serviceextinfo{ host_name Mail service_description IMAP notes_url http://192.168.80.2/nagios/notes/service_imap.html icon_image pop3_imap.png icon_image_alt Web Service } Для того чтобы Nagios увидел созданные нами файлы hostextinfo.cfg, serviceextinfo.cfg, нужно внести в файл cgi.cfg следующие директивы. xedtemplate_config_file=/usr/local/nagios/etc/hostextinfo.cfg xedtemplate_config_file=/usr/local/nagios/etc/serviceextinfo.cfg Я думаю, вы сможете самостоятельно положить файлы иконок в директорию /usr/local/nagios/share/images/logos/. Кстати, стоит обязательно убедиться, что все файлы, создаваемые вами, принадлежат пользователю, от имени которого работает Nagios, иначе вы будете очень долго недоумевать, почему никаких изменений в картах не видно, хотя все сделано так, как в этой статье. К таким файлам относятся hostextinfo.cfg serviceextinfo.cfg иконки, записки и прочая мелкая живность. Кстати, создавать самостоятельно файлы иконок в формате библиотеки GD довольно просто. Мы говорили об этих файлах во время обсуждения тега statusmap_image файла hostextinfo.cfg. Для этого нужно взять файлы иконки в формате png и преобразовать его в формат GD с помощью утилиты pngtogd2, поставлявшейся вместе с библиотекой GD. Желательно, чтобы создаваемый файл был сохранен без компрессии изображения. Это позволит увеличить скорость работы функций библиотеки GD, отвечающих за загрузку в память и рисование иконок внутри интерфейса Nagios. Если данные внутри файла не сжаты, значит, не нужно тратить время на их распаковку. Учитывая малый размер наших картинок, сжатие не принесет никакой выгоды. Например, для конвертации файла www.png в www.gd2 нужно подать следующую команду: $ /usr/local/bin/png2gd2 www.png www.gd2 4000 1 Я думаю, с первыми двумя параметрами все ясно. Третий указывает размер порции кодирования, и четвертый – наличие компрессии. После некоторого количества наблюдений замечено, что в качестве размера порции кодирования можно писать какое угодно число. Для исходных файлов малого размера, к которым относятся и наши иконки, этот параметр смысла не имеет. И не забудьте подать процессу nagios команду «reload», которая заставит его обновить конфигурацию. Во FreeBSD это обычно делается так: /usr/local/etc/rc.d/nagios.sh reload. Если есть желание, можно нарисовать свои собственные иконки и использовать их вместо стандартных. Я именно так поступил с сервисами HTTP, SMTP, POP3 и IMAP. Для HTTP использовалось перо, потерянное индейцем Apache, а для всех остальных изображение открытого и закрытого почтового конверта. И хотя картинки получились размером чуть более, чем 40x40 пикселей, Nagios работал с ними довольно хорошо. Полюбоваться на результат можно на следующей картинке.
Теперь у каждого хоста и сервиса есть не только личная иконка, но и на страничке с подробной информацией о каждом из них возникло вот такое изображение.
Если нажать на него, то можно почитать дополнительные сведения из файла, который мы описали тегом notes_url. Координаты точек, в которых должны рисоваться иконки и объекты наших хостов на плоской и трехмерной картах сети, не будут использоваться Nagios до тех пор, пока мы не выставим вот таким образом значения тегов default_statusmap_layout и default_statuswrl_layout в файле cgi.cfg. default_statusmap_layout=0 default_statuswrl_layout=0 Если вы все сделали правильно, то плоская карта сети будет выглядеть вот так:
Впечатляет, не правда ли?
Трехмерная карта выглядит тоже довольно хорошо. И самое приятное в этом то, что в трехмерное пространство можно добавить, например, подробный макет здания, в котором эта сеть находится, и поставить сервера в нужных помещениях. Но об этом мы поговорим в другой статье. Ну а если вместо вожделенной карты на экране появилась следующая надпись:
Значит, вы что-то напутали с тегами координат отрисовки. Еще одной из полезных возможностей, которую мы сегодня изучим, будет умение добавлять в страницы, создаваемые Nagios, свои вставки и заголовки. Каждая страница может иметь два заголовка и две вставки. Обычно таким образом в текст страницы можно вставлять корпоративную символику, справочные телефоны и прочие сведения, относящиеся к выбранной странице.
Все заголовки страниц и вставки делятся на глобальные и локальные. Глобальные действуют на все страницы cgi, а локальные только на те, для которых они были определены. Тексты, записанные в файлах заголовков и разрывов страниц, вставляются в начало и конец тега страницы, создаваемой cgi. Обычно текст страницы после обработки выглядит так: <BODY> глобальный заголовок локальный заголовок первоначальный текст глобальная вставка локальная вставка </BODY> Давайте посмотрим, что нужно сделать для того, чтобы это работало на примере файла status.cgi. В директории /usr/local/nagios/share/ssi нужно создать следующие файлы:
Я думаю, все уже сообразили, что имя для файлов локального заголовка и локальной вставки образуется с помощью сращивания имени подопытного файла cgi с надписями -footer.ssi и -header.ssi. Нужно помнить, что содержимое всех вышеперечисленных файлов перед добавлением в целевой файл никак не обрабатывается, то есть создать динамические заголовки и вставки без безумных ухищрений не получится, потому что нет возможности использовать в качестве генератора данных cgi или что-либо другое. Получается, что включаемые файлы должны содержать в себе только чистый html. Давайте рассмотрим содержимое всех файлов, применявшихся в этом примере: Файл common-footer.ssi <p> <center> <h2> По вопросам техподдержки обращаться на tigrisha@sysadmins.ru или <a href="http://onix.opennet.ru">http://onix.opennet.ru</a> </h2> </center> </p> Файл common-header.ssi <p> <center> <img src="../images/onix.png" border="0" alt="Nagios"> </center> </p> Файл status-footer.ssi <p> <center> <h2> Разделитель страницы status.cgi</h2> </center> </p> Файл status-header.ssi <p> <center> <h2>Тестовый заголовок status.cgi</h2> </center> </p> Как вы могли убедиться, все это работает довольно просто. Еще одной вкусностью, которой я с вами поделюсь, будет способность привязывать проигрывание звуковых файлов к определенным событиям. Например, моя система мониторинга при умирании какого-либо сервиса начинает изображать жалобно мычащую корову. Такая возможность очень полезна для администраторов, которые не хотят постоянно смотреть на веб-интерфейс Nagios или ежеминутно проверять свой почтовый ящик на предмет уведомлений о проблемах. Нужно всего лишь открыть в браузере или прикрепить на Active Desktop одну из этих страниц tac.cgi, status.cgi. После этого можно минимизировать браузер и заниматься своими делами. Как только случится какое-либо интересующее нас событие, Nagios начнет воспроизводить звук, связанный с ним. Для осуществления наших желаний есть следующие теги:
Опцию normal_sound практически никто не использует. Но на всякий случай я решил ее упомянуть. Для того чтобы звуковое оповещение заработало, нужно поместить файлы звуков в формате wav внутрь директории /usr/local/nagios/share/media/, как всегда, не забыть о правах пользователя и принадлежности файлов. А затем добавить следующие записи в файл cgi.cfg. host_unreachable_sound=hostunreachable.wav host_down_sound=host down.wav service_critical_sound=servicecritical.wav service_warning_sound=servicewarning.wav service_unknown_sound=service unknown.wav normal_sound=noproblem.wav В случае если в процессе мониторинга будет обнаружено одновременно несколько проблем, Nagios начнет проигрывать звук для наиболее критичной из них. После десятка или двух повторений одного и того же звука вам, наверное, захочется отключить звук. Сделать это довольно легко: нужно просто войти в режим управления сервисом или хостом и подать команду подтверждения проблемы.
После подобной обработки записи в таблице сервисов или хостов примут вот такой вид:
Я думаю, на сегодня хватит грызть гранит науки, и пора дать мозгам отдохнуть. Позволю себе попрощаться с вами в эту радостную минуту. Литература:
|
АНДРЕЙ БЕШКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
