За системен администратор

Инсталиране и конфигуриране на системата за наблюдение на мрежата OpenNMS, част 4

Предишни части на тази статия: част 1, част 2, част 3.
Настройване на събиране и показване на SNMP статистика

Настройките за събиране на информация, получена чрез SNMP, са описани във файла data-collection-config.xml. Данните се събират чрез изпращане на GET заявки, съдържащи специфичен OID (Object ID) до устройство, поддържащо SNMP. В отговор се връщат някои стойности, които след това се записват в RRD файлове (RoundRobin Database (RRD) е проект, който е израснал от известния проект MRTG. Проектът се оказа доста успешен и в момента се използва не само в openNMS, но също така и в много други системи за наблюдение).

Използвайки услугите на Международната логистична търговска компания, транспортът на контейнери става бърз и надежден.

Файлът data-collection-config.xml вече съдържа информация за OID (Object ID) от MIB (Management Information Base) на най-често срещаните устройства (както хардуер, като Cisco Pix, така и софтуер - Asterisk), които поддържат SNMP протокол.

OID са описани вътре в маркера:

На свой ред, за да се осигури по-удобно по-нататъшно използване, OID се групират с помощта на маркер, например:

Ако параметърът ifType на маркера е зададен на „всички“, както в примера по-горе, това означава, че данните в групата са от табличен характер и тогава параметърът на екземпляра на маркера приема последователни стойности (в нашия case, ifIndex, съдържащ индексите на интерфейсите, налични в системата). Случаят с нетаблични данни е по-лесен. Параметърът ifType на маркера е зададен на „игнориране“, а параметърът на екземпляра на маркера е зададен на „0“.

Различните видове SNMP устройства са описани в етикети. За всеки тип устройство се дефинират една или няколко OID групи, въз основа на които ще се събират статистически данни за устройството и неговите интерфейси в rrd файлове:

.1.3.6.1.4.1.9.1.

cisco-памет
cisco-рутер
cisco-температура
cisco-напрежение
cisco-рутер-интерфейс
mib2-интерфейси
adsl-line

Когато се намери SNMP услуга на устройство, OpenNMS се опитва да определи типа на устройството, като изпрати GET заявка с OID = 1.3.6.1.2.1.1.2.0. Полученият отговор се сравнява със стойността на вложения в него етикет .

Например за голямо семейство рутери на Cisco този отговор ще съдържа подниза .1.3.6.1.4.1.9.1. Въз основа на този отговор, колекторът SNMP ще събира информация, като изпраща GET заявки с OID, описани в конфигурацията за този тип оборудване.

Ако имате конкретно оборудване, можете да създадете допълнителни OID групи и също така да дефинирате нов тип оборудване с помощта на етикет, в който можете да вмъкнете необходимите OID групи. Обикновено допълнителни MIB-бази се разпространяват с такова специфично оборудване. За да се ускори импортирането на OID данни от такива MIB файлове, дистрибуцията openNMS включва помощната програма mib2opennms, с която можете да конвертирате данни от MIB файл в набор от маркери, които се използват във файла data-collection-config.xml.

Нека сега разгледаме как данните, събрани чрез протокола SNMP, се записват и съхраняват в RRD файлове. Честотата на събиране на данни, както и продължителността на тяхното съхранение са описани в етикета:

RRA: СРЕДНА: 0,5: 1: 263520
RRA: СРЕДНА: 0,5: 60: 8784
RRA: СРЕДНА: 0,5: 1440: 366
RRA: МАКС: 0,5: 1440: 366
RRA: МИН: 0,5: 1440: 366

Параметърът на стъпката на маркера определя стъпката на съхраняване на информация в rrd файлове. Вложеният маркер се състои от следните атрибути:

RRA - уникално идентифицира линия като команда за конфигуриране.
срв - тип обединяване на данни, приема стойности СРЕДНО, МАКС, МИН или ПОСЛЕДНО.
xff - когато комбинирате събраните стойности в една, може да се случи така, че някои стойности да не са дефинирани (например възелът е бил недостъпен за известно време). Този параметър определя минималния процент недефинирани данни, при който всички данни, събрани за определен период, стават несигурни. По подразбиране е 50% (0,5).
стъпки - означава коефициент на агрегиране на събраните данни, например:
един - данните се записват на всяка стъпка (т.е. всяка минута, в случай на стъпка = 60);
60 - данните се групират за 60 периода и след това се записват (т.е. интервалът за съхранение е 1 час).
редове - определя броя на съхранените стойности. Цифрата 263520 означава, че данните, в случай на групиране на всяка минута, ще се съхраняват за около шест месеца (188 дни).

Информацията, събрана в RRD файлове, може да бъде представена под формата на графики. Настройването на графики въз основа на данни, събрани чрез SNMP, се извършва във файла snmp-graph.properties. Всички налични диаграми са посочени като стойности в раздела за отчети, разделени със запетаи. При първоначалната инсталация на OpenNMS вече има доста впечатляващ брой от тях. След изброяване на всички диаграми има пълна информация за всяка от тях. За да разберете по-добре принципа на графики, можете да добавите графика за състоянието на интерфейса във времето, която приема стойността „0“ в случай на „срив“ на интерфейса и „1“ в случай на нормалното му състояние. функциониране. За да направим това, нека се върнем към файла data-collection-config.xml, в който трябва да добавим съответния OID = .1.3.6.1.2.1.2.2.1.8, например, към групата mib2-интерфейси:

report.mib2.opstat.name = Работно състояние на интерфейса
report.mib2.opstat.columns = ifOperStatus
report.mib2.opstat.type = interfaceSnmp
report.mib2.opstat.command = - title = "Работно състояние на интерфейса" \
--долна граница 0 - горна граница 2 - твърда \
--vertical-label = "Нагоре (1) | Надолу (0)" \
--ширина 400 \
--височина 100 \
DEF: opst =: ifOperStatus: СРЕДНА \
CDEF: copst = 2, opst, - \
LINE2: copst # 00ff00: "OperStatus" \
GPRINT: copst: СРЕДЕН: "Състояние (0 - надолу 1 - нагоре) \\:% 2.0lf% s" \

В тези редове описахме външния вид на графиката, която ще показва данни за състоянието на интерфейса (нула на графиката - интерфейсът е „пропуснат“ и един - интерфейсът функционира нормално)

Редът „report.mib2.opstat.columns = ifOperStatus“ описва данните, въз основа на които е изградена графиката.

Стойността interfaceSnmp на параметъра report.mib2.opstat.type означава, че графиката е създадена за интерфейсите на възела (типът nodeSNMP е възможен - т.е. за целия възел, а не за неговите интерфейси).

Редът „DEF: opst =: ifOperStatus: AVERAGE \“ дефинира opst - променливата въз основа на средните стойности (AVERAGE), на които графиката ще бъде нанесена.

Редът „CDEF: copst = 2, opst, - \“ съдържа дефиницията на производната променлива copst, чиято стойност е функцията 2-opst. Функцията е въведена, за да направи показаната графика да изглежда по-позната (в диапазона от стойности от 0 до 1), тъй като възвръщаемите стойности за "повдигнатия" интерфейс са 1, в противен случай - 2. Функцията 2 - opst решава този проблем.

Редът “LINE2: copst # 00ff00:” OperStatus ”\” описва типа на диаграмата, нейния цвят и име на диаграмата.

Редът „GPRINT: copst: AVERAGE:” Състояние (0 - надолу 1 - нагоре) \\:% 2.0lf% s ”\”, както подсказва името, отговаря за изчертаването на графиката въз основа на променливата copst.

Височината и ширината на линиите задават размерите на диаграмата.

След въвеждане на тази информация в конфигурацията на openNMS, можем да видим историята на промените в работното състояние на интерфейса на графиката (вж. Фиг. 6).

Фигура 6. Графика на промяната на състоянието (нагоре/надолу) на интерфейса във времето

Разбира се, човек може да се съмнява в практическата полезност на добавената графика, но целта на примера е да покаже, че по същия начин можете да изградите почти всяка графика въз основа на rrd данни.

Заключение

Е, това приключи, като приведе инсталираната система openNMS във форма. Надявам се, че получените знания за принципите на работа на системата, както и нейната конфигурация, ще бъдат достатъчни за по-нататъшно независимо развитие и използване.

Системата се оказа много гъвкава и функционална, въпреки че отне известно усилие за конфигуриране на някои допълнителни функции. Като несъмнени предимства може да се посочи и дейността на разработчиците на проекта, като се добавят нови функции с всяка нова версия и се коригират установените грешки. След излизането на първата статия бяха пуснати три актуализации на продукти, последната от които (версия 1.5.93 по време на настоящото писане) беше посветена само на отстраняване на грешки. На официалния уебсайт също има ясна документация, въпреки че, може би, тя не е съвсем оптимално структурирана. И след публикуването на статията стана възможно да се прочете за системата на руски език.

Зад кулисите има описание на много други функции, като интеграция с други системи за мониторинг, включително търговски, разпределена инсталация на системата и тънкостите при увеличаване на производителността на силно натоварени системи. Освен това, след някои настройки, тази система може да бъде допълнена с графична карта с устройства, което е удобна функция. Но ще оставя тези въпроси на вас, колеги, за изучаване, така че изследователските и творчески моменти да останат във вашата ежедневна работа, а не само следвайки готови ръководства и инструкции стъпка по стъпка (което в много случаи е полезно и за повишаване на производителността на труда). Късмет.

За различно

В Русия все още има политически сили, за които думата патриотизъм не е празна фраза. Присъедини се към нас!