Осваиваем Nagios::Журнал СА 12.2003
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 2249
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2226
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1784
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1309
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1840
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Осваиваем Nagios

Архив номеров / 2003 / Выпуск №12 (13) / Осваиваем 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 и обратившись к веб-интерфейсу, должны увидеть что-то вроде такой картинки:

Рисунок 1

Судя по всему, русификация прошла без сучка без задоринки. Следующая проблема, нуждающаяся в исправлении, – неработающая карта сети.

При попытке воспользоваться пунктами «Карта сети» (statusmap.cgi) и «3D карта сети» (statuswrl.cgi) на экране вместо карты обычно появляется такое меню:

Рисунок 2

Причин этому может быть две. Первая – не работает библиотека 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) должна приобрести вид, примерно похожий на этот:

Рисунок 3

Теперь все те, кто ушли пить кофе, могут возвращаться. Сейчас мы начнем починку 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».

Рисунок 4

Обратите внимание на пустой прямоугольник в центре страницы. Его появление означает, что в вашем браузере нет vrml-модуля. Нажимаем на кнопку «Install Now». После того как процесс скачивания закончится, перед нами появится следующее окно:

Рисунок 5

Жмем «Yes» в знак того, что мы доверяем цифровой подписи ParallelGraphics LTD. Подобный механизм цифровых подписей для всех скачиваемых программ помогает избежать подмены или порчи дистрибутива во время его путешествия через сеть.

На следующем экране выставляем во всех окошках галочки. Таким образом, мы назначаем vrml-клиента программой по умолчанию для обработки файлов wrl, wrml и wrz.

Рисунок 6

По окончании инсталляции текущая страница в браузере должна обновиться. И в центре нее появится вращающийся куб.

Рисунок 7

На этом первый способ инсталляции можно считать оконченным. Если в процессе выполнения этих инструкций что-то пошло не так, как должно было, и установка завершилась неудачно, то огорчаться не стоит. Можно выполнить все требуемые действия вручную.

Итак, переходим ко второму способу инсталляции. Скачиваем дистрибутив, подходящий для нашего браузера. После запуска принимаем лицензионное соглашение и несколько раз жмем кнопку «Next». После распаковки файлов на экране должно появиться что-то вроде такой картинки:

Рисунок 8

Система может задуматься на минуту-другую, а затем снова очнется и начнет задавать вопросы.

Рисунок 9

Требуется уточнить, каким образом мы будем отрисовывать vrml-сцены. Выбирайте один из пунктов в зависимости от программного обеспечения, установленного в вашей системе. Если вы ошибетесь, и у вас нет выбранного компонента, то ничего страшного не произойдет. Система самостоятельно переключит отрисовку в программный режим.

Рисунок 10

Лично я – человек ленивый, и не люблю читать  readme-файлы без нужды, поэтому на следующем экране отключаю такую возможность. А вот во втором окошке галочку лучше оставить нетронутой, потому что это позволит нам проверить, правильно ли работает vrml.

Вслед за нажатием кнопки «Next» на экране появится 3D-сцена, изображающая постепенно расцветающую розу.

Рисунок 11

Если нам не удалось правильно угадать нужный режим отрисовки, то рядом откроется окно консоли с соответствующим сообщением.

Рисунок 12

Для того чтобы избавиться от этой надоедливой помехи, закрываем окно консоли и щелкаем правой клавишей мыши в середине окна с 3D-сценой.

Рисунок 13

В открывшемся меню выберем пункт «Preferences». А затем, воспользовавшись вкладкой «Render», выбираем альтернативный механизм рендеринга.

Рисунок 14

Думаю, вы сможете легко самостоятельно разобраться с настройками и изучить способы перемещения в трехмерном виртуальном пространстве. Теперь можно посмотреть на 3D-карту Nagios.

Рисунок 15

Выглядит она пока не так уж и красиво, но дайте время, и все еще изменится к лучшему.

А теперь вновь одним прыжком вернемся к плоской карте сети statusmap.cgi.

Для наглядности давайте представим, что наша система мониторинга наблюдает за сетью, изображенной на следующем рисунке:

Рисунок 16

У нас есть две отдельные подсети, созданные на основе управляемых коммутаторов 3com. Каждому из них выдан собственный IP-адрес. Таким образом, мы имеем возможность проверять их работоспособность с помощью подключаемого модуля check_ping. Внутренняя сеть включает в себя следующие компьютеры:

  • Nagios – система мониторинга;
  • Linux – рабочая станция на основе Linux;
  • Win_2000 – рабочая станция на основе Windows 2000 Professional.

Вторая сеть у нас используется как демилитаризованная зона. В нее включены серверы 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, все остальные машины, задействованные в данной проблеме, получат статус «недоступно». Согласитесь, это все-таки более соответствует действительному положению вещей в контролируемых сетях.

Прародителем всех компьютеров считается машина, на которой работает процесс системы мониторинга. И уже от него строится цепочка.

Рисунок 17

Для правильной диагностики неполадок иерархия должна выглядеть так, как изображено на предыдущей схеме. С точки зрения 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.

Итак, разобравшись с понятием иерархии, посмотрим, как оно влияет на отображение наших сетей на карте.

Рисунок 18

Рисунок 19

Рисунок 20

Рисунок 21

Рисунок 22

Думаю, выглядит довольно впечатляюще. Какой из способов отображения карты будет использоваться по умолчанию, указывает параметр 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 работал с ними довольно хорошо. Полюбоваться на результат можно на следующей картинке.

Рисунок 23

Теперь у каждого хоста и сервиса есть не только личная иконка, но и на страничке с подробной информацией о каждом из них возникло вот такое изображение.

Рисунок 24

Если нажать на него, то можно почитать дополнительные сведения из файла, который мы описали тегом notes_url.

Координаты точек, в которых должны рисоваться иконки и объекты наших хостов на плоской и трехмерной картах сети, не будут использоваться Nagios до тех пор, пока мы не выставим вот таким образом значения тегов default_statusmap_layout и default_statuswrl_layout в файле cgi.cfg.

default_statusmap_layout=0

default_statuswrl_layout=0

Если вы все сделали правильно, то плоская карта сети будет выглядеть вот так:

Рисунок 25

Впечатляет, не правда ли?

Рисунок 26

Трехмерная карта выглядит тоже довольно хорошо. И самое приятное в этом то, что в трехмерное пространство можно добавить, например, подробный макет здания, в котором эта сеть находится, и поставить сервера в нужных помещениях. Но об этом мы поговорим в другой статье. Ну а если вместо вожделенной карты на экране появилась следующая надпись:

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, свои вставки и заголовки. Каждая страница может иметь два заголовка и две вставки. Обычно таким образом в текст страницы можно вставлять корпоративную символику, справочные телефоны и прочие сведения, относящиеся к выбранной странице.

Рисунок 27

Все заголовки страниц и вставки делятся на глобальные и локальные. Глобальные действуют на все страницы cgi, а локальные только на те, для которых они были определены. Тексты, записанные в файлах заголовков и разрывов страниц, вставляются в начало и конец тега страницы, создаваемой cgi.

Обычно текст страницы после обработки выглядит так:

<BODY>

глобальный заголовок

локальный заголовок

первоначальный текст

глобальная вставка

локальная вставка

</BODY>

Давайте посмотрим, что нужно сделать для того, чтобы это работало на примере файла 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</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 начнет воспроизводить звук, связанный с ним. Для осуществления наших желаний есть следующие теги:

  • host_unreachable_sound – хост недоступен;
  • host_down_sound – хост не работает;
  • service_critical_sound – сервис в критическом состоянии;
  • service_warning_sound – сервис в состоянии предупреждения;
  • service_unknown_sound – состояние сервиса неизвестно;
  • normal_sound – все работает отлично, нет никаких проблем.

Опцию 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 начнет проигрывать звук для наиболее критичной из них. После десятка или двух повторений одного и того же звука вам, наверное, захочется отключить звук. Сделать это довольно легко: нужно просто войти в режим управления сервисом или хостом и подать команду подтверждения проблемы.

Рисунок 28

После подобной обработки записи в таблице сервисов или хостов примут вот такой вид:

Рисунок 29

Я думаю, на сегодня хватит грызть гранит науки, и пора дать мозгам отдохнуть. Позволю себе попрощаться с вами в эту радостную минуту.

Литература:

  1. Бешков А. Установка Nagios. – Журнал «Системный администратор» №2(3), февраль 2003 г. – 6-14 с.
  2. Бешков А. Мониторинг Windows-серверов с помощью Nagios. Часть 1. – Журнал «Системный администратор» №7(8), июль 2003 г. – 12-19 с.
  3. Бешков А. Мониторинг Windows-серверов с помощью Nagios. Часть 2. – Журнал «Системный администратор» №8(9), август 2003 г. – 12-23 с.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru