SNMP nadzor u Odoo-u 19: granična vrijednost prekoračena, tiket otvoren
Poslužitelji, switchevi, UPS uređaji, temperaturni senzori u serverskoj sobi: gotovo sve što visi na mreži govori SNMP i može dati informaciju o svom stanju. Pitanje je samo tko sluša – i što se događa kada neka vrijednost izmakne kontroli.
Za infrastrukturu koju održavamo za svoje kupce taj smo lanac sada smjestili na jedno mjesto: naš Odoo 19 ispituje uređaje, uspoređuje vrijednosti s graničnim vrijednostima, a kada se granica dosegne, otvara tiket u helpdesku – kod kupca kojem uređaj pripada. Ne zasebni sustav nadzora koji e-poštom piše u helpdesk, nego isti sustav u kojem su kupac, uređaj i tiket ionako povezani.
Modul smo razvili za vlastito poslovanje. To nije objava za zajednicu poput naših modula za bankovne izvode ili e-račune, nego dio naše interne platforme za održavanje – kao i praćenje o kojem smo nedavno izvijestili.
Od mjerne vrijednosti do tiketa
Tijek je namjerno jednostavan:
- Uređaj se izrađuje s adresom i pristupnim podacima (SNMP v1, v2c ili v3 s autentifikacijom i šifriranjem). Pri spremanju Odoo dohvaća opis sustava, naziv sustava i uptime – najiskreniju potvrdu da su adresa i pristupni podaci ispravni.
- Na uređaju se definiraju podatkovne točke: OID, jedinica, dodjela kupcu.
- Raspored ispituje sve aktivne podatkovne točke. Po uređaju se spaja jednom, a ne po podatkovnoj točki – kod dvadeset OID-ova na jednom switchu to je razlika između jedne i dvadeset sesija.
- Svaka podatkovna točka može nadzirati granične vrijednosti: gornju granicu, donju granicu ili oboje.
- Ako se granica prekorači, nastaje helpdesk tiket.
Jedan tiket po incidentu, a ne po mjerenju
Najvažnija točka u logici alarmiranja: Računa se samo promjena stanja. Tko pri svakom mjerenju stvara tiket, nakon jedne noći s zaglavljenim ili treperavim senzorom ima tristo tiketa – to nije alarmiranje, to je zamagljivanje.
Modul stoga za svaku podatkovnu točku pamti nalazi li se u stanju „Normalno“ ili „Alarm“. Pri prvom prekoračenju granice stanje se mijenja, poruka završava u chatteru uređaja i otvara se tiket – s pogođenim kupcem kao partnerom, s podatkovnom točkom, uređajem, izmjerenom vrijednošću i povrijeđenom granicom u tekstu. Sve dok vrijednost ostaje izvan granice, ne događa se ništa dodatno: tiket je otvoren, naši tehničari znaju.
Ako se vrijednost vrati u normalno područje, modul upisuje poruku o prestanku alarma u isti tiket i razvezuje poveznicu. Hoće li se tiket zatim zatvoriti i dalje odlučuje čovjek – vrijednost koja nakratko padne ispod granice još ne znači da je uzrok otklonjen.
Granične vrijednosti provjeravaju se pri svakom mjerenju, neovisno o tome pohranjuje li se vrijednost. Trajno previsoka vrijednost ostaje alarm. A alarm nikada ne smije propasti zbog toga što se tiket ne može izraditi – ako izrada ne uspije, zapisnik i poruka na uređaju ipak ostaju.
Pohranjivati samo ono što se mijenja
Podatkovna točka koja se ispituje svakih pet minuta daje 105.000 vrijednosti godišnje. Kod sto podatkovnih točaka to je više od deset milijuna redaka – za vrijednosti koje se većinom uopće nisu promijenile.
Zato se pohranjuje samo ono što se u odnosu na posljednju pohranjenu vrijednost razlikuje za više od postavljenog praga – po podatkovnoj točki kao apsolutna razlika (primjerice 0,5 °C), kao postotno odstupanje ili pri svakoj promjeni. Trenutačna vrijednost i vrijeme posljednjeg ispitivanja ipak su uvijek na podatkovnoj točki; samo se povijest prorjeđuje.
Kamo se vrijednosti zapisuju, također je podesivo: u Odoo bazu podataka, u MongoDB ili kao CSV datoteke u Odoo filestore. Tako mjerne vrijednosti držimo izvan ERP baze podataka – isto načelo kao kod podataka o položaju u praćenju. Povijest se u svakom slučaju može prikazati kao dijagram, uz satno zgušnjavanje kao prosjek, a ne kao zbroj.
Popunjenost u postocima umjesto 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 daju skalirane cijele brojeve – 235 za 23,5 stupnjeva.
Podatkovna točka stoga može preuzeti vrijednost kako je javljena, pomnožiti je faktorom ili je izračunati kao postotak druge OID vrijednosti. Za granične vrijednosti to je presudno: granica od 90 % vrijedi za svaku veličinu diska. Granicu u gigabajtima trebalo bi održavati za svaki pogon zasebno.
Nitko ne mora znati OID-ove napamet
Kod Windows i Linux poslužitelja HOST-RESOURCES-MIB je normiran: pogoni i radna memorija nalaze se na poznatom mjestu. Prepoznavanje uređaja čita tablicu, preračunava popunjenost u postotke i jednim klikom izrađuje podatkovne točke zajedno s alarmnom granicom.
Za sve ostalo postoji SNMP preglednik koji prolazi OID stablom i prikazuje svaki pronađeni OID s njegovom trenutačnom vrijednošću – i, ako je poznat u katalogu, s nazivom, opisom i jedinicom iz uvezenog MIB-a proizvođača. Dovoljno je označiti.
Što naši kupci imaju od toga
Uređaji i podatkovne točke dodijeljeni su kupcima. U korisničkom portalu pod Moje SNMP vrijednosti nalazite trenutačne mjerne vrijednosti svojih uređaja i povijest zadnjih 24 sata, 7 dana, 30 dana ili 12 mjeseci kao dijagram – iste vrijednosti koje vidimo i mi. Vidljivo je isključivo ono što je dodijeljeno vašoj tvrtki.
A kada se granična vrijednost prekorači, ne morate ništa učiniti: tiket je već kod nas, s uređajem, vrijednošću i vremenom, prije nego što to uopće primijetite.
Što modul namjerno nije
Nije zamjena za potpun nadzor s provjerama dostupnosti, lancima eskalacije i stablima ovisnosti. Ne prima SNMP trapove, nego aktivno ispituje. I ne zatvara tiket automatski – prestanak alarma je poruka, a ne promjena statusa.
Riječ je o točno jednoj dionici: od mjerne vrijednosti preko granice do tehničara koji se time bavi. Ta je dionica sada onoliko kratka koliko može biti.
Ako svoje poslužitelje, mrežne uređaje ili senzore želite uključiti u ovaj nadzor, obratite nam se.