Простейший моделер для zenoss или грязный путь в светлое будущее

Мониторинг
(от лат. monitor — тот, кто напоминает, предупреждает) — комплексная система регламентированных периодических наблюдений, оценки и прогноза изменений состояния среды c целью выявления негативных изменений и выработки рекомендаций по их устранению или ослаблению.

Вступление и общие слова

На хабре удивительно немного статей по zenoss, хотя эта система мониторинга наголову опережает по функциональности большинство своих конкурентов. Само описание системы всегда можно найти на официальном сайте Zenoss ^[1]

Почему я считаю, что Zenoss опережает конкурентов? Потому что его легко конфигурировать и получать нужные именно вам системы наблюдения, оповещения и реагирования на оповещения. В Zenoss разумно сочетается гибкость, функциональность и сложность. Последняя растёт пропорционально вашим запросам: следить за местом на жёстком диске — легче лёгкого, мониторить программно-аппаратные комплексы по собственным метрикам— значительно сложнее.

В сети есть множество гайдов по первоначальной настройке системы. Пройдя по этим гайдам вы сможете легко начать мониторить свои сервера или коммуникационное оборудование по основным параметрам.
Я предпочитаю использовать zenoss с snmp серверами на оборудовании. SNMP сервер — прост в настройке (simple в названии относится не только к самому протоколу ;), надёжен, позволяет разметить основные права доступа к предоставляемой информации и вообще — common software. Кроме того, snmp, в том или ином виде, поддерживается большей частью оборудования.
Системы мониторинга со своими агентами меня несколько нервируют: никогда не знаешь, что в этом агенте делается и как хорошо.
Если для нужных вам параметров ещё нет стандартных snmp агентов, вы можете реализовать свой на основе встроенного в net-snmp механизма agentx. Подробнее с agentx агентами можно познакомиться в гайде www.net-snmp.org/tutorial/tutorial-5/toolkit/ ^[2] (Коллега подсказывает: лучше смотреть code.google.com/p/linux-administrator-tools/source/browse/#svn%2Fsnmpd-agent%2Ftrunk ^[3]: документация там хромает, зато весь код рабочий.) Приложив небольшое количество усилий, вы сможете мониторить всё то, статус чего можно получить программно из системы, и отдавать эту информация по 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 ^[4] ­— количество деградировавших логических томов для megaraid адаптера
.1.3.6.1.4.1.3582.5.1.4.1.1.3.1.20.0 ^[5] — количество деградировавших логических том для 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 и там добавляем новое правило. Правим и получаем что-то в духе:
^[6]

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

На этом этапе можно повесить полученный шаблон на определённый класс устройств и успокоиться. Но это не наш метод. Далее самое интересное: свой простейший моделер и зенпак.

Создание плагина моделера.

Вот и самое интересное. Создадим свой 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