Ganglia и Nagios: Часть 2. Мониторинг коммерческих кластеров с помощью Nagios

Устанавливаем Nagios для эффективного мониторинга вычислительного центра; совместно используем Ganglia и Nagios

Это вторая из двух статей, в которых рассматривается практический подход к мониторингу вычислительных центров с помощью инструментов с открытым исходным кодом Ganglia и Nagios. В части 2 вы научитесь устанавливать и конфигурировать Nagios – популярную открытую компьютерную систему для сетевого мониторинга, которая наблюдает за машинами и сервисами, оповещая пользователей, когда что-то начинает идти не так. В статье также показано, как объединить Nagios и Ganglia (см. часть 1) и как добавить к Nagios две новые возможности, помогающие в мониторинге сетевых коммутаторов и менеджеров ресурсов в стандартных кластерах, решетках и cloud-средах.

Валлард Бенинкоса, сертифицированный технический специалист по продажам, IBM

Валлард Бенинкоса занимается построением кластеров для высокопроизводительных вычислений с 2001 года. Он работает над многими крупнейшими вычислительными комплексами, которые развертывает IBM. Он участвовал в проектировании, установке и поддержке нескольких крупнейших Linux-кластеров IBM, в том числе кластеров суперкомпьютерного центра в Огайо и NASA.



25.06.2009

Обзор части 1

Рост вычислительных центров и экономия на персонале требуют применения эффективных средств мониторинга вычислительных ресурсов. В части 1 этой серии мы обсудили преимущества совместного использования Ganglia и Nagios, а затем рассмотрели процесс установки Ganglia и расширения его возможностей с помощью созданных собственноручно скриптов мониторинга.

Припомним определения мониторинга, которые мы давали в части 1 (различающиеся в зависимости от того, кто и кому о нем говорит):

  • Если вы запускаете на кластере приложения, вам интересны ответы на такие вопросы: «Когда мое задание будет запущено? Когда завершится его выполнение? Как оно выполняется по сравнению с предыдущим разом?»
  • Если вы сетевой инженер, то вы хотели бы знать: "Когда мы увидим красный сигнал, означающий, что нужно что-то исправить и позвонить в сервис?"
  • Если вы системный инженер, то вам интересно: "Какова производительность наших машин? Все ли сервисы функционируют правильно? Какие тенденции наблюдаются и как мы можем лучше использовать наши вычислительные ресурсы?"

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

  1. Ни один инструмент не будет отслеживать все, что вы хотите, и именно так, как вы хотите.
  2. Возможно, вам придется серьезно адаптировать инструмент, чтобы заставить его работать в вашем вычислительном центре именно так, как вы хотите.

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. Мониторинг локальной машины.
Screen showing your local host being monitored

Нажав кнопку 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. Настройка проверки корневого раздела
How the root partition check is configured

Во-первых, обратите внимание на схему наследования объектов 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. Диаграмма сущностей и их файлов
Diagram of entities and their files

Помните об этой диаграмме на всех последующих этапах настройки и установки.

В файле /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 data monitored by 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. Мониторинг коммутаторов
Monitoring switches

Это только один пример того, как настроить мониторинг коммутаторов. Обратите внимание, что я не устанавливал оповещения и не указывал, какие события обозначают критическую ситуацию. Также вы могли бы заметить, что в 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
TORQUE service appears after Nagios restart

У себя я вижу критическое оповещение из-за того, что в очереди находится 518 заданий!

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


Заключение

После прочтения этих двух статей системный администратор должен почувствовать в себе силы, чтобы создать эффективную систему мониторинга своего вычислительного центра, используя Ganglia и Nagios. Эти два пакета обладают необычайно широкими возможностями. В этой статье мы затронули их возможности, связанные с мониторингом кластеров, grid- и cloud-сред.

Большая часть времени при настройке этих решений мониторинга у вас будет уходить на конфигурирование сервисов, которые вы хотите отслеживать. Многие существующие альтернативные решения похожи на «голую» водопроводную сеть без оборудования. Другими словами, они предоставляют инфраструктуру для написания модулей расширения, но редко поставляются с какими-либо уже готовыми модулями. Большая часть работы по написанию модулей расширения перекладывается на администратора или пользователей сети. Часто эта работа недооценивается, хотя фактически она составляет значительную часть эффективного решения мониторинга вычислительного центра.

Вместе Ganglia и Nagios – это больше, чем просто инфраструктура.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=399487
ArticleTitle=Ganglia и Nagios: Часть 2. Мониторинг коммерческих кластеров с помощью Nagios
publish-date=06252009