Monitorizare SNMP în Odoo 19: prag depășit, tichet deschis
Servere, switch-uri, sisteme UPS, senzori de temperatură în camera serverelor: aproape tot ce este conectat la o rețea vorbește SNMP și poate oferi informații despre starea sa. Întrebarea este doar cine ascultă – și ce se întâmplă când o valoare iese din limite.
Pentru infrastructura pe care o administrăm pentru clienții noștri am mutat acum acest lanț într-un singur loc: Odoo 19 al nostru interoghează dispozitivele, compară valorile cu pragurile, iar când o limită este atinsă, deschide un tichet în Helpdesk – la clientul căruia îi aparține dispozitivul. Nu un sistem de monitorizare separat care scrie prin e-mail în Helpdesk, ci același sistem în care clientul, dispozitivul și tichetul sunt oricum legate între ele.
Modulul l-am dezvoltat pentru propria activitate. Nu este o publicare pentru comunitate, ca modulele noastre pentru extrase de cont sau facturi electronice, ci parte din platforma noastră internă de administrare – la fel ca localizarea, despre care am relatat recent.
De la valoarea măsurată la tichet
Fluxul este păstrat în mod deliberat simplu:
- Un dispozitiv este creat cu adresă și date de acces (SNMP v1, v2c sau v3 cu autentificare și criptare). La salvare, Odoo preia descrierea sistemului, numele sistemului și uptime-ul – cea mai sinceră confirmare că adresa și datele de acces sunt corecte.
- Pe dispozitiv se definesc puncte de date: un OID, o unitate, o atribuire la client.
- Un program interoghează toate punctele de date active. Pentru fiecare dispozitiv se face o singură conexiune, nu una pentru fiecare punct de date – la douăzeci de OID-uri pe un switch aceasta este diferența dintre una și douăzeci de sesiuni.
- Fiecare punct de date poate monitoriza praguri: o limită superioară, o limită inferioară sau ambele.
- Dacă o limită este depășită, se creează un tichet Helpdesk.
Un tichet pentru fiecare incident, nu pentru fiecare măsurătoare
Cel mai important punct al logicii de alarmare: contează doar schimbarea de stare. Cine generează un tichet la fiecare măsurătoare are, după o noapte cu un senzor blocat sau instabil, trei sute de tichete – aceasta nu este alarmare, ci ceață.
De aceea, modulul reține pentru fiecare punct de date dacă se află în starea „Normal” sau „Alarmă”. La prima depășire a limitei, starea se schimbă, un mesaj ajunge în Chatter-ul dispozitivului și se deschide un tichet – cu clientul afectat ca partener, cu punctul de date, dispozitivul, valoarea măsurată și limita încălcată în text. Cât timp valoarea rămâne în afara limitei, nu se mai întâmplă nimic: tichetul este deschis, tehnicienii noștri sunt la curent.
Dacă valoarea revine în intervalul normal, modulul scrie o încetare a alarmei în același tichet și desface legătura. Dacă tichetul este apoi închis sau nu, decide în continuare un om – o valoare care scade scurt sub limită nu înseamnă încă că cauza a fost remediată.
Pragurile sunt verificate la fiecare măsurătoare, indiferent dacă valoarea este salvată. O valoare constant prea mare rămâne o alarmă. Iar o alarmă nu are voie să eșueze din cauză că un tichet nu poate fi creat – dacă crearea eșuează, jurnalul și mesajul de pe dispozitiv rămân totuși.
Se salvează doar ce se modifică
Un punct de date interogat la fiecare cinci minute produce 105.000 de valori pe an. La o sută de puncte de date sunt peste zece milioane de rânduri – pentru valori care, în cea mai mare parte, nici nu s-au modificat.
De aceea se salvează doar ceea ce diferă de ultima valoare salvată cu mai mult decât un prag stabilit – pentru fiecare punct de date ca diferență absolută (de exemplu 0,5 °C), ca abatere procentuală sau la fiecare modificare. Valoarea curentă și momentul ultimei interogări rămân totuși mereu la punctul de date; doar istoricul este rărit.
Unde sunt scrise valorile este, de asemenea, configurabil: în baza de date Odoo, într-un MongoDB sau ca fișiere CSV în filestore-ul Odoo. Astfel ținem valorile măsurate în afara bazei de date ERP – același principiu ca la datele de poziție ale localizării. Istoricul poate fi afișat în orice caz ca diagramă, la condensare pe ore ca medie, nu ca sumă.
Nivel de umplere în procente în loc de octeți
Unele mărimi nu se găsesc ca atare în dispozitiv. Nivelul de umplere al unei partiții trebuie calculat din memoria ocupată și dimensiunea totală; senzorii de temperatură furnizează adesea numere întregi scalate – 235 pentru 23,5 grade.
Un punct de date poate de aceea să preia valoarea așa cum este raportată, să o înmulțească cu un factor sau să o calculeze ca procent dintr-un al doilea OID. Pentru praguri aceasta este decisiv: o limită de 90 % este valabilă pentru orice dimensiune de disc. O limită în gigaocteți ar trebui actualizată pentru fiecare unitate.
Nimeni nu trebuie să știe OID-urile pe de rost
La serverele Windows și Linux, HOST-RESOURCES-MIB este standardizat: unitățile și memoria de lucru se află într-un loc cunoscut. O detectare a dispozitivului citește tabelul, convertește nivelurile de umplere în procente și creează cu un clic punctele de date împreună cu pragul de alarmă.
Pentru tot restul există un browser SNMP care parcurge arborele OID și arată fiecare OID găsit cu valoarea sa curentă – și, dacă este cunoscut în catalog, cu nume, descriere și unitate din MIB-ul producătorului importat. Este suficient să bifați.
Ce câștigă clienții noștri din aceasta
Dispozitivele și punctele de date sunt atribuite clienților. În portalul de clienți găsiți, la Valorile mele SNMP, valorile măsurate curente ale dispozitivelor dumneavoastră și istoricul ultimelor 24 de ore, 7 zile, 30 de zile sau 12 luni ca diagramă – aceleași valori pe care le vedem și noi. Este vizibil exclusiv ceea ce este atribuit companiei dumneavoastră.
Iar dacă un prag este depășit, nu trebuie să faceți nimic: tichetul este deja la noi, cu dispozitiv, valoare și oră, înainte să observați.
Ce nu este modulul, în mod deliberat
Nu este un înlocuitor pentru o monitorizare completă, cu verificări de disponibilitate, lanțuri de escaladare și arbori de dependențe. Nu primește SNMP-trap-uri, ci interoghează activ. Și nu închide automat niciun tichet – încetarea alarmei este un mesaj, nu o schimbare de stare.
Este vorba de exact un traseu: de la valoarea măsurată, prin limită, până la tehnicianul care se ocupă. Acest traseu este acum atât de scurt cât poate fi.
Dacă doriți să includeți serverele, dispozitivele de rețea sau senzorii dumneavoastră în această monitorizare, contactați-ne.