 | Уровень сложности: средний Валлард Бенинкоса, сертифицированный технический специалист по продажам, IBM
25.06.2009 Это вторая из
двух статей, в которых рассматривается практический подход к мониторингу вычислительных центров с помощью инструментов
с открытым исходным кодом Ganglia и Nagios. В части 2 вы научитесь устанавливать и конфигурировать Nagios –
популярную открытую компьютерную систему для сетевого мониторинга, которая наблюдает за
машинами и сервисами, оповещая пользователей, когда что-то начинает идти не так. В статье также показано, как
объединить Nagios и Ganglia (см.
часть
1) и как добавить к Nagios две новые возможности, помогающие в мониторинге сетевых коммутаторов и
менеджеров ресурсов в стандартных кластерах, решетках и cloud-средах.
Обзор части 1
Рост вычислительных центров и экономия на персонале требуют применения эффективных средств мониторинга
вычислительных ресурсов. В части 1 этой серии мы обсудили преимущества совместного использования Ganglia и
Nagios, а затем рассмотрели процесс установки Ganglia и расширения его возможностей с помощью созданных
собственноручно скриптов мониторинга.
Припомним определения мониторинга, которые мы давали в
части 1
(различающиеся в зависимости от того, кто и кому о нем говорит):
- Если вы запускаете на кластере приложения, вам интересны ответы на такие вопросы: «Когда мое задание
будет запущено? Когда завершится его выполнение? Как оно выполняется по сравнению с предыдущим разом?»
- Если вы сетевой инженер, то вы хотели бы знать: "Когда мы увидим красный сигнал, означающий,
что нужно что-то исправить и позвонить в сервис?"
- Если вы системный инженер, то вам интересно: "Какова производительность наших машин? Все ли сервисы
функционируют правильно? Какие тенденции наблюдаются и как мы можем лучше использовать наши
вычислительные ресурсы?"
Вы можете найти код, причем открытый, который будет отслеживать именно то, что вы хотите. Самое сложное в
использовании средств мониторинга с открытым исходным кодом - выработать такой вид установки и конфигурации,
который подходит для вашей сетевой среды. Вот две главные проблемы, связанные как с открытыми, так и с
коммерческими инструментами мониторинга:
- Ни один инструмент не будет отслеживать все, что вы хотите, и именно так, как вы хотите.
- Возможно, вам придется серьезно адаптировать инструмент, чтобы заставить его работать
в вашем вычислительном центре именно так, как вы хотите.
Ganglia широко используется в средах для высокопроизводительных вычислений (high performance
computing или HPC), но обладает качествами, которые делают его привлекательным и в других
средах (таких как среды cloud-вычислений, комплексы визуализации и центры хостинга). Ganglia больше
сконцентрирован на сборе значений различных параметров (метрик) и отслеживании их изменений с течением
времени, тогда как Nagios сфокусирован на мощном механизме оповещений. Раньше Ganglia мог собирать
информацию только с машин, на которых был запущен его агент, но сейчас метрики можно получить практически
отовсюду с помощью имеющегося в Ganglia механизма подмены адреса узла. В Ganglia нет встроенной
системы уведомления, зато он изначально был спроектирован так, чтобы поддерживать масштабируемую систему
встраиваемых агентов на целевых машинах.
После прочтения части 1 мы научились устанавливать Ganglia, а также отвечать на вопросы, связанные с
мониторингом, обычно задаваемые различными группами пользователей. Также мы научились базовому конфигурированию
Ganglia, увидели, как использовать модули Python для расширения его функциональности с помощью интеллектуального
интерфейса управления платформой (IPMI или Intelligent Platform Management Interface) и как применять технику
подмены узла Ganglia (spoofing) для мониторинга IPMI.
Сейчас давайте познакомимся с Nagios.
Введение в Nagios
В этой части мы увидим, как устанавливать Nagios и интегрировать его с Ganglia. Кроме того, мы добавим в
Nagios две возможности, которые будут полезны в стандартных кластерах, grid- и cloud-средах (и других средах
крупномасштабных вычислений) для решения следующих задач:
- Мониторинг сетевых коммутаторов
- Мониторинг менеджера ресурсов
В нашем случае мы будем наблюдать за TORQUE. Когда мы закончим, в вашем распоряжении окажется
инфраструктура для управления системой мониторинга всего вашего вычислительного центра.
Как и Ganglia, Nagios широко применяется в средах высокопроизводительных вычислений и не только в них.
Однако Nagios в большей степени применяется как средство уведомления, в отличие от Ganglia,
больше сфокусированного на сборе и отслеживании изменений значений различных параметров – метрик. Раньше
Nagios собирал информацию только со своих целевых машин, но теперь у него появились модули расширения,
запускающие агенты на целевых машинах. Также в Nagios имеется встроенная система уведомления.
Теперь давайте установим Nagios и настроим базовую систему мониторинга высокопроизводительного
кластера Linux®, в которой:
- человек, запускающий приложения, может видеть заполненность очереди и видеть узлы, доступные
для запуска на них заданий
- центр сетевых операций может получать оповещения о системных ошибках или видеть красный сигнал
ошибки в Web интерфейсе Nagios. Также возможны оповещения по электронной почте, если какой-нибудь
узел выключается или температура на нем становится слишком высокой
- системный инженер может строить графики данных, получать отчеты об использовании кластера и,
руководствуясь этими данными, принимать решения о приобретении дополнительного оборудования
Установка Nagios
Процесс установки Nagios хорошо документирован в Интернете. Так как мне часто доводится устанавливать
его в различных системах, я написал скрипт, который это делает.
Во-первых, вам нужно загрузить два пакета:
- Nagios (проверялось с версией 3.0.6)
- Nagios-plugins (проверялось с версией 1.4.13)
Дополнения включают в себя:
- Журнал событий Nagios, позволяющий следить за журналамм событий Windows
- NRPE, реализующий значительную часть функциональности Ganglia
Загрузите tar-архивы и поместите их в какую-либо директорию, например в /tmp:
- nagios-3.0.6.tar.gz
- nagios-plugins-1.4.13.tar.gz
- naginstall.sh
В листинге 1 показан установочный скрипт naginstall.sh:
Листинг 1. Установочный скрипт naginstall.sh
#!/bin/ksh
NAGIOSSRC=nagios-3.0.6
NAGIOSPLUGINSRC=nagios-plugins-1.4.13
NAGIOSCONTACTSCFG=/usr/local/nagios/etc/objects/contacts.cfg
NAGIOSPASSWD=/usr/local/nagios/etc/htpasswd.users
PASSWD=cluster
OS=foo
function buildNagiosPlug {
if [ -e $NAGIOSPLUGINSRC.tar.gz ]
then
echo "found $NAGIOSPLUGINSRC.tar.gz building and installing Nagios"
else
echo "could not find $NAGIOSPLUGINSRC.tar.gz in current directory."
echo "Please run $0 in the same directory as the source files."
exit 1
fi
echo "Extracting Nagios Plugins..."
tar zxf $NAGIOSPLUGINSRC.tar.gz
cd $NAGIOSPLUGINSRC
echo "Configuring Nagios Plugins..."
if ./configure --with-nagios-user=nagios --with-nagios-group=nagios
-prefix=/usr/local/nagios > config.LOG.$$ 2>&1
then
echo "Making Nagios Plugins..."
if make -j8 > make.LOG.$$ 2>&1
then
make install > make.LOG.$$ 2>&1
else
echo "Make failed of Nagios plugins. See $NAGIOSPLUGINSRC/make.LOG.$$"
exit 1
fi
else
echo "configure of Nagios plugins failed. See config.LOG.$$"
exit 1
fi
echo "Successfully built and installed Nagios Plugins!"
cd ..
}
function buildNagios {
if [ -e $NAGIOSSRC.tar.gz ]
then
echo "found $NAGIOSSRC.tar.gz building and installing Nagios"
else
echo "could not find $NAGIOSSRC.tar.gz in current directory."
echo "Please run $0 in the same directory as the source files."
exit 1
fi
echo "Extracting Nagios..."
tar zxf $NAGIOSSRC.tar.gz
cd $NAGIOSSRC
echo "Configuring Nagios..."
if ./configure --with-command-group=nagcmd > config.LOG.$$ 2>&1
then
echo "Making Nagios..."
if make all -j8 > make.LOG.$$ 2>&1
then
make install > make.LOG.$$ 2>&1
make install-init > make.LOG.$$ 2>&1
make install-config > make.LOG.$$ 2>&1
make install-commandmode > make.LOG.$$ 2>&1
make install-webconf > make.LOG.$$ 2>&1
else
echo "make all failed. See log:"
echo "$NAGIOSSRC/make.LOG.$$"
exit 1
fi
else
echo "configure of Nagios failed. Please read $NAGIOSSRC/config.LOG.$$ for details."
exit 1
fi
echo "Done Making Nagios!"
cd ..
}
function configNagios {
echo "We'll now configure Nagios."
LOOP=1
while [[ $LOOP -eq 1 ]]
do
echo "You'll need to put in a user name. This should be the person"
echo "who will be receiving alerts. This person should have an account"
echo "on this server. "
print "Type in the userid of the person who will receive alerts (e.g. bob)> \c"
read NAME
print "What is ${NAME}'s email?> \c"
read EMAIL
echo
echo
echo "Nagios alerts will be sent to $NAME at $EMAIL"
print "Is this correct? [y/N] \c"
read YN
if [[ "$YN" = "y" ]]
then
LOOP=0
fi
done
if [ -r $NAGIOSCONTACTSCFG ]
then
perl -pi -e "s/nagiosadmin/$NAME/g" $NAGIOSCONTACTSCFG
EMAIL=$(echo $EMAIL | sed s/\@/\\\\@/g)
perl -pi -e "s/nagios\@localhost/$EMAIL/g" $NAGIOSCONTACTSCFG
else
echo "$NAGIOSCONTACTSCFG does not exist"
exit 1
fi
echo "setting ${NAME}'s password to be 'cluster' in Nagios"
echo " you can change this later by running: "
echo " htpasswd -c $NAGIOSPASSWD $Name)'"
htpasswd -bc $NAGIOSPASSWD $NAME cluster
if [ "$OS" = "rh" ]
then
service httpd restart
fi
}
function preNagios {
if [ "$OS" = "rh" ]
then
echo "making sure prereqs are installed"
yum -y install httpd gcc glibc glibc-common gd gd-devel perl-TimeDate
/usr/sbin/useradd -m nagios
echo $PASSWD | passwd --stdin nagios
/usr/sbin/groupadd nagcmd
/usr/sbin/usermod -a -G nagcmd nagios
/usr/sbin/usermod -a -G nagcmd apache
fi
}
function postNagios {
if [ "$OS" = "rh" ]
then
chkconfig --add nagios
chkconfig nagios on
# touch this file so that if it doesn't exist we won't get errors
touch /var/www/html/index.html
service nagios start
fi
echo "You may now be able to access Nagios at the URL below:"
echo "http://localhost/nagios"
}
if [ -e /etc/redhat-release ]
then
echo "installing monitoring on Red Hat system"
OS=rh
fi
# make sure you're root:
ID=$(id -u)
if [ "$ID" != "0" ]
then
echo "Must run this as root!"
exit
fi
preNagios
buildNagios
buildNagiosPlug
configNagios
postNagios
|
Запустите скрипт ./naginstall.sh
Этот код работает в системах Red Hat и должен выполняться без ошибок, если вы предварительно
установили все зависимости, указанные в
части 1 этой серии. При запуске naginstall.sh вам будет предложено указать пользователя, которому Nagios должен слать
оповещения. Позже вы сможете добавить и других пользователей. В большинстве организаций есть почтовые псевдонимы, которые
перенаправляют письма всем людям из нужной группы.
Если вы столкнулись с трудностями в процессе установки, посетите сайт проекта Nagios
(см. ссылку в разделе Ресурсы)
и присоединяйтесь к рассылке. По моему опыту, пакеты такого уровня успешности, как Nagios и
Ganglia относительно просты в установке.
Настройка Nagios
Итак, представим, что скрипт сделал за вас всю работу и установка прошла успешно. Тогда по завершении
работы скрипта, открыв web браузер, вы можете увидеть, что за локальной машиной установлено наблюдение,
как на рисунке 1:
Рисунок 1. Мониторинг локальной машины.
Нажав кнопку Service Detail, вы можете увидеть, что на локальной машине отслеживаются несколько
сервисов (таких как Ping, HTTP, загрузка, пользователи и т.д.). Так было настроено по умолчанию.
Давайте изучим сервис под названием Root Partition (корневой раздел). Этот сервис оповещает вас,
когда корневой раздел полностью заполняется. Вы можете получить полное представление о том, как это работает,
изучив конфигурационные файлы, сгенерированные во время инсталляции.
Главный конфигурационный файл
Если для установки вы использовали скрипт naginstall.sh, то главный конфигурационный файл – это
/usr/local/nagios/etc/nagios.cfg. В этом скрипте указано еще несколько конфигурационных файлов,
содержащих дополнительные определения. Например:
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
Если вы изучите этот файл, вы увидите в нем все сервисы локальной машины,
которые присутствуют в Web-представлении. Именно здесь конфигурируются сервисы по умолчанию.
Определение сервиса Root Partition находится в 77-ой строке.
Иерархия того, как настроена проверка корневого раздела, показана на рисунке 2
Рисунок 2. Настройка проверки корневого раздела
Во-первых, обратите внимание на схему наследования объектов Nagios. Определение
сервиса Root Partition использует определения локальных сервисов (local-service), которые в свою очередь используют
определения обобщенных сервисов (generic-service). В этих определениях задается, как и насколько часто вызывается сервис,
прочие регулируемые параметры и т.д.
Следующей важной частью определения является используемая команда проверки. Во-первых,
указывается определение команды -
check_local_disk. Это определение передает параметры
!20%!10%!/. Это значит, что если
check_local_disk вернет значение меньше чем
20%, будет сгенерировано предупреждение, а если меньше чем
10% - будет получена критическая ошибка. Символ
/ означает, что будет проверяться (корневой) раздел «/».
Затем check_local_disk просто вызывает команду
check_disk, находящуюся в директории
/usr/local/nagios/libexec directory.
Такова общая идея настройки Nagios. Имея о ней представление, вы можете создавать свои собственные
сервисы для мониторинга и настраивать параметры по своему желанию. Для более глубокого понимания происходящих
процессов читайте документацию и пробуйте самостоятельно регулировать параметры мониторинга.
Подписка на оповещения
Теперь, когда все настроено, давайте подпишемся на оповещения. Мы уже делали это в самом начале, но
если вы хотите добавить в подписку новых пользователей или изменить существующих, вы можете сделать это
в файле /usr/local/nagios/etc/objects/contacts.cfg. Просто замените в нем контактное имя и адрес электронной
почты на ваши. Большинство простых Linux-серверов уже должны быть настроены для обработки сообщений.
Теперь давайте сконфигурируем другие узлы (помимо локальной машины).
Настройка узлов в grid-системах, кластерах и cloud-средах
У меня есть группа узлов в моем вычислительном центре в Далласе. Я создам для нее директорию, в которую
помещу мои конфигурационные файлы:
mkdir -p /usr/local/nagios/etc/dallas
Теперь нужно сообщить Nagios, что мои конфигурационные файлы находятся здесь. Сделаем это,
добавив в файл nagios.cfg следующую строку:
cfg_dir=/usr/local/nagios/etc/dallas
Теперь я создам здесь несколько файлов, которые могут показаться довольно сложными.
На рисунке 3 показаны создаваемые сущности, файлы, которым они принадлежат, а также их взаимосвязи.
Рисунок 3. Диаграмма сущностей и их файлов
Помните об этой диаграмме на всех последующих этапах настройки и установки.
В файле /usr/local/nagios/etc/dallas/nodes.cfg я определил имеющиеся узлы и группы узлов.
Мы хотим настроить мониторинг трех типов машин:
- Сетевые серверы (в моем случае это Linux-серверы с запущенным на них сервисом Ganglia)
- Сетевые коммутаторы (включая высокоскоростные, в том числе коммутаторы Gigabit Ethernet)
- Управляющие устройства (такие как модули управления blade-серверами, старые платы IBM RSA, различные
BMC, PDU-устройства и т.д.)
Соответственно я создаю в конфигурационном файле три следующие группы :
define hostgroup {
hostgroup_name dallas-cloud-servers
alias Dallas Cloud Servers
}
define hostgroup
hostgroup_name dallas-cloud-network
alias Dallas Cloud Network Infrastructure
}
define hostgroup
hostgroup_name dallas-cloud-management
alias Dallas Cloud Management Devides
}
|
Затем для каждой группы устройств я создам файл шаблонов, содержащий общие характеристики
всех узлов данной группы:
define host {
name dallas-management
use linux-server
hostgroups dallas-cloud-management
# TEMPLATE!
register 0
}
define host {
name dallas-server
use linux-server
hostgroups dallas-cloud-servers
# TEMPLATE!
register 0
}
define host {
name dallas-network
use generic-switch
hostgroups dallas-cloud-network
# TEMPLATE!
register 0
}
|
Теперь мои узлы мониторинга определяются как
dallas-management,
dallas-server или
dallas-network. Вот пример, как может выглядеть каждый из них:
define host {
use dallas-server
host_name x336001
address 172.10.11.1
}
define host {
use dallas-network
host_name smc001
address 172.10.0.254
}
define host {
use dallas-management
host_name x346002-rsa
address 172.10.11.12
}
|
Я сгенерировал скрипт, проходящий по списку узлов, имеющихся в моей лаборатории в Далласе, и заполняющий
для них этот файл. Теперь при перезапуске Nagios все они будут проверяться на доступность. Но ведь мне нужно
добавить и другие сервисы!
Мы можем сейчас перезапустить Nagios, чтобы убедиться, что наши настройки работают. Если
все правильно, то мы увидим, что в представлении HostGroup
Overview появились группы. Если что-то не так, воспользуйтесь командой:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Она проверит правильность вашего файла и поможет найти возможные ошибки.
Теперь можно добавить какие-нибудь простые сервисы. Если следовать шаблонам, имеющимся
для локальной машины, можно довольно легко добавить проверку сервиса SSH для группы узлов
dallas-cloud-servers. Для этого создадим еще один файл:
/usr/local/nagios/etc/dallas/host-services.cfg. Проще всего скопировать в него
настройки из соответствующего файла для локальной машины. Я сделал это, а также добавил зависимость:
define service{
use generic-service
hostgroup_name dallas-cloud-servers
service_description SSH
check_command check_ssh
}
define service{
use generic-service
hostgroup_name dallas-cloud-servers
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}
define servicedependency{
hostgroup_name dallas-cloud-servers
service_description PING
dependent_hostgroup_name dallas-cloud-servers
dependent_service_description SSH
}
|
Мы не будем проверять SSH в случаях, когда не работает PING. Подобным образом вы можете
добавлять и другие вещи, но сначала надо убедиться в том, что это работает. Перезапустите
Nagios и убедитесь, что в меню появились проверки сервисов ping и ssh для ваших узлов:
service nagios reload
Все в порядке? Отлично, тогда давайте приступим к самой интересной части – интеграции с Ganglia.
Интегрируем в Nagios оповещения для метрик Ganglia
Еще одно прекрасное место, где можно скачать модули расширения для Nagios, - это Nagios Exchange.
Но модуль расширения Nagios для Ganglia можно получить и из tar-архива, который мы
загрузили в
части 1 этой статьи.
Предположим, что вы распаковали его в директорию /tmp, тогда из него нужно просто скопировать скрипт
check_ganglia.py, находящийся в директории contrib:
cp /tmp/ganglia-3.1.1/contrib/check_ganglia.py \
/usr/local/nagios/libexec/
|
Написанный на Python скрипт
check_ganglia нужно запускать на том же сервере, где запущен демон
gmetad (в моем случае это управляющий сервер, на котором
также запущен и Nagios).
Давайте с его помощью опросим порт 8649 локальной машины. Таким образом, мы не будем тратить
сетевой трафик благодаря средствам масштабирования
Ganglia.
Если запустить команду telnet localhost 8649, будет выведено огромное
количество информации, полученной на основе данных, собранных с узлов мониторинга (при условии, что Ganglia
настроен и работает). Давайте настроим мониторинг некоторых вещей, имеющихся в Ganglia.
В директории /var/lib/ganglia/rrds вы можете найти, какие именно метрики отслеживаются на
каждом конкретном узле. Также генерируются симпатичные графики, чтобы было легче анализировать изменение
метрик с течением времени. Мы будем отслеживать метрики
load_one, disk_free
и, раз уж мы в части 1 настроили измерение температуры с помощью IPMI, то и эту метрику тоже.
Создадим файл /usr/local/nagios/etc/dallas/ganglia-services.cfg и добавим в него следующие сервисы:
define servicegroup {
servicegroup_name ganglia-metrics
alias Ganglia Metrics
}
define command {
command_name check_ganglia
command_line $USER1$/check_ganglia.py -h $HOSTNAME$ -m $ARG1$ -w $ARG2$ -c $ARG3$
}
define service {
use generic-service
name ganglia-service
hostgroup_name dallas-cloud-servers
service_groups ganglia-metrics
notifications_enabled 0
}
define service {
use ganglia-service
service_description load_one
check_command check_ganglia!load_one!4!5
}
define service {
use ganglia-service
service_description ambient_temp
check_command check_ganglia!AmbientTemp!20!30
}
define service {
use ganglia-service
service_description disk_free
check_command check_ganglia!disk_free!10!5
}
|
Теперь, перезапустив Nagios, мы сможем добавлять оповещения для метрик Ganglia!
Небольшое предупреждение: скрипт check_ganglia.py генерирует
оповещения только при слишком больших значениях показателей. Если вы хотите настроить оповещения и
когда показатель становится слишком мал, (как в случае с
disk_free), то придется немного подправить код скрипта. Я изменил код
в конце файла следующим образом:
if critical > warning:
if value >= critical:
print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
sys.exit(2)
elif value >= warning:
print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
sys.exit(1)
else:
print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
sys.exit(0)
else:
if critical >= value:
print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
sys.exit(2)
elif warning >= value:
print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
sys.exit(1)
else:
print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
sys.exit(0)
|
Теперь перезапустим Nagios:
service nagios restart
Если все будет хорошо, вы увидите, что теперь данные Ganglia отслеживаются в Nagios!
Рисунок 4. Отслеживание данных Ganglia в Nagios
Используя Ganglia и Nagios совместно, вы можете настроить мониторинг всего, чего
угодно. Вы буквально можете управлять своим "облаком"!
Расширение возможностей Nagios: мониторинг сетевых коммутаторов
По мере того, как cloud-среды и виртуализация становятся частью нашей жизни, привычные границы обязанностей
сетевых инженеров и системных администраторов все больше размываются. Системный администратор, пренебрегающий
настройкой сетевых коммутаторов и пониманием сетевых топологий, рискует оказаться не у дел.
Поэтому сейчас для полноты картины я расскажу о расширении функциональности Nagios для мониторинга
работы сетевых коммутаторов. Преимуществом использования Nagios для мониторинга коммутаторов (по сравнению
с использованием решения, поставляемого производителем конкретного оборудования) является то, что с
его помощью можно вести наблюдение за коммутатором любого производителя. Мы уже видели, как отслеживать сервис ping, давайте
теперь научимся отслеживать SNMP на коммутаторах.
В некоторых коммутаторах SNMP включен по умолчанию. В любом случае вы можете его включить и настроить, следуя
инструкциям производителя. Вы можете настроить коммутатор Cisco, пользуясь приведенным ниже примером настройки моего
коммутатора с именем c2960g:
telnet c2960g
c2960g>enable
c2960g#configure terminal
c2960g(config)#snmp-server host 192.168.15.1 traps SNMPv1
c2960g(config)#snmp-server community public
c2960g(config)#exit
c2960g#copy running-config startup-config
|
Чтобы посмотреть, какие метрики можно отслеживать, запустите команду snmpwalk
и перенаправьте ее результат в файл:
snmpwalk -v 1 -c public c2960g
Если все пойдет хорошо, команда вернет огромное количество информации, среди
которой можно поискать, что вам было бы интересно отслеживать.
Я воспользуюсь для примера еще одним своим коммутатором. Запуская на нем команду
snmpwalk, я могу видеть номера и описания портов. Мне было бы интересно получить следующую информацию:
- MTU
(
IF-MIB::ifMtu.<portnumber>).
- скорость работы порта
(
IF-MIB::ifSpeed.<port number>).
- работает ли порт в данный момент
(
IF-MIB::ifOperStatus.<port number>).
Чтобы настроить мониторинг этих показателей создадим файл
/usr/local/nagios/etc/dallas/switch-services.cfg. Я знаю, где
в моей сети находится каждое устройство, потому что у меня есть
карта распределения машин по коммутаторам. Если вы хотите устроить
у себя cloud-среду, вы также должны все в точности знать о вашей
сети.
Например, я хочу получать информацию об узле x336001. Я знаю, что он находится на
порту 5. Вот как выглядит мой конфигурационный файл:
define servicegroup {
servicegroup_name switch-snmp
alias Switch SNMP Services
}
define service {
use generic-service
name switch-service
host_name smc001
service_groups switch-snmp
}
define service {
use switch-service
service_description Port5-MTU-x336001
check_command check_snmp!-o IF-MIB::ifMtu.5
}
define service {
use switch-service
service_description Port5-Speed-x336001
check_command check_snmp!-o IF-MIB::ifSpeed.5
}
define service {
use switch-service
service_description Port5-Status-x336001
check_command check_snmp!-o IF-MIB::ifOperStatus.5
}
|
Теперь перезапустив Nagios, мы можем отслеживать информацию с коммутатора
об этом узле:
Рисунок 5. Мониторинг коммутаторов
Это только один пример того, как настроить мониторинг коммутаторов. Обратите
внимание, что я не устанавливал оповещения и не указывал, какие события обозначают
критическую ситуацию. Также вы могли бы заметить, что в libexec есть и другие команды,
например, check_ifoperstatus,
которые позволяют делать то же самое. В Nagios одну и ту же задачу можно решать несколькими способами.
Расширение Nagios: отслеживаем задания TORQUE
TORQUE – это менеджер ресурсов, работающий с планировщиками наподобие Moab и Maui. Для
TORQUE можно написать множество скриптов, чтобы можно было определять, как работает эта
система диспетчеризации. Далее я предполагаю, что TORQUE у вас установлен и работает.
Давайте рассмотрим
открытый
модуль расширения Nagios
для работы с ним, написанный Колином Мореем.
Загрузите его, поместите в директорию /usr/local/nagios/libexec и сделайте исполняемым.
Чтобы заставить его работать, мне пришлось немного поправить его код. Во-первых, я поменял
строку с директорией, в которой установлен Nagios, с
use lib "/usr/nagios/libexec"; на
use lib "/usr/local/nagios/libexec";. Во-вторых, в строке
my $qstat = '/usr/bin/qstat' ; мне пришлось поменять директорию, в
которой находится qstat (т.е. в моем случае получилось:
my $qstat = '/opt/torque/x86_64/bin/qstat' ;).
Проверим, что это работает (я использую очередь dqueue):
[root@redhouse libexec]# ./check_pbs.pl -Q dque -tw 20 -tm 50
check_pbs.pl Critical: dque on localhost checked, Total number of jobs
higher than 50. Total jobs:518, Jobs Queued:518, Jobs Waiting:0, Jobs
Halted:0 |exectime=9340us
|
С помощью параметра -h можно посмотреть
дополнительные показатели, доступные для мониторинга. Теперь давайте поместим в
конфигурационный файл
/usr/local/nagios/etc/dallas/torque.cfg следующее:
define service {
use generic-service
host_name localhost
service_description TORQUE Queues
check_command check_pbs!20!50
}
define command {
command_name check_pbs
command_line $USER1$/check_pbs.pl -Q dque
-tw $ARG1$ -tm $ARG2$
}
|
После перезапуска Nagios в разделе метрик локальной машины появится новый сервис:
Рисунок 6. После перезапуска Nagios
появляется сервис TORQUE
У себя я вижу критическое оповещение из-за того, что в очереди находится 518 заданий!
Очевидно, есть множество других способов следить за работой TORQUE, скриптов, которые
можно написать, а также уже написанных скриптов. Вы можете даже задавать в скриптах состояние
узлов, используя команду pbsnodes. Тогда пользователи, возможно, станут больше заботиться
о том, где и как долго выполняются их задания. В этом небольшом примере просто дается
представление о том, что вообще можно сделать для мониторинга TORQUE и показывается,
насколько хорошим можно сделать ваше решение мониторинга за небольшое время.
Заключение
После прочтения этих двух статей системный администратор должен почувствовать
в себе силы, чтобы создать эффективную систему мониторинга своего вычислительного
центра, используя Ganglia и Nagios. Эти два пакета обладают необычайно широкими возможностями.
В этой статье мы затронули их возможности, связанные с мониторингом кластеров, grid- и cloud-сред.
Большая часть времени при настройке этих решений мониторинга у вас будет уходить на конфигурирование
сервисов, которые вы хотите отслеживать. Многие существующие альтернативные решения похожи на «голую»
водопроводную сеть без оборудования. Другими словами, они предоставляют инфраструктуру
для написания модулей расширения, но редко поставляются с какими-либо уже готовыми модулями. Большая
часть работы по написанию модулей расширения перекладывается на администратора или пользователей сети.
Часто эта работа недооценивается, хотя фактически она составляет значительную часть эффективного
решения мониторинга вычислительного центра.
Вместе Ganglia и Nagios – это больше, чем просто инфраструктура.
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторе | | | Валлард Бенинкоса занимается построением кластеров для высокопроизводительных вычислений с 2001 года.
Он работает над многими крупнейшими вычислительными комплексами, которые развертывает IBM. Он участвовал в проектировании, установке и поддержке нескольких крупнейших Linux-кластеров IBM, в том числе кластеров суперкомпьютерного центра в Огайо и NASA. |
Выскажите мнение об этой странице
| |
