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

Устанавливаем, настраиваем и расширяем открытый инструмент Ganglia для эффективного мониторинга вычислительного центра

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

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

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



28.05.2009

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

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

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

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

  • Нет такого инструмента, который бы отслеживал все параметры, которые вы хотите и именно так, как вы хотите. Почему? Потому что разные пользователи по-разному видят для себя мониторинг (как я указывал ранее).
  • Ввиду первой проблемы вам, возможно, придется серьезно адаптировать инструмент, чтобы заставить его работать в вашем вычислительном центре именно так, как вы хотите. Почему? Потому что каждая сеть, какой бы стандартной она ни была, все равно является уникальной.

Кстати, те же самые проблемы существуют и с коммерческими инструментами мониторинга.

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

По мере развития этих проектов их функциональность начала перекрываться. Например:

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

Хотя эти инструменты местами имеют схожую функциональность, все-таки они довольно сильно различаются, так что, используя их совместно, вы можете только выиграть. Их совместное использование может компенсировать недостатки каждого продукта:

  • В Ganglia нет встроенной системы оповещения, тогда как в Nagios она есть, притом замечательная.
  • По всей видимости, в Nagios нет масштабируемых агентов на целевых машинах (хотя некоторые могут с этим поспорить), в то время как в архитектуре Ganglia это предусмотрено изначально.

Есть и другие проекты с открытым исходным кодом, предназначенные для тех же самых целей, каждый со своими достоинствами и недостатками. Самые популярные среди них - это Cacti, Zenoss, Zabbix, Performance Copilot (PCP), и Clumon (также наверняка есть еще и ваш любимый проект, о котором я не упомянул). Многие из них (включая Ganglia и некоторые модули расширения Nagios) используют инструмент Тоби Этикера RRDT или MRTG (Multi Router Traffic Grapher) для хранения данных и создания симпатичных графиков.

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

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

Прочитав эту статью, вы научитесь устанавливать Ganglia и связывать его с Nagios, а также сможете решать задачи мониторинга, интересные различным группам пользователей. Хотя это только начало, эта статья поможет вам познакомиться с основами систем мониторинга и создать цельное видение вашего кластера.

В этой статье мы рассмотрим следующие темы:

  • Стандартная установка и конфигурирование Ganglia
  • Использование модулей Python для расширения функциональности с помощью интеллектуального интерфейса управления платформой (IPMI, Intelligent Platform Management Interface).
  • Использование техники подмены узла Ganglia для мониторинга IPMI.

Наша цель – настроить базовую систему мониторинга HPC кластера Linux®, которая бы в той или иной степени соответствовала трем взглядам на мониторинг, указанным выше; систему в которой:

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

Введение в Ganglia

Ganglia – это система мониторинга с открытым исходным кодом, спроектированная для работы с тысячами узлов, изначально разрабатывавшаяся в университете Berkeley. На каждой машине запускается демон gmond, который собирает системную информацию (скорость процессора, использование памяти и т.д.) и посылает ее на определенную машину. Машина, получающая информацию, может отображать ее, а также передавать некоторую обобщенную форму данных вверх по иерархии. Именно благодаря этой иерархической схеме Ganglia так хорошо масштабируется. Накладные расходы, связанные с работой gmond, очень малы, поэтому этот код можно запускать на всех машинах кластера без ущерба для производительности.

Случается, что такой сбор данных все-таки влияет на производительность узлов. В сетях это называется «джиттер» - когда много маленьких сообщений приходят в одно и то же время. Мы с этим столкнулись, жестко синхронизировав часы на узлах; этого можно избежать.


Установка Ganglia

В Интернете есть множество статей и ресурсов, рассказывающих об установке Ganglia. Мы обратимся к статье, написанной мною для wiki проекта xCAT. Для целей данной статьи будем полагать, что используется операционная система семейства Red Hat 5, обновление 2 (хотя действия в другой промышленной операционной системе Linux не будут сильно отличаться).

Подготовительный этап

Если у вас настроен репозиторий yum, установка предварительных компонентов должна быть довольно простой. Что-то вроде этого:

yum -y install apr-devel apr-util check-devel cairo-devel pango-devel libxml2-devel
  rpmbuild glib2-devel dbus-devel freetype-devel fontconfig-devel gcc-c++ expat-devel
  python-devel libXrender-devel

(Замечание: Вообще yum должен справляться с большинством этих зависимостей, но я видел в одном из своих тестов ошибки компиляции, которые удалось устранить, добавив все эти пакеты.)

Теперь нужно предварительно установить еще один компонент, отсутствующий в репозитории Red Hat. Если ваша машина имеет соединение с Интернетом, вы можете установить и собрать его так:

wget \ http://ga13.files.bigpond.com:4040/fedora/linux/releases/9/Everything/source/
       SRPMS/libconfuse-2.6-1.fc9.src.rpm

rpmbuild --rebuild libconfuse-2.6-1.fc9.src.rpm
cd /usr/src/redhat/RPMS/x86_64/
rpm -ivh libconfuse-devel-2.6-1.x86_64.rpm libconfuse-2.6-1.x86_64.rpm

Помните, что зеркала часто меняются. Если это зеркало не работает, найдите rpm-файл libconfuse-2.6.-1.fc9 с помощью поисковика.

Инструмент RRDTool

RRDTool (Round Robin Database Tool) - это инструмент работы с базами данных круговой системы. Этот инструмент был создан Тобиасом Этикером, он применяется во многих высокопроизводительных инструментах мониторинга. Помимо Ganglia, это Cacti и Zenoss.

Чтобы установить Ganglia, нам сначала нужно запустить RRDTool на нашем сервере мониторинга. RRDTool предоставляет две замечательные возможности, широко используемые другими программами:

  • • Он хранит данные в базе данных круговой системы (Round Robin). Подробность хранимых данных уменьшается по мере их устаревания. Это позволяет сохранить компактность базы данных без ущерба для ее полезности в большинстве случаев.
  • Он может строить графики на основе собранных данных с помощью аргументов командной строки.

Для установки RRDTool выполните следующее (проверено с версиями 1.3.4 и 1.3.6):

cd /tmp/
wget http://oss.oetiker.ch/rrdtool/pub/rrdtool.tar.gz
tar zxvf rrdtool*
cd rrdtool-*
./configure --prefix=/usr
make -j8
make install
which rrdtool
ldconfig  # чтобы создать ссылки на новые библиотеки rrdtool.

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

Основная установка Ganglia

Теперь, выполнив все предварительные установки, мы можем установить Ganglia. Сначала нужно его скачать. В этой статье мы используем Ganglia 3.1.1. Загрузите файл ganglia-3.1.1.tar.gz и поместите его в каталог /tmp вашего сервера мониторинга. Затем сделайте следующее:

cd /tmp/
tar zxvf ganglia*gz
cd ganglia-3.1.1/
./configure --with-gmetad
make -j8
make install

Установка должна пройти без ошибок. Если ошибки появляются, проверьте наличие всех необходимых библиотек.


Настройка Ganglia

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

  1. Поработаем с файлами в командной строке.
  2. Отредактируем файл /etc/ganglia/gmond.conf.
  3. Позаботимся о машинах с несколькими сетевыми интерфейсами.
  4. Запустим Ganglia на управляющем сервере.

Шаг 1: работаем с файлами в командной строке.

Сделайте то, что показано ниже:

cd /tmp/ganglia-3.1.1/   # вы уже должны находиться в этой директории
mkdir -p /var/www/html/ganglia/  # убедитесь что apache установлен
cp -a web/* /var/www/html/ganglia/   # это web интерфейс
cp gmetad/gmetad.init /etc/rc.d/init.d/gmetad  # скрипт для запуска при старте системы
cp gmond/gmond.init /etc/rc.d/init.d/gmond
mkdir /etc/ganglia  # здесь будут конфигурационные файлы
gmond -t | tee /etc/ganglia/gmond.conf  # генерируем файл начальной конфигурации для gmond
cp gmetad/gmetad.conf /etc/ganglia/  # файл начальной конфигурации для gmetad
mkdir -p /var/lib/ganglia/rrds  # место хранения графиков, построенных с помощью RRDTool
chown nobody:nobody /var/lib/ganglia/rrds  # чтобы RRDTool мог писать в эту директорию
chkconfig --add gmetad  # чтобы gmetad запускался во время загрузки системы
chkconfig --add gmond # чтобы gmetad запускался во время загрузки системы

Шаг 2: редактируем файл /etc/ganglia/gmond.conf.

Теперь можно задать имя кластера в файле /etc/ganglia/gmond.conf. Предположим, что наш кластер называется matlock, тогда нужно заменить строчку name = "unspecified" на name = "matlock".

Шаг 3: позаботимся о машинах с несколькими сетевыми интерфейсами.

В моем кластере eth0 является публичным IP-адресом моей системы. Однако сервер мониторинга общается с узлами сети через eth1. Нужно привязать групповую рассылку, используемую Ganglia, к eth1. Это можно сделать, создав файл /etc/sysconfig/network-scripts/route-eth1 с содержимым 239.2.11.71 dev eth1.

Теперь можно перезапустить сетевой сервис командой service network restart после чего убедиться, что в маршрутах этот IP-адрес проходит через eth1. Замечание: Адрес 239.2.11.71, который мы использовали - это канал групповой рассылки ganglia по умолчанию. Измените его если вы будете менять этот канал или добавлять новые.

Шаг 4: запускаем Ganglia на управляющем сервере.

Теперь мы можем запустить Ganglia на сервере мониторинга:

service gmond start
service gmetad start
service httpd restart

Откройте на управляющем сервере браузер и перейдите по адресу: http://localhost/ganglia. По этому адресу вы теперь можете наблюдать за состоянием управляющего сервера. Вы увидите несколько отслеживаемых показателей и их графики. Одним из самых полезных отслеживаемых показателей является загрузка машины. График загрузки моей машины выглядит так:

Рисунок 1. Мониторинг загрузки
Monitoring load

Как видно, ничего не происходит, машина просто простаивает.

Размещение Ganglia на узлах

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

Вот быстрый и грубый способ сделать то, что нужно. Создадим файл с именами всех ваших машин. Предположим, ваши узлы называются deathstar001-deathstar100, тогда нужно создать файл /tmp/mynodes, выглядящий так:

deathstar001
deathstar002
...и так далее...
deathstar099
deathstar100

Теперь просто запустите:

# for i in `cat /tmp/mynodes`; do 
scp /usr/sbin/gmond $i:/usr/sbin/gmond
ssh $i mkdir -p /etc/ganglia/
scp /etc/ganglia/gmond.conf $i:/etc/ganglia/
scp /etc/init.d/gmond $i:/etc/init.d/
scp /usr/lib64/libganglia-3.1.1.so.0 $i:/usr/lib64/
scp /lib64/libexpat.so.0 $i:/lib64/
scp /usr/lib64/libconfuse.so.0 $i:/usr/lib64/
scp /usr/lib64/libapr-1.so.0 $i:/usr/lib64/
scp -r /usr/lib64/ganglia $i:/usr/lib64/
ssh $i service gmond start
done

Если вы сейчас перезапустите gmetad и обновите окно браузера, то вы увидите список, содержащий все ваши узлы.

Некоторые проблемы, с которыми вы можете столкнуться:

  • Возможно, придется выполнить шаг 3 на всех узлах, чтобы явно указать статический маршрут.
  • Возможно, у вас есть межсетевой экран (firewall), блокирующий порты. Демон gmond работает на порте 8649. Чтобы проверить, что gmond запущен на машине, вы можете запустить команду telnet localhost 8649 - в результате вы должны увидеть некоторый XML-текст.

Ведение наблюдений с помощью Ganglia

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

Мы изучим с помощью Ganglia поведение системы во время выполнения тестов Linpack. На рисунке 2 показан промежуток времени, в течение которого я запускал три различных задания Linpack.

Рисунок 2. Наблюдения за Linpack
Watching over Linpack

Как видно из графика, во время выполнения заданий наблюдается некоторая сетевая активность. Также интересно то, что сетевой трафик заметно увеличивается к концу заданий. Даже не зная ничего о Linpack, мы уже можем кое-что сказать о его работе: объем трафика возрастает к концу выполнения заданий.

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

Рисунок 3. Использование процессора
CPU usage
Рисунок 4. Использование памяти
Memory usage

Эти графики дают нам представление о работе приложения: мы используем много процессорного времени и памяти, а также начинаем генерировать больше сетевого трафика к концу задания. Конечно, еще очень многих параметров выполнения работы мы не знаем, но все-таки для начала это очень неплохие данные.

Знание таких вещей поможет в будущем сделать лучший выбор при покупке дополнительного оборудования. Хотя, конечно, никто не будет обновлять аппаратное обеспечение только чтобы запускать Linpack… верно?


Расширение возможностей

Основной пакет Ganglia предоставляет нам множество полезной информации. Использование модулей расширения (плагинов) Ganglia позволяет расширить его возможности двумя способами:

  • Добавлением внутренних модулей расширения
  • Добавлением внешних источников данных с помощью техники подмены узла.

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


Внутренние модули расширения

Внутренние модули расширения реализуются двумя путями.

  • С помощью задач cron, в которых вызывается команда gmetric, осуществляющая ввод данных в Ganglia
  • С помощью написания скриптов в новых модулях расширения для Python

Первый метод широко применялся в прошлом и я расскажу о нем в следующем разделе, посвященном внешним модулям расширения. Его проблема была в том, что это довольно «грязный» метод. Чтобы сделать расширение Ganglia более естественным, в Ganglia 3.1.x были добавлены модули расширения для С и Python. Сейчас я расскажу о втором методе.

Во-первых, включим модули расширения Python для Ganglia. Надо сделать следующее:

  1. Отредактировать файл /etc/ganglia/gmond.conf

Когда вы его откроете, то, пролистав от начала примерно четверть файла, вы увидите раздел modules, выглядящий примерно так:

modules {
    module {
           name = "core_metrics"
     }
     ...
}

Нужно добавить в этот раздел еще один модуль:

  module {
    name = "python_module"
    path = "modpython.so"
    params = "/usr/lib64/ganglia/python_modules/"
  }

В моем файле gmond.conf я добавил этот код начиная с 90-ой строки. Таким образом мы включили в Ganglia модули расширения Python. Также несколькими строчками ниже после инструкции include ('/etc/ganglia/conf.d/*.conf') нужно добавить строчку include ('/etc/ganglia/conf.d/*.pyconf'). Это подключает определения добавляемых нами модулей.

  1. Создать следующие директории:
mkdir /etc/ganglia/conf.d
mkdir /usr/lib64/ganglia/python_modules
  1. Выполнить шаги 1 и 2 на всех ваших узлах.

Для этого:

  • Скопируйте новый файл gmond.conf на все узлы за которыми мы будем наблюдать.
  • Создайте две директории указанные в пункте 2 на каждом узле, чтобы узлы также могли использовать расширения Python.

Теперь, когда узлы подготовлены, давайте создадим новый модуль Python. В нашем примере мы создадим модуль расширения, который будет использовать IPMI драйверы для Linux. Если вы не знакомы с IPMI и работаете с современными машинами от Intel или AMD, ознакомьтесь с соответствующей ссылкой в разделе Ресурсы.

Мы будем использовать инструмент IPMItool с открытым исходным кодом для связи с устройствами IPMI на локальной машине. Есть и другие инструменты, например, OpenIPMI и freeipmi. Так как это просто пример, вы можете свободно использовать любой другой инструмент.

Перед началом работы с Ganglia убедитесь, что IPMItool работает на вашей машине. Запустите команду ipmitool -c sdr type temperature | sed 's/ /_/g'; если команда не работает загрузите драйверы IPMI устройства и запустите её снова:

modprobe ipmi_msghandler
modprobe ipmi_si
modprobe ipmi_devintf

Результат выполнения команды ipmitool на моей машине выглядит так:

Ambient_Temp,20,degrees_C,ok
CPU_1_Temp,20,degrees_C,ok
CPU_2_Temp,21,degrees_C,ok

Итак, я с помощью модуля расширения Ganglia просто буду отслеживать температуру окружающей среды. Я создал довольно плохо написанный модуль расширения ambientTemp.py, использующий IPMI, взяв за основу модуль, найденный на wiki-страничке Ganglia. Вот он:

Листинг 1. Плохо написанный модуль расширения Python ambientTemp.py
import os
def temp_handler(name):
  # команды, которые мы собираемся выполнить
  sdrfile = "/tmp/sdr.dump"
  ipmitool = "/usr/bin/ipmitool"
  # Перед запуском нужно загрузить драйверы IPMI:
  # modprobe ipmi_msghandler
  # modprobe ipmi_si
  # modprobe ipmi_devintf
  # также надо выставить в nobody права доступа к файлу /dev/ipmi0:
  # chown nobody:nobody /dev/ipmi0
  # разместите это в /etc/rc.d/rc.local

  foo = os.path.exists(sdrfile)
  if os.path.exists(sdrfile) != True:
    os.system(ipmitool + ' sdr dump ' + sdrfile)

  if os.path.exists(sdrfile):
    ipmicmd = ipmitool + " -S " + sdrfile + " -c sdr"
  else:
    print "file does not exist... oops!"
    ipmicmd = ipmitool + " -c sdr"
  cmd = ipmicmd + " type temperature | sed 's/ /_/g' "
  cmd = cmd + " | awk -F, '/Ambient/ {print $2}' "
  #print cmd
  entries = os.popen(cmd)
  for l in entries:
    line = l.split()
  # print line
  return int(line[0])

def metric_init(params):
    global descriptors

    temp = {'name': 'Ambient Temp',
        'call_back': temp_handler,
        'time_max': 90,
        'value_type': 'uint',
        'units': 'C',
        'slope': 'both',
        'format': '%u',
        'description': 'Ambient Temperature of host through IPMI',
        'groups': 'IPMI In Band'}

    descriptors = [temp]

    return descriptors

def metric_cleanup():
    '''Очистка модуля метрик.'''
    pass

#Это код для отладки и юнит-тестирования
if __name__ == '__main__':
    metric_init(None)
    for d in descriptors:
        v = d['call_back'](d['name'])
        print 'value for %s is %u' % (d['name'],  v)

Скопируйте листинг 1 и сохраните его в /usr/lib64/ganglia/python_modules/ambientTemp.py. Сделайте это для всех узлов кластера.

Теперь, когда мы разместили скрипт на всех узлах кластера, сообщим Ganglia, как его нужно выполнять. Создадим новый файл /etc/ganglia/conf.d/ambientTemp.pyconf со следующим содержимым:

Листинг 2. Ambient.Temp.pyconf
modules {
  module {
    name = "Ambient Temp"
    language = "python"
  }
}

collection_group {
  collect_every = 10
  time_threshold = 50
  metric {
    name = "Ambient Temp"
    title = "Ambient Temperature"
    value_threshold = 70
  }
}

Сохраните листинг 2 на всех узлах.

И, наконец, перед перезапуском gmond надо выставить права на работу с устройством IPMI в nobody, чтобы никто не мог с ним работать. Иначе интерфейс IPMI станет очень уязвимым для атак злоумышленников!

Вот пример того, как это сделать: chown nobody:nobody /dev/ipmi0.

Теперь перезапустите gmond на всех машинах. Если все заработает, то, обновив окно браузера, вы должны увидеть что-то вроде этого:

Рисунок 5. Внутренние метрики IPMI
IPMI in-band metrics

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

Обратите внимание, что нам пришлось написать скрипт написан на Python, подготовить конфигурационный файл и задать в gmond.conf правильные настройки. Мы сделали только одну метрику! Только подумайте о том, сколько всего нужно будет сделать, чтобы написать другие метрики! Выполнение такой работы на каждой машине для каждой метрики может быть весьма утомительным. IPMI - это внешний инструмент, поэтому должен быть какой-то способ лучше, не так ли? Совершенно верно.


Внешние модули расширения (использование техники подмены узла)

Host spoofing - это именно то, что нам надо. Мы воспользуемся программой gmetric - мощным инструментом командной строки для добавления информации в Ganglia, и сообщим ему на каких машинах мы работаем. Таким способом мы можем наблюдать за всем, чем угодно.

Что самое лучшее в gmetric? Огромное количество уже написанных скриптов.

В качестве учебного примера я вместе с вами переоткрою способ запускать ipmitool для получения удаленного доступа к машинам:

  1. Убедитесь, что ipmitool работает сам по себе.

Я настроил BMC (контроллер мониторинга на целевой машине) так, чтобы иметь возможность запускать на нем команды IPMI. Например, мой сервер мониторинга называется redhouse. С redhouse я хочу наблюдать за всеми остальными узлами кластера. Именно на redhouse запущен gmetad и именно с него я через web браузер буду получать всю информацию о Ganglia.

Один из узлов моего кластера называется x01. На x01 я установил для ВМС IP-адрес, разрешающийся в имя x01-bmc. Вот я пытаюсь получить удаленный доступ к этой машине:

# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD sdr dump \ /tmp/x01.sdr
Dumping Sensor Data Repository to '/tmp/x01.sdr'
# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD -S /tmp/x01.sdr \ sdr type 
                                                                            Temperature
Ambient Temp     | 32h | ok  | 12.1 | 20 degrees C
CPU 1 Temp       | 98h | ok  |  3.1 | 20 degrees C
CPU 2 Temp       | 99h | ok  |  3.2 | 21 degrees C

Выглядит здорово. Теперь давайте поместим это в скрипт и передадим его в gmetric.

  1. Делаем скрипт, который передает информацию от ipmitool в gmetric.

Создадим следующий скрипт и разместим его на сервере мониторинга по пути usr/local/bin/ipmi-ganglia.pl:

#!/usr/bin/perl
# vallard@us.ibm.com
use strict;  # чтобы сделать все чище
use Socket;  # для разрешения имен в IP-адреса

# для зачистки после ветвлений
use POSIX ":sys_wait_h";
# nodeFile: это простой текстовый файл со списком узлов:
# например:
# node01
# node02
# ...
# nodexx
my $nodeFile = "/usr/local/bin/nodes";
# бинарный файл gmetric
my $gmetric = "/usr/bin/gmetric";
# бинарный файл ipmitool
my $ipmi = "/usr/bin/ipmitool";
# id пользователя для BMC
my $u = "xcat";
# пароль для BMC
my $p = "f00bar";
# открываем файл со списком узлов и проходим по всем узлам
open(FH, "$nodeFile") or die "can't open $nodeFile";
while(my $node = <FH>){
  # делаем ветвления (fork), чтобы каждый удаленный вызов выполнялся параллельно
  if(my $pid = fork()){
    # родительский процесс
    next;
  }
  # здесь начинается порожденный процесс
  chomp($node);  # убираем символы новой строки
  # разрешаем IP адрес узла и подменяем его
  my $ip;
  my $pip = gethostbyname($node);
  if(defined $pip){
    $ip = inet_ntoa($pip);
  }else{
    print "Can't get IP for $node!\n";
    exit 1;
  }
  # проверяем, существует ли файл кэша SDR.
  my $ipmiCmd;
  unless(-f "/tmp/$node.sdr"){
    # кэша SDR нет, поэтому попробуем его создать...
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p sdr dump /tmp/$node.sdr";
    `$ipmiCmd`;
  }
  if(-f "/tmp/$node.sdr"){
    # выполняем команду для кэша, так как это быстрее
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p -S /tmp/$node.sdr sdr type 
                                                                       Temperature ";
    # помещаем весь результат в массив @out
    my @out = `$ipmiCmd`;
    # проходим по элементам массива @out.
    foreach(@out){
      # каждая строка результата выглядит так:
      # Ambient Temp     | 32h | ok  | 12.1 | 25 degrees C
      # мы разбираем строку следующим образом:
      chomp(); # убираем символ новой строки
      # выбираем первое и пятое поля.  (Description и Temp)
      my ($descr, undef, undef, undef,$temp) = split(/\|/);
      # убираем пробелы в описании
      $descr =~ s/ //g;
      # выбираем только температуру (полагая ее всегда в градусах Цельсия С)
      $temp = (split(' ', $temp))[0];
      # убеждаемся, что температура является числом:
      if($temp =~ /^\d+/ ){
        #print "$node: $descr $temp\n";
        my $gcmd = "$gmetric -n '$descr' -v $temp -t int16 -u Celcius -S $ip:$node";
        `$gcmd`;
      }
    }
  }
  # порожденный поток завершается.
  exit;
}
# ждем окончания всех ветвлений fork...
while(waitpid(-1,WNOHANG) != -1){
  1;
}

Помимо разбора строк, скрипт просто запускает команду ipmitool и получает с ее помощью значения температуры. Затем для каждой метрики с помощью команды gmetric он помещает эти значения в Ganglia.

  1. Запускаем скрипт как задачу cron.

Запустите crontab -e. Я добавил следующую строку, чтобы скрипт запускался каждые 30 минут: 30 * * * * /usr/local/bin/ipmi-ganglia.sh. Если хотите, вы можете задать его выполнение чаще или реже.

  1. Открываем Ganglia и смотрим на результаты.

Открыв в web браузере Ganglia и взглянув на графики для одного из узлов, мы можем видеть, что произошла подмена и теперь для каждого узла на всех графиках показано подмененное имя:

Рисунок 6. Метрика no_group
The no_group metrics

Одним из недостатков подмены узла является то, что таким метрикам присваивается категория no_group. В gmetric, похоже, нет красивого способа изменить группировку, как в случае внутренних расширений.


Что дальше

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

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

Во второй части этой серии статей рассказывается о работе с Nagios и его интеграции с Ganglia, включая:

  • Базовую установку Nagios и настройку оповещений
  • Мониторинг коммутаторов и другой инфраструктуры
  • Встраивание оповещений Nagios в Ganglia

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

Ресурсы

Научиться

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

  • Загрузите Ganglia 3.1.1 (EN).
  • RDDTool (Round Robin Database Tool) был создан Тобиасом Этикером (биография); он применяется во многих высокопроизводительных системах мониторинга (EN).
  • Gmetric (EN) - это инструмент командной строки для занесения информации в Ganglia, который имеет множество скриптов, помогающих реализовать подмену узлов.
  • Другие инструменты мониторинга:
  • Разработайте ваш следующий Linux-проект с помощью ознакомительного ПО от IBM, которое можно загрузить непосредственно с сайта developerWorks.

Обсудить

Комментарии

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=392461
ArticleTitle=Ganglia и Nagios: Часть 1. Мониторинг коммерческих кластеров с помощью Ganglia
publish-date=05282009