SNMP мониторинг в Odoo 19: превишена гранична стойност, създадена заявка за поддръжка
Сървъри, комутатори, непрекъсваеми токозахранващи устройства, температурни датчици в сървърното помещение: почти всичко, свързано към мрежата, поддържа SNMP и може да предостави информация за състоянието си. Въпросът е кой следи тази информация — и какво става, когато някоя стойност излезе извън нормата.
За инфраструктурата, която поддържаме за нашите клиенти, вече обединихме целия процес на едно място: нашата Odoo 19 извлича данните от устройствата, сравнява стойностите с граничните стойности и при достигане на граница създава заявка в системата за поддръжка — за клиента, на когото принадлежи устройството. Вместо отделна система за мониторинг, която изпраща имейли до системата за поддръжка, използваме същата система, в която клиентът, устройството и заявката вече са свързани.
Разработихме модула за собствената си работа. Той не е публикуван за общността като модулите ни за банкови извлечения или електронни фактури, а е част от вътрешната ни платформа за обслужване — също като проследяването, за което разказахме наскоро.
От измерената стойност до заявката за поддръжка
Процесът умишлено е опростен:
- Добавя се устройство с адрес и данни за достъп (SNMP v1, v2c или v3 с удостоверяване и шифроване). При запазване Odoo извлича описанието на системата, системното име и времето на непрекъсната работа — най-надеждното потвърждение, че адресът и данните за достъп са правилни.
- За устройството се определят точки за измерване: OID, мерна единица и клиент, към когото са отнесени.
- Всички активни точки за измерване се проверяват по график. Връзката се установява веднъж за всяко устройство, а не за всяка точка — при двадесет OID на един комутатор това е разликата между една и двадесет сесии.
- За всяка точка за измерване могат да се следят гранични стойности: горна граница, долна граница или и двете.
- При излизане извън зададените граници се създава заявка за поддръжка.
Една заявка за всеки инцидент, а не за всяко измерване
Най-важният момент в логиката на алармите: Брои се само смяната на състоянието. Който създава тикет при всяко измерване, след една нощ със заседнал или трептящ сензор има триста тикета – това не е алармиране, това е замъгляване.
Затова модулът запомня за всяка точка с данни дали е в състояние „Нормално“ или „Аларма“. При първото превишаване на прага състоянието се сменя, съобщение попада в Chatter на устройството и се отваря тикет – със засегнатия клиент като партньор, с точка с данни, устройство, измерена стойност и нарушен праг в текста. Докато стойността остава извън прага, не се случва нищо повече: тикетът е отворен, нашите техници са информирани.
Когато стойността се върне в нормалния диапазон, модулът добавя съобщение за нормализиране в същата заявка и премахва връзката с нея. Дали заявката да се затвори, продължава да решава човек — краткото спадане на стойността под границата още не означава, че причината е отстранена.
Граничните стойности се проверяват при всяко измерване, независимо дали стойността се записва. Постоянно прекалено високата стойност продължава да означава аларма. А невъзможността да се създаде заявка никога не бива да води до загуба на алармата — ако създаването е неуспешно, записът в журнала и съобщението все пак остават в записа на устройството.
Записваме само това, което се променя
Точка с данни, която се запитва на всеки пет минути, дава 105 000 стойности годишно. При сто точки с данни това са над десет милиона реда – за стойности, които в повечето случаи изобщо не са се променили.
Затова се записват само стойностите, които се различават от последната записана стойност с повече от зададен праг — за всяка точка това може да е абсолютна разлика (например 0,5 °C), процентно отклонение или запис при всяка промяна. Текущата стойност и часът на последната проверка винаги са налични в точката за измерване; намалява се само обемът на историята.
Мястото за записване на стойностите също може да се настройва: в базата данни на Odoo, в MongoDB или като CSV файлове във файловото хранилище на Odoo. Така държим измерените стойности извън ERP базата данни — същият принцип като при данните за местоположението в системата за проследяване. Във всички случаи историята може да се показва като графика, а при обобщаване по часове се използва средна стойност, а не сбор.
Заето пространство в проценти вместо в байтове
Някои величини не са налични директно в устройството. Процентът на заетото пространство в даден дял трябва да се изчисли от използваното пространство и общия размер; температурните датчици често връщат мащабирани цели числа — 235 за 23,5 градуса.
Затова точката за измерване може да приема стойността така, както е подадена, да я умножава по коефициент или да я изчислява като процент от стойността на втори OID. Това е решаващо за граничните стойности: граница от 90 % важи за всеки размер диск. Граница в гигабайти би трябвало да се настройва отделно за всеки диск.
Няма нужда да знаете OID наизуст
При сървърите с Windows и Linux HOST-RESOURCES-MIB е стандартизирана: дисковете и оперативната памет са на известни места. Функцията за откриване на устройства прочита таблицата, изчислява заетото пространство в проценти и с едно щракване създава точките за измерване заедно с прага за аларма.
За всичко останало има SNMP браузър, който обхожда OID дървото и показва всеки намерен OID с текущата му стойност — а ако е известен в каталога, и с име, описание и мерна единица от импортираната MIB на производителя. Достатъчно е да поставите отметка.
Каква е ползата за нашите клиенти
Устройствата и точките за измерване са отнесени към съответните клиенти. В клиентския портал, в раздела Моите SNMP стойности, ще намерите текущите измерени стойности от Вашите устройства и графика с историята за последните 24 часа, 7 дни, 30 дни или 12 месеца — същите стойности, които виждаме и ние. Видими са само данните, отнесени към Вашата фирма.
А при превишаване на гранична стойност не е нужно да правите нищо: заявката вече е при нас с устройството, стойността и часа, още преди да сте забелязали проблема.
Какво умишлено остава извън обхвата на модула
Модулът не замества цялостна система за мониторинг с проверки за достъпност, вериги за ескалация и дървета на зависимостите. Той не приема SNMP trap известия, а извлича данните чрез активни заявки. И не затваря автоматично заявки за поддръжка — известието за нормализиране е съобщение, а не промяна на статуса.
Целта е един конкретен път: от измерената стойност през преминаването на границата до техника, който поема случая. Този път вече е възможно най-кратък.
Ако искате да включите Вашите сървъри, мрежови устройства или датчици в този мониторинг, свържете се с нас.