Содержание ВступлениеПройдя парадным маршем через установку, настройку и примеры успешного использования Nagios в реальной жизни, мы завоевали для себя довольно просторное место под солнцем. После предыдущих статей у читателей накопилось некоторое количество вопросов. Это значит, что, несмотря на все былые успехи, пришло время прекратить расширять свои владения и перейти на интенсивный путь развития. Слегка замедлим свой бег вперед и займемся благоустройством захваченного пространства. Как обычно, в начале статьи хотелось бы упомянуть то обстоятельство, что описываемые действия выполнялись на хосте, работающем под управлением FreeBSD 4.8. Однако переживать по это поводу не стоит, так как все обсуждаемые приемы будут отлично работать с любым дистрибутивом Unix-подобных операционных систем, для которых существует версия Nagios. Единственным щекотливым моментом может быть различие в именах директорий, где расположились Nagios и остальное вспомогательное программное обеспечение, необходимое для нашей работы. Надеюсь, с этим мелкими проблемами вы сможете разобраться самостоятельно. Первым делом хотелось бы научить Nagios говорить на чистом русском языке. Как всегда, вспоминаем, что в этом мире нет ничего невозможного. Примерно девять месяцев назад я завершил работы по локализации Nagios версии 1.06 beta. Затем, по мере выхода новых версий продукта, та же судьба постигла официальные релизы 1.0 и 1.1. Методика русификация для всех версий одинакова, поэтому я буду описывать ее на примере версии 1.1, как наиболее свежей и, надеюсь, наиболее распространенной. Плюс ко всему, именно эта версия установлена у меня. Русификация NagiosИтак, что же нам нужно сделать для того чтобы Nagios заговорил по русски? Первым делом скачиваем дистрибутив версии Nagios, которая установлена у вас с официального сайта http://www.nagios.org. Затем здесь htpp://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 смысла нет. Поэтому сразу же переходим к компиляции. # make all После того, как этот процесс завершится успешно, останавливаем демона Nagios. Все-таки резать по живому не очень хорошо, и подобные действия могут вызвать разнообразные сбои в функционировании системы мониторинга. # /usr/local/etc/nagios.sh stop Вот теперь можно спокойно выполнять инсталляцию. # make install В результате файлы из директории дистрибутива должны заменить те файлы, которые Nagios использовал до сегодняшнего дня. Таким образом, файлы из /tmp/nagios-1.1/html должны попасть в /usr/local/nagios/share/, а скомпилированные файлы из /tmp/nagios-1.1/cgi в /usr/local/nagios/sbin/. Снова запустив Nagios и обратившись к Web-интерфейсу, должны увидеть что-то вроде такой картинки. 
Судя по всему, русификация прошла без сучка-без задоринки. Чиним 3D карту сетиСледующая проблема, нуждающаяся в исправлении - неработающая карта сети. При попытке воспользоваться пунктами "Карта сети" (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 среди всего прочего будут вот такие надписи: checking for gdImagePng in -lgd (order 1)... no checking for gdImagePng in -lgd (order 2)... no checking for gdImagePng in -lgd (order 3)... no *** GD, PNG, and/or JPEG libraries could not be located... ********* Boutell's GD library is required to compile the statusmap, trends and histogram CGIs. Get it from http://www.boutell.com/gd/, compile it, and use the --with-gd-lib and --with-gd-inc arguments to specify the locations of the GD library and include files. NOTE: In addition to the gd-devel library, you'll also need to make sure you have the png-devel and jpeg-devel libraries installed on your system. NOTE: After you install the necessary libraries on your system: 1. Make sure /etc/ld.so.conf has an entry for the directory in which the GD, PNG, and JPEG libraries are installed. 2. Run 'ldconfig' to update the run-time linker options. 3. Run 'make clean' in the Nagios distribution to clean out any old references to your previous compile. 4. Rerun the configure script. NOTE: If you can't get the configure script to recognize the GD libs on your system, get over it and move on to other things. The CGIs that use the GD libs are just a small part of the entire Nagios package. Get everything else working first and then revisit the problem. Make sure to check the nagios-users mailing list archives for possible solutions to GD library problems when you resume your troubleshooting. ******************************************************************** Ну а в случае, если вам повезло и вы нашли в указанном выше файле вот такое: checking for gdImagePng in -lgd (order 1)... yes GD library was found! Значит с GD у вас все в порядке, и вы можете спокойно пойти попить кофе, пока я расскажу остальным, как избавиться от проблем с этой неуловимой библиотекой. По традиции начинаем с FreeBSD. Посмотреть, устанавливалась ли библиотека GD в эту систему стандартными средствами, то есть с помощью пакетов или портов, можно командой: # pkg_info | grep gd gd-1.8.4_6 A graphics library for fast image creation Теперь мы знаем полное название пакета. Смотрим куда, установились его файлы. # pkg_-L gd-1.8.4_6 Information for gd-1.8.4_6: Files: /usr/local/bin/bdftogd /usr/local/bin/gd2copypal /usr/local/bin/gd2topng /usr/local/bin/gdparttopng /usr/local/bin/gdtopng /usr/local/bin/pngtogd /usr/local/bin/pngtogd2 /usr/local/bin/webpng /usr/local/include/gd/gd.h /usr/local/include/gd/gd_io.h /usr/local/include/gd/gdcache.h /usr/local/include/gd/gdfontg.h /usr/local/include/gd/gdfontl.h /usr/local/include/gd/gdfontmb.h /usr/local/include/gd/gdfonts.h /usr/local/include/gd/gdfontt.h /usr/local/lib/libgd.a /usr/local/lib/libgd.so /usr/local/lib/libgd.so.2 /usr/local/share/doc/gd/index.html Итак, судя по выводу, параметры команды configure, относящиеся к библиотке GD, должны выглядеть так --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include/gd. Давайте посмотрим, как можно добиться подобного эффекта для Linux-систем, основанных на rpm. В качестве примера возьмем ALT Linux. # rpm -qa | grep gd libgd2-devel-2.0.4-alt2 gdm-2.4.4.5-alt1 gdk-pixbuf-loaders-0.22.0-alt2 gdk-pixbuf-0.22.0-alt2 libgd2-2.0.4-alt2 libgda2-1.0.0-alt1 gnome2-utils-gdict-applet-2.4.0-alt2 libgda2-devel-1.0.0-alt1 В отличие от FreeBSD, в Linux системах библиотека GD обычно разделена на два отдельных пакета. Судя по всему, нас интересуют rpm файлы libgd2 и libgd2-devel. Первый содержит динамически загружаемые библиотеки, ну а второй, соответственно, заголовочные файлы. # rpm -ql libgd2 /usr/lib/libgd.so.2 /usr/lib/libgd.so.2.0.4 # rpm -ql libgd2-devel /usr/include/gd.h /usr/include/gd_io.h /usr/include/gdcache.h /usr/include/gdfontg.h /usr/include/gdfontl.h /usr/include/gdfontmb.h /usr/include/gdfonts.h /usr/include/gdfontt.h /usr/lib/libgd.so /usr/share/doc/gd-2.0.4 /usr/share/doc/gd-2.0.4/index.html Ну и наконец, универсальный способ, подходящий для любой Unix-подобной операционной системы. Им можно воспользоваться в случае, если все предыдущие попытки не дали никаких результатов. Нужно самостоятельно отыскать, где находятся файлы libgd.* и gd.h #find / -name libgd.* /usr/lib/libgd.so.1.2 /usr/lib/libgd.so.1 /usr/lib/libgd.so #find / -name gd.h /usr/include/gd.h Теперь вы можете уверенно сказать, чему должны быть равны параметры --with-gd-lib и --with-gd-inc команды configure. Выполняем ее со всеми необходимыми настройками и, как описано выше, проверяем, найдена ли библиотека GD. Ну и наконец, проводим компиляцию и инсталляцию, не забыв остановить демона Nagios. После этого карта сети (statusmap.cgi) должна приобрести вид, примерно похожий на этот: 
Теперь все те, кто ушли пить кофе, могут возвращаться. Сейчас мы начнем починку 3D карты. Не работает она по причине того, что ваш браузер не знает, что делать с vrml файлом, который возвращается в ответ на запросы к скрипту statuswrl.cgi. Для того, чтобы все заработало как положено, нужно установить в используемый браузер модуль для работы с vrml, или отдельную программу, предназначенную для тех же целей. Выбор средства просмотра VRMLПрограммного обеспечения, подходящего работы с VRML (Virtual Reality Modeling Language), написано воз и маленькая тележка. Как обычно, пальма первенства по количеству экземпляров принадлежит 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/. На самом деле, программ, подходящих для наших целей, гораздо больше, чем вы могли бы подумать. Я постарался упомянуть лишь наиболее известные из них. Если же вы хотите непременно огласить весь список, то вам нужно провести поиск по слову 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. Прочитать ее можно так же в старых номерах журнала "Системный администратор". К сожалению, 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 для того, чтобы применить изменения в конфигурации, получим вот такие ошибки: Running configuration check... Nagios 1.1 Copyright (c) 1999-2003 Ethan Galstad (nagios@nagios.org) Last Modified: 06-02-2003 License: GPL Reading configuration data... Error: Could not add object property in file '/usr/local/nagios/etc/hosts.cfg' on line 74. ***> One or more problems was encountered while processing the config files... Check your configuration file(s) to ensure that they contain valid directives and data defintions. If you are upgrading from a previous version of Nagios, you should be aware that some variables/definitions may have been removed or modified in this version. Make sure to read the HTML documentation on the main and host config files, as well as the 'Whats New' section to find out what has changed. failed - aborting 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
# Надпись, отображаемая, если web-серверу не удается загрузить иконку
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, но и на любом другом.
# Главное, чтобы там работал web-сервер и 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
# Надпись, отображаемая, если web-серверу не удается загрузить иконку привязанную,
# к сервису
}
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 Если все сделали правильно, то плоская карта сети будет выглядеть вот так. Впечатляет, не правда ли? 
Трехмерная карта выглядит тоже довольно хорошо. И самое приятное в этом то, что в трехмерное пространство можно добавить, например, подробный макет здания, в котором эта сеть находится, и поставить сервера в нужных помещениях. Но об этом мы поговорим в другой статье. 
Ну а если вместо вожделенной карты на экране появилась следующая надпись: You have not supplied any host drawing coordinates, so you cannot use this layout method. Read the FAQs for more information on specifying drawing coordinates or select a different layout method. Значит, вы что-то напутали с тегами координат отрисовки. Еще одной из полезных возможностей, которую мы сегодня изучим, будет умение добавлять в страницы, создаваемые Nagios, свои вставки и заголовки. Настройка заголовков страницКаждая страница может иметь два добавочных заголовка и две вставки определяемых пользователем. Обычно таким образом в текст страницы можно вставлять корпоративную символику, справочные телефоны, данные о наблюдаемом объекте и прочие сведения, относящиеся к выбранной странице. Все заголовки страниц и вставки делятся на глобальные и локальные. Глобальные действуют на все страницы cgi, а локальные только на те, для которых они были определены. Тексты, записанные в файлах заголовков и разрывов страниц, вставляются в начало и конец тега страницы, создаваемой cgi. Обычно текст страницы после обработки выглядит так:глобальный заголовок локальный заголовок основной текст страницы Nagios глобальная вставка локальная вставка Давайте посмотрим, что нужно сделать для того, чтобы это работало на примере файла status.cgi. В директории /usr/local/nagios/share/ssi нужно создать следующие файлы common-footer.ssi - файл глобального заголовка common-header.ssi - файл глобальной вставки status-footer.ssi - файл локального заголовка status-header.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
|
|||
 |
LinuxShareКто владеет информацией - владеет всем! Документация по Linux! |
|
|
|
|
