Предыдущие части данной статьи: часть 1, часть 2, часть 3.
Тюнинг сбора и отображения SNMP-статистики
Настройки сбора информации, получаемой по протоколу SNMP, описываются в файле data-collection-config.xml. Данные собираются путем посылки GET-запросов, содержащих определенный OID (Object IDentificator), устройству, поддерживающему протокол SNMP. В ответ возвращаются некоторые значения, которые сохраняются затем в RRD-файлах (RoundRobin Database (RRD) – это проект, выросший из известного проекта MRTG. Проект оказался довольно удачным и в настоящее время используется не только в оpenNMS, но и во многих других системах мониторинга).
Пользуясь услугами Международной Логистической Торговой Компании контейнерные перевозки становятся быстрыми и надежными.
В файле data-collection-config.xml уже содержится информация по OID (Object ID) из MIB (Management Information Base) наиболее распространенных устройств (как аппаратных, например Cisco Pix, так и программных – Asterisk), поддерживающих протокол SNMP.
OID описываются внутри тега <mibObj>:
<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />
В свою очередь, для обеспечения более удобного дальнейшего использования OID группируются с помощью тега <group>, например:
<group name="my-mib2-interfaces" ifType="all">
<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />
</group>
Если параметру ifType тега <group> присвоено значение “all”, как в примере выше, это значит, что данные в группе имеют табличную природу, и тогда параметр instance тега <mibObj> принимает последовательные значения (в нашем случае ifIndex, содержащий индексы имеющихся в системе интерфейсов). Случай с нетабличными данными проще. Параметр ifType тега <group> принимает значение “ignore”, а параметр instance тега <mibObj> принимает значение “0″.
Различные типы SNMP-устройств описываются в тегах <systemDef>. Для каждого типа устройств определена одна или несколько OID-групп, на основе которых для устройства и его интерфейсов в rrd-файлы будет собираться статистика:
<systemDef name="Cisco Routers">
<sysoidMask>.1.3.6.1.4.1.9.1.</sysoidMask>
<collect>
<includeGroup>cisco-memory</includeGroup>
<includeGroup>cisco-router</includeGroup>
<includeGroup>cisco-temperature</includeGroup>
<includeGroup>cisco-voltage</includeGroup>
<includeGroup>cisco-router-interface</includeGroup>
<includeGroup>mib2-interfaces</includeGroup>
<includeGroup>adsl-line</includeGroup>
</collect>
</systemDef>
При обнаружении на устройстве службы SNMP система OpenNMS пытается определить тип устройства, посылая GET-запрос с OID=1.3.6.1.2.1.1.2.0. Полученный ответ сравнивается со значением тега <sysoidMask>, вложенного в тег <systemDef>.
Например, для многочисленного семейства маршрутизаторов фирмы Cisco этот ответ будет содержать подстроку .1.3.6.1.4.1.9.1. На основании такого ответа SNMP-сборщик будет собирать информацию, посылая GET-запросы с OID, описанными в конфигурации для данного типа оборудования.
В случае наличия специфичного оборудования можно создать дополнительные группы OID, а также определить с помощью тега <systemDef> новый тип оборудования, в который и вложить необходимые OID-группы. Обычно с таким специфичным оборудованием распространяются и дополнительные MIB-базы. Для ускорения импортирования данных OID из таких MIB-файлов в состав дистрибутива openNMS включена утилита mib2opennms, с помощью которой можно преобразовать данные из MIB-файла в набор тегов <mibObj>, которые используются в файле data-collection-config.xml.
Давайте теперь рассмотрим, как записываются и хранятся в RRD-файлах собранные по протоколу SNMP данные. Периодичность сбора данных, а также продолжительность их хранения описывается в теге <rrd>:
<rrd step="60">
<rra>RRA:AVERAGE:0.5:1:263520</rra>
<rra>RRA:AVERAGE:0.5:60:8784</rra>
<rra>RRA:AVERAGE:0.5:1440:366</rra>
<rra>RRA:MAX:0.5:1440:366</rra>
<rra>RRA:MIN:0.5:1440:366</rra>
</rrd>
Параметр step тега <rrd> определяет шаг хранения информации в rrd-файлах. Вложенный тег <rrа> состоит из следующих атрибутов:
RRA:Cf:xff:steps:rows
где:
- RRA – однозначно определяет строку как конфигурационную команду.
- cf – тип объединения данных, принимает значения AVERAGE, MAX, MIN или LAST.
- xff – при объединении собранных значений в одно может случиться, что некоторые значения не определены (например, какое-то время узел был недоступен). Данный параметр определяет минимальный процент неопределенных данных, при котором все собранные за период данные становятся неопределенными. По умолчанию это 50% (0,5).
- steps – означает коэффициент групировки собранных данных, например:
- 1 – данные сохраняются на каждом шаге (то есть ежеминутноо, в случае, step=60);
- 60 - данные группируются за 60 периодов и затем сохраняются(то есть интервал сохранения – 1 час).
- rows – определяет количество сохраняемых значений. Цифра 263520 означает, что данные, в случае ежеминутной группировки будут хранитьсяоколо полугода (188 дней).
Собранная в RRD-файлах информация может быть представлена в виде графиков. Настройка графиков на основе собранных по SNMP данных производится в файле snmp-graph.properties. В качестве значений секции reports через запятую перечислены все доступные графики. При первоначальной установке OpenNMS их уже достаточно внушительное количество. После перечисления всех графиков находится полная информация по каждому из графиков. Чтобы лучше понять принцип построения графиков, можно добавить график состояния интерфейса во времени, принимающий значение “0″ в случае “падения” интерфейса и “1″ – в случае его нормального функционирования. Для этого вернемся снова к файлу data-collection-config.xml, в который необходимо добавить соответствующий OID =.1.3.6.1.2.1.2.2.1.8, например, в группу mib2-interfaces:
<group name="mib2-interfaces" ifType="all">
<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />
<mibObj oid=".1.3.6.1.2.1.2.2.1.10" instance="ifIndex"
alias="ifInOctets" type="counter" />
<mibObj oid=".1.3.6.1.2.1.2.2.1.16" instance="ifIndex"
alias="ifOutOctets" type="counter" />
.... другие oid
</group>
Теперь для тех SNMP-устройств (точнее, для их интерфейсов, так как это данные уровня интерфейса, а не узла), в описании которых указана данная OID-группа, будет собираться статистика по состоянию интерфейса. Однако в графическом виде информацию о состоянии интерфейсов посмотреть пока не получится. Для просмотра графиков на основе rrd-данных необходимо будет внести соответствующие дополнения в конфигурационный файл snmp-graph.properties. Добавим строку mib2.opstat в секцию reports файла snmp-graph.properties. Теперь добавим следующие строки ниже секции report:
report.mib2.opstat.name=Interface Operational Status
report.mib2.opstat.columns=ifOperStatus
report.mib2.opstat.type=interfaceSnmp
report.mib2.opstat.command=--title="Interface Operational Status" \
--lower-limit 0 --upper-limit 2 --rigid \
--vertical-label="Up(1)|Down (0)" \
--width 400 \
--height 100 \
DEF:opst={rrd1}:ifOperStatus:AVERAGE \
CDEF:copst=2,opst,- \
LINE2:copst#00ff00:"OperStatus" \
GPRINT:copst:AVERAGE:"Status (0 - down 1 - up) \\: %2.0lf %s" \
В данных строках мы описали внешний вид графика, на котором будут отображаться данные о состоянии интерфейса (ноль на графике – интерфейс “опущен”, а единица – интерфейс функционирует нормально)
В строке “report.mib2.opstat.columns=ifOperStatus” описываются данные, на основе которых строится график.
Значение interfaceSnmp параметра report.mib2.opstat.type означает, что график создается для интерфейсов узла (возможен тип nodeSNMP – то есть для всего узла, а не его интерфейсов).
В строке “DEF:opst={rrd1}:ifOperStatus:AVERAGE \” дается определение opst – переменной, на основе средних значений (AVERAGE) которой будет строиться график.
В строке “CDEF:copst=2,opst,- \” дано определение производной переменной copst, значение которой есть функция 2-opst. Функцию ввели для того, чтобы отображаемый график выглядел более привычно (в диапазоне значений от 0 до 1), так как возвращаемые значения для “поднятого” интерфейса – 1, в противном случае – 2. Функция 2 – opst решает данную проблему.
В строке “LINE2:copst#00ff00:”OperStatus” \” описывается вид графика, его цвет и название графика.
Строка “GPRINT:copst:AVERAGE:”Status (0 – down 1 – up) \\: %2.0lf %s” \”, как видно из названия, ответственна за рисование графика на основе переменной copst.
В строках height и width задаются размеры графика.
После внесения данной информации в конфигурацию openNMS мы можем просматривать на графике историю изменения оперативного состояния интерфейса (см. рис. 6).
Рисунок 6. График изменения состояния (Up/Down) интерфейса во времени
Конечно, можно усомниться в практической полезности добавленного графика, но цель примера – показать, что аналогичным образом можно построить практически любой график на основе rrd-данных.
Заключение
Ну вот и закончено приведение в надлежащий вид установленной системы openNMS. Надеюсь, что полученных знаний о принципах работы системы, а также ее конфигурировании будет достаточно для дальнейшего самостоятельного освоения и использования.
Система оказалась очень гибкой и функциональной, хотя для настройки некоторых дополнительных функций и пришлось затратить некоторое количество усилий. В качестве несомненных плюсов также можно назвать и активность разработчиков проекта, с каждой новой версией добавляющих новые функции и исправляющих выявленные ошибки. За время, прошедшее после выхода первой статьи, было выпущено три обновления продукта, последнее из которых (версия 1.5.93 на момент написания статьи) было посвящено только работе над ошибками. Также на официальном сайте есть внятная документация, хотя, возможно, она не совсем оптимально структурирована. А после выхода статьи появилась возможность почитать о системе и на русском.
За кадром осталось описание еще многих возможностей, таких как интеграция с другими системами мониторинга, в том числе и коммерческими, распределенная установка системы и тонкости повышения производительности на высоконагруженных системах. Кроме того, данная система после некоторых настроек может дополняться графической картой устройств, что является удобной функцией. Но оставлю эти вопросы для изучения вам, коллеги, чтобы в повседневной работе оставались исследовательские и творческие моменты, а не только следование готовым мануалам и пошаговым инструкциям (что во многих случаях также полезно для повышения производительности труда). Удачи.
О разном
В России ещё есть политические силы, для который слово патриотизм не пустой звук. Присоединяйтесь!