SNMP monitoring u Odoo 19: granična vrednost prekoračena, tiket otvoren
Serveri, switchevi, UPS uređaji, temperaturni senzori u server sali: skoro sve što visi na mreži govori SNMP i može da daje informacije o svom stanju. Pitanje je samo ko sluša – i šta se dešava kada neka vrednost izmakne kontroli.
Za infrastrukturu koju održavamo za naše klijente sada smo ovaj lanac smestili na jedno mesto: naš Odoo 19 ispituje uređaje, upoređuje vrednosti sa graničnim vrednostima, a kada se granica dostigne, otvara tiket u helpdesku – kod klijenta kome uređaj pripada. Nikakav poseban monitoring sistem koji e-poštom piše u helpdesk, već isti sistem u kome klijent, uređaj i tiket ionako zajedno pripadaju.
Modul smo razvili za sopstveno poslovanje. To nije objava za zajednicu kao naši moduli za bankovne izvode ili e-račune, već deo naše interne platforme za održavanje – kao i praćenje o kome smo nedavno izveštavali.
Od izmerene vrednosti do tiketa
Tok je namerno održan jednostavnim:
- Uređaj se kreira sa adresom i pristupnim podacima (SNMP v1, v2c ili v3 sa autentifikacijom i šifrovanjem). Pri čuvanju Odoo preuzima opis sistema, ime sistema i uptime – najpoštrenija potvrda da su adresa i pristupni podaci ispravni.
- Na uređaju se definišu tačke podataka: jedan OID, jedna jedinica, jedna dodela klijentu.
- Vremenski plan ispituje sve aktivne tačke podataka. Po uređaju se povezuje jednom, a ne po tački podataka – kod dvadeset OID-ova na jednom switchu to je razlika između jedne i dvadeset sesija.
- Svaka tačka podataka može nadgledati granične vrednosti: gornju granicu, donju granicu ili obe.
- Ako se granica prekorači, nastaje helpdesk tiket.
Jedan tiket po incidentu, a ne po merenju
Najvažnija tačka u logici alarma: Računa se samo promena stanja. Ko pri svakom merenju kreira tiket, posle jedne noći sa zaglavljenim ili treperavim senzorom ima trista tiketa – to nije alarmiranje, to je zamagljivanje.
Modul zato za svaku tačku podataka pamti da li se nalazi u stanju „Normalno“ ili „Alarm“. Pri prvom prekoračenju granice stanje se menja, poruka završava u Chatteru uređaja i otvara se tiket – sa pogođenim klijentom kao partnerom, sa tačkom podataka, uređajem, izmerenom vrednošću i narušenom granicom u tekstu. Dokle god vrednost ostaje van granice, ne dešava se ništa više: tiket je otvoren, naši tehničari znaju.
Ako se vrednost vrati u normalni opseg, modul u isti tiket upisuje prestanak alarma i raskida vezu. Da li će se tiket tada zatvoriti, i dalje odlučuje čovek – vrednost koja kratko padne ispod granice još ne znači da je uzrok otklonjen.
Granične vrednosti proveravaju se pri svakom merenju, bez obzira na to da li se vrednost čuva. Stalno previsoka vrednost ostaje alarm. A alarm nikada ne sme da propadne zbog toga što tiket ne može da se kreira – ako kreiranje ne uspe, zapisnik i poruka na uređaju ipak ostaju.
Čuvati samo ono što se menja
Tačka podataka koja se ispituje svakih pet minuta daje 105.000 vrednosti godišnje. Kod stotinu tačaka podataka to je preko deset miliona redova – za vrednosti koje se uglavnom uopšte nisu promenile.
Zato se čuva samo ono što se u odnosu na poslednju sačuvanu vrednost razlikuje za više od podešenog praga – po tački podataka kao apsolutna razlika (na primer 0,5 °C), kao procentualno odstupanje ili pri svakoj promeni. Trenutna vrednost i vreme poslednjeg ispitivanja ipak uvek stoje na tački podataka; samo se istorija proređuje.
Kuda se vrednosti upisuju, takođe se može podesiti: u Odoo bazu podataka, u MongoDB ili kao CSV datoteke u Odoo filestore. Tako merene vrednosti držimo van ERP baze podataka – isti princip kao kod podataka o pozicijama u praćenju. Istorija se u svakom slučaju može prikazati kao dijagram, pri časovnom zgušnjavanju kao prosek, a ne kao zbir.
Popunjenost u procentima umesto u bajtovima
Neke veličine u uređaju ne postoje kao takve. Popunjenost particije mora se izračunati iz zauzete memorije i ukupne veličine; temperaturni senzori često isporučuju skalirane cele brojeve – 235 za 23,5 stepeni.
Tačka podataka stoga može da preuzme vrednost kako je prijavljena, da je pomnoži faktorom ili da je izračuna kao procenat druge OID. Za granične vrednosti to je presudno: granica od 90 % važi za svaku veličinu diska. Granicu u gigabajtima trebalo bi održavati za svaki disk posebno.
Niko ne mora da zna OID-ove napamet
Kod Windows i Linux servera HOST-RESOURCES-MIB je standardizovan: diskovi i radna memorija nalaze se na poznatom mestu. Prepoznavanje uređaja čita tabelu, preračunava popunjenost u procente i jednim klikom kreira tačke podataka zajedno sa granicom alarma.
Za sve ostalo postoji SNMP pregledač koji prolazi kroz OID stablo i prikazuje svaki pronađeni OID sa njegovom trenutnom vrednošću – i, ako je poznat u katalogu, sa imenom, opisom i jedinicom iz uvezenog MIB-a proizvođača. Dovoljno je označiti.
Šta naši klijenti imaju od toga
Uređaji i tačke podataka dodeljeni su klijentima. U korisničkom portalu pod Moje SNMP vrednosti pronalazite trenutne izmerene vrednosti svojih uređaja i istoriju poslednjih 24 sata, 7 dana, 30 dana ili 12 meseci kao dijagram – iste vrednosti koje vidimo i mi. Vidljivo je isključivo ono što je dodeljeno vašem preduzeću.
A kada se granična vrednost prekorači, ne morate ništa da radite: tiket je već kod nas, sa uređajem, vrednošću i vremenom, pre nego što to primetite.
Šta modul namerno nije
To nije zamena za potpuni monitoring sa proverama dostupnosti, lancima eskalacije i stablima zavisnosti. Ne prima SNMP trapove, već aktivno ispituje. I ne zatvara tiket automatski – prestanak alarma je poruka, a ne promena statusa.
Reč je o tačno jednoj deonici: od izmerene vrednosti preko granice do tehničara koji se time bavi. Ta deonica je sada onoliko kratka koliko može biti.
Ako želite da svoje servere, mrežne uređaje ili senzore uključite u ovaj nadzor, obratite nam se.