Мониторинг
(от лат. monitor — тот, кто напоминает, предупреждает) — комплексная система регламентированных периодических наблюдений, оценки и прогноза изменений состояния среды c целью выявления негативных изменений и выработки рекомендаций по их устранению или ослаблению.
Вступление и общие слова
На хабре удивительно немного статей по zenoss, хотя эта система мониторинга наголову опережает по функциональности большинство своих конкурентов. Само описание системы всегда можно найти на официальном сайте Zenoss
Почему я считаю, что Zenoss опережает конкурентов? Потому что его легко конфигурировать и получать нужные именно вам системы наблюдения, оповещения и реагирования на оповещения. В Zenoss разумно сочетается гибкость, функциональность и сложность. Последняя растёт пропорционально вашим запросам: следить за местом на жёстком диске — легче лёгкого, мониторить программно-аппаратные комплексы по собственным метрикам— значительно сложнее.
В сети есть множество гайдов по первоначальной настройке системы. Пройдя по этим гайдам вы сможете легко начать мониторить свои сервера или коммуникационное оборудование по основным параметрам.
Я предпочитаю использовать zenoss с snmp серверами на оборудовании. SNMP сервер — прост в настройке (simple в названии относится не только к самому протоколу ;), надёжен, позволяет разметить основные права доступа к предоставляемой информации и вообще — common software. Кроме того, snmp, в том или ином виде, поддерживается большей частью оборудования.
Системы мониторинга со своими агентами меня несколько нервируют: никогда не знаешь, что в этом агенте делается и как хорошо.
Если для нужных вам параметров ещё нет стандартных snmp агентов, вы можете реализовать свой на основе встроенного в net-snmp механизма agentx. Подробнее с agentx агентами можно познакомиться в гайде www.net-snmp.org/tutorial/tutorial-5/toolkit/ (Коллега подсказывает: лучше смотреть code.google.com/p/linux-administrator-tools/source/browse/#svn%2Fsnmpd-agent%2Ftrunk: документация там хромает, зато весь код рабочий.) Приложив небольшое количество усилий, вы сможете мониторить всё то, статус чего можно получить программно из системы, и отдавать эту информация по snmp через стандартный snmp сервер.
Итак, на этом вступление можно считать оконченным. Резюме: мне нравится zenoss и snmp. Перейдём к zenoss плотнее.
Конфигурирование zenoss под себя
Простейший путь настройки zenoss повторяет путь настройки любых других систем мониторинга:
- добавить устройство
- определить контролируемые, ключевые параметры
- повторить для каждого устройства
Если у вас 2 свича и 5 серверов, это делается легко, 1 раз и навсегда. Если же у вас десятки серверов и часть из них «ротируется» (например, у вас есть виртуальные машины, которые то появляются в сети, то выключаются за ненадобностью), то добавление и удаление устройств и параметров мониторинга превращается в каторгу.
Поэтому, современные системы мониторинга, такие как zabbix и zenoss имеют функциональность автообнаружения устройств: задаёте диапазон ip адресов для поиска, параметры доступа и voilà, найденное оборудование добавлено в систему. Осталось навесить на него шаблоны мониторинга.
Навешивать шаблоны — тоже грустное занятие. Разметьте хосты по группам или классам и повесьте шаблоны на них. Тогда будет достаточно определить класс устройства и к нему применятся соответствующие правила мониторинга.
Что делать, если у нас есть десяток правил, которые вешаются на хосты «хаотично»? Так, что нельзя чётко составить классы устройств. Можно пойти дальше и описать для системы правила назначения шаблонов мониторинга. В Zenoss процесс определения состава мониторинга называется "моделированием устройства": zenoss опрашивает snmp сервер, определяет доступные параметры и мониторит их, если есть правила мониторинга.
Сами правила мониторинга предоставляются ZenPack'ами. Zenpack — способ распространения собственных расширений стандартной функциональности. В нём могут содержаться классы событий, шаблоны мониторинга, плагины моделера, описания кнопок интерфейса и многое другое.
Правильный способ расширения функций мониторинга — определение наличия тех или иных компонентов на хосте и привязка к ним графиков и событий (event'ов). Правильный zenpack — штука не то чтобы сложная, но объёмная. Далеко не все согласны долго что-то изобретать. Я продемонстрирую «quick&dirty» способ добиться своего.
Основная концепция
Писать собственные компоненты и плагины моделера — сложно. Вешать везде руками шаблоны мониторинга — долго. Давайте совместим эти два подхода: их минусы в итоге дадут плюсы: моделер будет простым, его код я приведу ниже, а созданные единожды шаблоны будут вешаться на устройства автоматом: если моделер будет находить нужные oid'ы в ответах snmp сервера, он будет навешивать определённый шаблон мониторинга.
Почему это быстро: нам потребуется создать 2 шаблона и 1 моделер и сконфигурить плагин моделера для 1 класса устройств (Device->Server). Быстро, просто, легко, переносимо (с помощью ZenPack'ов).
Почему это «грязно»: мы будем следить за RAID контроллером LSI. Первым и единственным. Если таких контроллеров много, они не будут покрыты системой наблюдения, для них придётся создавать отдельные шаблоны и моделеры. Подход с созданием собственных компонентов более гибкий: он позволил бы описать компонент «дисковый контроллер lsi», обнаружить и замониторить все подобные контроллеры.
Реализация
SNMP часть
Итак, у меня было несколько linux серверов с RAID-контроллерами фирмы LSI. Часть из них работала на драйвере megaraid, часть — на mptsas. После некоторых мучений я нашёл snmp агенты для получения информации о состоянии массивов: sas_snmp-3.17-1123.i386.rpm и sas_ir_snmp-3.17-1126.i386.rpm (да, 32х битные, других не нашлось). После их установки snmp сервер способен отдавать oid из деревьев
.1.3.6.1.4.1.3582.4 и .1.3.6.1.4.1.3582.5 соответственно.
Среди этих деревьев можно найти:
1.3.6.1.4.1.3582.4.1.4.1.2.1.19.0 — количество деградировавших логических томов для megaraid адаптера
.1.3.6.1.4.1.3582.5.1.4.1.1.3.1.20.0 — количество деградировавших логических том для mpt адаптера.
Это хорошие «интегральные» метрики, которые позволят обратить внимание системного администратора на сервер в случае проблем: вылетел диск — логические тома, в которые он включен, станут деградировавшими и поднимут метрику с нуля.
Описывать установку пакетов не стану, она тривиальна, если вы знаете название пакетов и чем sas_snmp отличается от sas_ir_snmp.
Zenoss часть
В Zenoss нам придётся создать два шаблона — для megaraid и mpt драйверов, и сконфигурировать для них два treshold'а.
Идём в Advanced -> Monitoring Templates и нажимает снизу кнопку "+". В появившемся окне вводим имя — «lsiArray», и выбираем путь — «Server in Devices».
После этого появится окно, разделённое на три части: data sources, tresholds и graph definitions. Нам потребуются первые два:
- Создаём источник данных. Имя «vdDegradedCount», как в mib (но можно и другое). Источник — SNMP
- Редактируем только что созданный источник данных: вписываем наш первый OID. В том же окне можем потестить на каком-либо сервере
- Создаём treshold, даём ему имя «LSI Degraded virtual drive count», и тип MinMaxTreshold
- Редактируем созданный treshold: выбираем единственную data point, задаём минимальные и максимальное значение в 0, обозначаем класс события (я выбрал /HW/Store). Класс события потребуется при настройке оповещения
После всех этих действий у нас есть шаблон, который мониторит megaraid'овский контроллер и генерирует событие в случае проблем с ним.
Конфигурирование второго шаблона я оставлю как упражнение для читателя: ничего сложного в этом нет.
Можем сконфигурировать отсылку сообщения для этого события. Идём в Advanced -> Settings -> Users -> $Your-user -> Alerting rules и там добавляем новое правило. Правим и получаем что-то в духе:
Обратите внимание на указания «важности» события и начала цепочки классов для события, по которому генерируется оповещение.
На этом этапе можно повесить полученный шаблон на определённый класс устройств и успокоиться. Но это не наш метод. Далее самое интересное: свой простейший моделер и зенпак.
Создание плагина моделера.
Вот и самое интересное. Создадим свой Zenpack! Zenpack создаст необходимую нам структуру каталогов, в которую мы поместим исходный код плагина для моделера. Кроме того, мы сможем выгрузить наш плагин из системы в составе этого Zenpack'а.
Итак, идём в Advanced -> Settings ->Zenpacks и там нажимаем на шестерёнку. В появившемся меню выбираем «Create Zenpack». Появится окно с вводом названия. Я выбрал ZenPacks.HW.Store.LSIArray. Хотя, как выяснилось позже, это не совсем верное название: надо было вписать туда хотя бы слово community перед HW.
После создания zenpaka на винте появится стандартное дерево файлов. Нам потребуется создать файл /opt/zenoss/ZenPacks/ZenPacks.HW.Store.LSIArray-*egg/ZenPacks/HW/Store/LSIArray/modeler/plugins/LSIArray.py (подправьте звёздочку под созданный класс) со следующим содержимым:
__doc__="""LSIArray
LSIArray modeller maps sas and sasir (mptsas) specific templates
$Id: LSIArray.py,v 2.00 2012/04/15 16:01 Exp $"""
__version__ = '$Revision: 2.15 $'
from Products.DataCollector.plugins.CollectorPlugin import SnmpPlugin, GetTableMap, GetMap
from Products.DataCollector.plugins.DataMaps import ObjectMap
class LSIArray(SnmpPlugin):
deviceProperties = SnmpPlugin.deviceProperties + ('zDeviceTemplates',)
mibDesc = {
'.1.3.6.1.4.1.3582.4.1.4.1.2.1.19.0': 'lsiArray',
'.1.3.6.1.4.1.3582.5.1.4.1.1.3.1.20.0': 'lsiirArray',
}
snmpGetMap = GetMap( mibDesc )
def process(self, device, results, log):
"""collect snmp information from this device"""
log.debug(str(self.deviceProperties))
log.info('processing %s for device %s', self.name(), device.id)
getdata, tabledata = results
log.debug(str(device.zDeviceTemplates))
newTemplates = []
rmTemplates = []
log.debug('getdata %s mibDesc %s', str(getdata),str(LSIArray.mibDesc))
if len(getdata.keys()) == getdata.values().count(None):
log.info('no data')
return
for each in LSIArray.mibDesc.values():
if getdata.has_key(each) and getdata[each] != None:
newTemplates.append(each)
log.debug('newTemplates append: %s' % each)
else:
rmTemplates.append(each)
log.debug('rmTemplates append: %s' % each)
log.info('Current zDeviceTemplaces: %s' % str(device.zDeviceTemplates))
for each in device.zDeviceTemplates:
if each not in newTemplates and each not in rmTemplates:
newTemplates.insert(0,each)
log.debug('adding to newTemplaces: %s' % str(each))
device.zDeviceTemplates=sorted(newTemplates)
log.info('New zDeviceTemplates: %s' % str(device.zDeviceTemplates))
om = self.objectMap({'bindTemplates': newTemplates})
return om
В исходном коде всё достаточно просто.
В начале комментарий с описанием, что делает класс.
Потом импорт некоторых zenoss'ных классов, для описания модели устройства.
Объект «mibDesc» — самое интересное. Он содержит список oid'ов и соответсвующие им шаблоны мониторинга. Если при опросе устройства нашёлся нужный oid, на устройство будет повешен новый шаблон мониторинга.
Когда будете править пример под себя, постарайтесь не пропустить все знаки препинания в тексте.
Дальше — метод, который выполняет все проверки и сопоставления, а так же сохраняет все предыдущие шаблоны мониторинга и дописывает в список свой. Результатом работы этого метода является модель объекта (om).
Проверка плагина
После того, как вы скопировали, поправили и сохранили текст моделера, необходимо перезапустить zenoss (процесс zopectl в Advanced -> Settings -> Daemons) и проверить, что в списке плагинов моделера появился новый, с названием LSIArray (в плагинах моделера любого класса устройств или в любом устройстве). Плагин нужно перенести в активные и запустить моделинг устройства.
В появившемся на экране окне нужно проверить, чтобы моделер был в списке используемых для устройства. Кроме того, на жёстком диске создастся файл LSIArray.pyс, что свидетельствует об успешной компиляции скрипта.
Если скрипт не скомпилировался — проверяйте правильность питонового кода.
Если скрипт не появился в списке активных или доступных моделеров — перезапустите zenoss.
После процесса моделирования на устройство должен добавиться новый шаблон мониторинга. Теперь можно пойти и выдернуть жёсткий диск из тестового сервера, что переведёт состояние массива из «нормального» в «деградированное». (Если у вас не RAID0, конечно). Количество деградировавших логических томов увеличится, treshold будет превышен и система сгенерирует нам событие. Если Вы сконфигурировали оповещения, то придёт и оно.
Заключение
Описанный выше способ позволяет добиться нескольких важных результатов:
- Начать использовать автоматическое конфигурирование мониторинга в zenoss
- Начать разбираться в написании своих плагинов для моделера
- Популяризирует использование zenoss, как более гибкой и современной системы мониторинга
Я прекрасно знаю, что есть более полные и «правильные» гайды по написанию своих зенпаков и моделеров. Однако, надеюсь, что этот текст послужит толчком для многих системных администраторов начать изучать и использовать zenoss в своих системах.
Автор: oxpa
