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