SNMP-мониторинг во Odoo 19: Граничната вредност е надмината, тикетот е отворен
Сервери, свичеви, УПС-уреди, температурни сензори во серверската соба: речиси сè што виси на една мрежа зборува SNMP и може да даде информација за својата состојба. Прашањето е само кој слуша – и што се случува кога некоја вредност излегува од контрола.
За инфраструктурата што ја одржуваме за нашите клиенти, овој ланец сега го ставивме на едно место: нашиот Odoo 19 ги опрашува уредите, ги споредува вредностите со гранични вредности и, кога ќе се достигне граница, отвора тикет во Helpdesk – кај клиентот на кого му припаѓа уредот. Не посебен систем за мониторинг што пишува по е-пошта во Helpdesk, туку истиот систем во кој клиентот, уредот и тикетот и онака се поврзани.
Модулот го развивме за сопствено работење. Тоа не е објава за заедницата како нашите модули за банкарски изводи или е-фактури, туку дел од нашата внатрешна платформа за одржување – како и следењето за кое неодамна известивме.
Од мерената вредност до тикетот
Текот намерно е едноставен:
- Уредот се создава со адреса и пристапни податоци (SNMP v1, v2c или v3 со автентикација и шифрирање). При зачувувањето Odoo добива опис на системот, име на системот и Uptime – најискрената потврда дека адресата и пристапните податоци се точни.
- На уредот се дефинираат податочни точки: една OID, една единица, едно доделување на клиент.
- Распоред ги опрашува сите активни податочни точки. По уред се поврзува еднаш, а не по податочна точка – при дваесет OID-и на еден свич тоа е разликата меѓу една и дваесет сесии.
- Секоја податочна точка може да следи гранични вредности: горна граница, долна граница или обете.
- Ако една граница се надмине, настанува Helpdesk-тикет.
Еден тикет по инцидент, а не по мерење
Најважната точка во логиката на алармирање: Брои само промената на состојбата. Кој создава тикет при секое мерење, по една ноќ со заглавен или трепкав сензор има триста тикети – тоа не е алармирање, тоа е замаглување.
Модулот затоа по податочна точка помни дали се наоѓа во состојба „Нормално“ или „Аларм“. При првото надминување на границата состојбата се менува, порака завршува во Chatter на уредот и се отвора тикет – со засегнатиот клиент како партнер, со податочна точка, уред, измерена вредност и повредена граница во текстот. Сè додека вредноста останува надвор од границата, ништо повеќе не се случува: тикетот е отворен, нашите техничари знаат.
Кога вредноста ќе се врати во нормалниот опсег, модулот запишува одјава на алармот во истиот тикет и ја раскинува врската. Дали тикетот потоа ќе се затвори, и натаму одлучува човек – вредност што накратко паѓа под границата сè уште не значи дека причината е отстранета.
Граничните вредности се проверуваат при секое мерење, независно од тоа дали вредноста се зачувува. Постојано превисока вредност останува аларм. А алармот никогаш не смее да пропадне поради тоа што не може да се создаде тикет – ако создавањето не успее, дневникот и пораката на уредот сепак остануваат.
Се зачувува само што се менува
Податочна точка што се опрашува на секои пет минути дава 105.000 вредности годишно. Кај сто податочни точки тоа се над десет милиони редови – за вредности што најчесто воопшто не се променети.
Затоа се зачувува само она што се разликува од последната зачувана вредност за повеќе од зададен праг – по податочна точка како апсолутна разлика (на пример 0,5 °C), како процентуално отстапување или при секоја промена. Тековната вредност и времето на последното опрашување сепак секогаш стојат на податочната точка; се проретчува само историјата.
Каде се запишуваат вредностите е исто така подесливо: во базата на податоци на Odoo, во MongoDB или како CSV-датотеки во Odoo-Filestore. Така мерените вредности ги држиме надвор од ERP-базата на податоци – истиот принцип како кај податоците за позиции на следењето. Историјата во секој случај може да се прикаже како дијаграм, при часовно згуснување како просек, а не како збир.
Пополнетост во проценти наместо во бајти
Некои големини не стојат како такви во уредот. Пополнетоста на партиција мора да се пресмета од зафатената меморија и вкупната големина; температурните сензори често даваат скалирани цели броеви – 235 за 23,5 степени.
Податочната точка затоа може да ја преземе вредноста како што е пријавена, да ја помножи со фактор или да ја пресмета како процент од втора OID. За граничните вредности тоа е одлучувачко: граница од 90 % важи за секоја големина на диск. Граница во гигабајти би морала да се дорегулира за секој погон.
Никој не мора да ги знае OID-ите напамет
Кај Windows- и Linux-серверите HOST-RESOURCES-MIB е стандардизиран: погоните и работната меморија стојат на познато место. Откривањето на уреди ја чита табелата, ги претвора пополнетостите во проценти и ги создава податочните точки заедно со границата за аларм со еден клик.
За сè друго постои SNMP-прелистувач што го поминува OID-стеблото и ја прикажува секоја пронајдена OID со нејзината тековна вредност – и, ако е позната во каталогот, со име, опис и единица од увезената MIB на производителот. Доволно е да се штиклира.
Што имаат нашите клиенти од тоа
Уредите и податочните точки се доделени на клиенти. Во клиентскиот портал под Мои SNMP-вредности ги наоѓате тековните мерени вредности на Вашите уреди и историјата од последните 24 часа, 7 дена, 30 дена или 12 месеци како дијаграм – истите вредности што ги гледаме и ние. Видливо е исклучиво она што е доделено на Вашето претпријатие.
А кога граничната вредност ќе се надмине, не мора да правите ништо: тикетот е веќе кај нас, со уред, вредност и време, пред да го забележите.
Што модулот намерно не е
Не е замена за целосен мониторинг со проверки на достапност, ланци на ескалација и стебла на зависности. Не прима SNMP-Trap-ови, туку активно опрашува. И не затвора тикет автоматски – одјавата на алармот е порака, а не промена на статус.
Станува збор за точно една траса: од мерената вредност преку границата до техничарот што се грижи. Таа траса сега е толку кратка колку што може да биде.
Ако сакате Вашите сервери, мрежни уреди или сензори да ги вклучите во овој надзор, обратете ни се.