Испытываем Antmon — новую систему мониторинга

СЕРГЕЙ ЖУМАТИЙ

Испытываем Antmon – новую систему мониторинга

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

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

Но все знают, какая свистопляска начинается, если выходит из строя сервер. Нет выхода в Интернет, не печатает принтер, повисла база и т. п.

Можно ли как-то застраховаться от подобной ситуации? Конечно, можно! Достаточно установить систему мониторинга. Систему, которая может обнаружить (а зачастую и предсказать) проблему и сообщить об этом администратору до того, как появились разгневанные пользователи. Умело настроенная система позволит не только сигнализировать о наличии проблемы, но и подсказать, почему, а также предпринять соответствующие действия. А при ещё более умелом использовании сделает простейшие шаги сама, например, перезапустит сервис.

Какие системы мониторинга бывают

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

Из заслуженно известных систем стоит упомянуть PIKT, OpenView и Nagios. Последние два продукта, кроме широкой функциональности, имеют и разветвлённые средства визуализации. Какому админу не будет приятно посмотреть на красивую картинку своей сети?

К недостаткам Nagios, да и большинства других систем мониторинга (к примеру, snmp-обработчики открытых snmp-серверов) можно отнести реализацию процедуры сбора не «вшитых» намертво параметров. Каждый модуль для мониторинга нового параметра (или группы параметров) представляет собой отдельную программу, которая запускается всякий раз, когда необходимо получить значения параметров. А если таких параметров десяток и не на одном, а нескольких серверах? Для серьёзного мониторинга сервера нужно снимать данные по температурам, скорости вращения вентиляторов, загрузке процессоров, объёмам передаваемых данных. А к тому же неплохо бы смотреть активность сервисов (кто «съел» всю память – почтовик, база данных или самописный сервер приложений?). А если надо собирать статистику не только по доступности какого-либо сервиса, но и локальные данные на удалённых серверах? К примеру, свободный объём на диске или температуру процессора?

Накладных расходов набегает немало, и каждый раз запускать десяток программ становится накладно. Да и запускаются все они на головной машине, проверяя параметр удалённо.

Есть способы решения этих проблем. Например, написать свой сервис, который будет снимать нужные данные и отдавать их по SNMP. Решение хорошее, но что если на сервере уже есть сервис для SNMP? Весьма вероятно, что будет иметь место конфликт по портам. Можно повесить свой сервер SNMP и на нестандартный порт, но тогда агенту мониторинга надо будет объяснять, что одни данные надо с этого порта брать, а другие – с того... Есть серверы SNMP, которые допускают подключение внешних обработчиков, но все такие обработчики для получения одного значения каждый раз запускают отдельный процесс, а если их с десяток и опрашивать их надо часто? Да и написать такой сервис тоже дело не получаса... Многие наверняка скажут: «Ничего, мы же пользуемся». Не буду спорить, во многих случаях подход себя оправдывает (всё-таки SNMP именно для этого и создавался), но, как показывает практика, не всегда. К примеру, получение по SNMP статистики с коммутатора 3Com 3300 по всем портам может занять около минуты – проверено. А это далеко не всегда хорошо.

OpenView является коммерческим продуктом и полностью основан на использовании SNMP. Если вы используете серьёзные дорогостоящие системы хранения и базы данных, то, скорее всего, у вас уже есть поддержка агентов для OpenView, и его использование будет весьма продуктивно. Однако, чтобы добавить к нему своего агента для съёма нестандартных параметров (OpenView позволяет это делать), придётся изрядно попотеть... Взять хотя бы минимальные требования для пакета OpenView Operations, который необходим для разработки: HP-UX version 11.0, 11.11/Solaris 8,9, 1 GB dedicated RAM/5 GB for management server installation, Oracle 9i Enterprise.

Вышесказанное не уменьшает достоинств упомянутых систем мониторинга. Но когда мне пришлось контролировать несколько десятков узлов вычислительного кластера и серверы для его поддержки, оказалось, что требования к системе мониторинга довольно высоки, и мало какие из существующих систем могут им удовлетворить. Особенно если добавить требование повышенной надёжности. Что делать, если завис или оказался недоступен сервер с головным монитором? Если канал в Интернет «умер»? Тогда админ уже ничего не узнает.

Система Antmon

Для решения обозначенных проблем я создал систему мониторинга Antmon (http://parcon.parallel.ru/antmon). Она была создана под конкретный комплекс, но заложенные в неё принципы построения дают ей очень широкие (как я полагаю) возможности применения. Пока и головные серверы, и агенты системы работают только под UNIX-совместимыми операционными системами, под Windows они не тестировались, но порт агента и головного сервера под эту платформу планируется в самое ближайшее время. Кроме того, система продолжает развиваться, и я всегда открыт пожеланиям.

Кратко сформулирую требования, которые легли в основу Antmon:

• лёгкая расширяемость (написать модуль расширения для снятия нестандартных параметров или реакции на нештатную ситуацию должно быть по силам среднему программисту);
• нетребовательность к ресурсам (затраты на работу мониторов должны быть минимальны);
• высокая стабильность (отказ головного сервера не должен приводить к полному отказу системы, по крайней мере администратор должен узнать об этом первым).

Рассмотрим общую архитектуру системы Antmon и заодно увидим, как в ней удовлетворяются сформулированные требования.

Структура комплекса Antmon

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

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

Возможности расширения Antmon

Система Antmon не имеет жёстко «вшитых» средств мониторинга, кроме проверки доступности удалённого агента. Поэтому всегда можно настроить систему под конкретные требования и не иметь дела с избыточными для вас данными.

Все параметры мониторятся агентами с помощью подключаемых модулей. Каждый модуль – программа, запускаемая один раз при первом запросе параметра. После запуска программа сообщает агенту Antmon, какие параметры она способна мониторить. После этого агент по мере необходимости в цикле даёт модулю на стандартный ввод запрос в виде списка имён параметров и ждёт от модуля на стандартном выводе список результатов.

Если модуль возвращает некорректные результаты, зависает или просто падает, то агент пытается перезапустить его. Если же ответ от модуля не будет получен и после этого агент вернёт серверу ответ «сенсор недоступен».

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

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

Благодаря таким простым требованиям модуль для Antmon может быть написан практически на любом языке, и навыки программиста для его написания должны быть минимальны (главное – запрограммировать съём значений параметров). В поставку входит набор готовых модулей, которые могут быть легко модифицированы и использованы для написания собственных.

За счёт того, что модули запускаются единожды и активизируются только по запросу агента, накладные расходы на мониторинг на сервере сводятся к минимуму.

Обработка событий

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

Обеспечение надёжности

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

В конфигурации головных серверов указывается, какие параметры могут быть переданы дублирующим серверам (ведь дублирование не всегда возможно, например, из-за firewall). В любом случае дублирующие серверы отреагируют на сбой одного из своих «собратьев».

За счёт использования нескольких головных серверов можно, к примеру, проводить мониторинг в нескольких виртуальных сетях, попутно контролируя их доступность через NAT и заодно работоспособность веб-сайта компании.

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

Примеры

Вот пример конкретного конфигурационного файла с комментариями.

Листинг 1. Кольцевая конфигурация

heads head1 head2 serv

# Используем 3 головных сервера с именами head1, head2 и serv

topo 1 2 3 2

# Описываем топологию.

# Кратко – 1–й сервер будет посылать пакеты 2–му для подтверждения того, что он «жив», 2–й – 3–му, а 3–й – 2–му.

#

# Если 1–й сервер откажет, об этом узнает только 2–й (но он «расскажет» 3–му)

head_ping 120

# Посылаем ping (точнее keep_alive) остальным серверам каждые 2 минуты

head_tmout 300

# Если в течение 5 минут нет сигнала от другого сервера, он считается сбойным

action mail_servfail action_mail root@superserver.ru

action_line Server $addr fails.

# Описываем действие – передать на вход модулю action_mail указанную строку, сам модуль action_mail

# запускается с параметром – адресом администратора

action mail_status action_mail root@superserver.ru

action_line $name on server $addr is $state

# Ещё одно действие – тоже отсылка письма

action down action_shutdown

action_line $addr

# Другой вариант реагирования – зайти на указанный сервер по ssh и выполнить shutdown

action log action_log /var/log/Antmon_log

action_line $addr $name $val $state

# Реагирование в виде записи в файл журнала

on_head_death mail_servfail

# В случае сбоя головного сервера оповестить администратора с помощью описанного выше действия mail_servfail

#####################################################

# Описание параметров мониторинга.

# Все инструкции описывают шаблон для параметра – диапазон значений, реакции на события и т. п.

#

# Инструкции names или addr_set «актуализируют» шаблон, реализуя описанные параметры на сервере из инструкции

# addresses или на указанных серверах с именем из инструкции name соответственно.

#

# Шаблон не обнуляется после «актуализации», так что нет необходимости описывать каждый параметр

# заново – достаточно модифицировать предыдущий

addressess host1

# Имя хоста, на котором работает агент

min 200

max 200

# Диапазон допустимых значений кода веб–страницы

min_ret 200

max_ret 200

# Диапазон значений для возврата в состояние «ОК»

bad_count 2

# Один сбой странички допускаем, 2 – уже нет

ret_cout 1

# Для возврата в состояние «ОК» достаточно одного «хорошего» результата её опроса

on_fail mail_state log

# При сбое – информировать администратора и сделать запись в журнале

on_ret mail_state log

# При возврате в состояние «ОК» – тоже address serv1 проверять будем на агенте на head1

mons 1 2

# Проверять могут мониторы head1 и head2.

# head1 имеет приоритет

names http.antmod test_url

# Формат: имя модуля [аргументы] название

# В этот момент происходит объявление сенсора с указанным именем на агенте по адресам, указанным в последней

# инструкции addr либо addresses (тогда объявляются сенсоры на всех перечисленных хостах)

addresses host1 host2 host3

min 5000

max 100000

min_ret 5500

max_ret 100000

ret_count 2

# Меняем параметры сенсоров.

# Описанные ранее параметры, которые не изменены, не сбрасываются!

# Проверяем на 3-х хостах

on_fail down

mons 2 3

# Ответственные мониторы – head2 и serv.

# head2 имеет приоритет

names fans.antmod w83781-isa-0290 w83781-isa-0290 fan1

# Объявляем сенсор

adsdresses node1 node2 node3 node4

# Объявляем сенсоры с указанным ранее в инструкции names именем на узлах node1-node4

#

# Проверяем вентилятор процессора на узлах node1-node4, используя их локальные агенты

В этом примере всего два сенсора. Один из них (доступность веб-страницы) контролируется сервером head1 и страхуется сервером head2, а второй – сервером head2 и страхуется сервером serv.

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

Ещё один пример, чуть сокращённый – конфигурация мониторинга трёх площадок с контролем доступности друг друга (предполагается, что VPN они не соединены).

Листинг 2. Три площадки

heads site1 site2 site3

# Головные сервера площадок – site1, site2 и site3

topo 1 2 3 1

# Все контролируют друг друга

action mail_fail action_mail root@superserver.ru

action_line $name fails.

action sms_servfail action_sms 1234567

action_line Server $addr fails.

action log action_log /var/log/Antmon_log

action_line $addr $name $val $state

action restart_base action_baserst

action_line restart

on_head_death sms_servfail

# Шлём sms, если один из серверов помер

addr 192.168.10.10

# Сервер баз данных

min 0

max 0

# Код успешного статуса базы данных

min_ret 0

max_ret 0

# Диапазон значений для возврата в состояние «ОК»

bad_count 1

# Первый же сбой фатален

ret_cout 1

on_fail mail_fail restart_base log

# При сбое базы – перестартовать её.

# Информировать администратора и сделать запись в журнале

on_ret log

mons 1

# Проверять будет только site1

names dbcheck.antmod database

addr 1.2.3.4

# Вторая площадка с реальными адресами

on_fail mail_fail log

mons 2 1 3

# Первая и третья площадки могут быть «на подхвате»

names smtp.antmod mail.myserv.ru; http.antmod www.myserv.ru

# В инструкции names можно определить и несколько сенсоров

addr 5.6.7.8

# Третья площадка с реальными адресами

mons 3 2 1

names smtp.antmod mail.serv2.ru; http.antmod www.serv2.ru

# За этот сенсор ответственны все

mons 3

min 0

max 70

min_ret 0

max_ret 60

names fantemp.antmod w83781-isa-0290 w83781-isa-0290 fan1

# Вентилятор на 5.6.7.8 контролирует только site3

Заметим, что все сенсоры, кроме вентилятора на третьей площадке, имеют два состояния – 0 и 1. 0 означает нормальную работу. Поэтому диапазон «хороших» значений (0-0) прописывается один раз и потом просто наследуется сенсорами, объявляемыми позднее до тех пор, пока этот диапазон не переопределяется.

Другой пример – мониторинг состояния вычислительного кластера из 8 узлов, его доступности извне (с внешнего сервера в другой сети) и проверка работоспособности сайта кластера. Сейчас вычислительные кластеры отнюдь не редкость, так что пример может быть весьма показателен.

Листинг 3. Кластер и внешняя площадка.

heads clusterhead friend.ru

topo 1 2 1

# Оба контролируют друг друга

action mail_fail action_mail root@superserver.ru

action_line $name fails.

action sms_servfail action_sms 1234567

action_line Server $addr fails.

action log action_log /var/log/Antmon_log

action_line $addr $name $val $state

on_head_death sms_servfail

# Шлём sms, если один из серверов помер

on_fail action_log mail_fail

on_ret action_log

addresses node1 node2 node3 node4 node5 node6 node7 node8

mons 1

min 0

min_ret 0

max 2.3

max_ret 1.9

# Максимально допустимая нагрузка на 2-процессорный узел

bad_count 3

ret_cout 2

names sysstat.antmod loadavg

max 70

# Максимальная температура

names fantemp.antmod w83781-isa-0290 w83781-isa-0290 fan1

max 2

bad_count 1

ret_cout 1

names sysstat.antmod eth0_rcv_errs

names sysstat.antmod eth0_sent_errs

names sysstat.antmod eth0_sent_colls

names sysstat.antmod nfs_retrans

on_fail mail_fail log

on_ret log

mons 1 2

min 200

min_ret 200

max 201

max_ret 201

addresses localhost

# Небольшое жульничество, каждый головной сервер будет опрашивать локального агента, но сначала это будет

# делать только первый

names http.antmod www.server.com

Можно отметить, что на второй площадке ничего не описано. Она существует для контроля доступности первой, и своих сенсоров не опрашивает. Если первая работает – всё ОК, если нет – вторая берёт на себя контроль за работоспособностью сайта и сообщает админу о случившемся.

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

Недостатки Antmon

Отмечу и недостатки. Система Antmon пока не работает на платформе Windows (хотя я не проверял вариант компиляции под cygwin). Кроме того, полный перенос логики на головные сервера имеет свою отрицательную сторону – излишнюю передачу данных для некоторых видов параметров мониторинга. Иногда удобнее, чтобы агент сам определял валидность параметра и только в случае смены его статуса (OK  FAIL, например) информировал об этом головной сервер, аналогично механизму Trap в SNMP. В систему Antmon уже заложена основа для реализации такой схемы работы (параллельно с вышеописанной).

Заключение

Несмотря на то что Antmon имеет некоторые минусы (а у кого их нет?) и не так хорошо обкатана, как многие другие системы мониторинга, она может стать хорошим подспорьем в работе администратора. К тому же система будет развиваться, а значит становиться ещё удобнее. На её освоение не требуется много времени, как и на доводку под свои специфичные нужды.

Надеюсь, для многих администраторов Antmon сможет сослужить добрую службу.