SNMP monitoring u Odoou 19: Granična vrijednost prekoračena, tiket otvoren
Serveri, switchevi, UPS uređaji, temperaturni senzori u serverskoj sobi: gotovo sve što visi u mreži govori SNMP i može dati informaciju o svom stanju. Pitanje je samo ko sluša – i šta se dogodi kada neka vrijednost izmakne kontroli.
Za infrastrukturu koju održavamo za naše kupce, ovaj smo lanac sada sveli na jedno mjesto: naš Odoo 19 ispituje uređaje, upoređuje vrijednosti s graničnim vrijednostima, a kada se granica dostigne, otvara tiket u Helpdesku – kod kupca kojem uređaj pripada. Nema zasebnog monitoring sistema koji e-poštom piše u Helpdesk, nego isti sistem 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 izvještavali.
Od mjerne vrijednosti do tiketa
Tok je namjerno jednostavan:
- Uređaj se kreira s adresom i pristupnim podacima (SNMP v1, v2c ili v3 s autentifikacijom i šifriranjem). Pri spremanju Odoo preuzima opis sistema, naziv sistema i uptime – najiskrenija potvrda da su adresa i pristupni podaci ispravni.
- Na uređaju se definiraju tačke podataka: jedan OID, jedna jedinica, jedno pridruživanje kupcu.
- Raspored 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 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 tačka u logici alarma: Računa se samo promjena stanja. Ko kod svakog mjerenja stvara tiket, nakon noći s zaglavljenim ili treperavim senzorom ima tri stotine tiketa – to nije alarmiranje, to je zamagljivanje.
Modul zato za svaku tačku podataka 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 tačkom podataka, uređajem, izmjerenom vrijednošću i prekršenom granicom u tekstu. Dok vrijednost ostaje izvan granice, ne događa se ništa dalje: tiket je otvoren, naši tehničari znaju.
Ako se vrijednost vrati u normalni opseg, modul u isti tiket upisuje odjavu alarma i raskida vezu. Hoće li se tiket tada 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. Stalno previsoka vrijednost ostaje alarm. A alarm nikada ne smije zakazati zato što se tiket ne može kreirati – ako kreiranje ne uspije, zapis i poruka na uređaju ipak ostaju.
Pohranjivati samo ono što se mijenja
Tačka podataka koja se ispituje svakih pet minuta daje 105.000 vrijednosti godišnje. Kod sto tačaka podataka to je više od deset miliona redova – za vrijednosti koje se uglavnom uopće nisu promijenile.
Zato se pohranjuje samo ono što se u odnosu na posljednju pohranjenu vrijednost razlikuje za više od podešenog praga – po tački podataka kao apsolutna razlika (npr. 0,5 °C), kao postotno odstupanje ili pri svakoj promjeni. Trenutna vrijednost i vrijeme posljednjeg ispitivanja ipak su uvijek na tački podataka; samo se historija prorjeđuje.
Kamo se vrijednosti upisuju, također se može podesiti: 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 pozicijama praćenja. Historija se u svakom slučaju može prikazati kao dijagram, pri satnom zgušnjavanju kao prosjek, a ne kao zbir.
Popunjenost u postocima umjesto u bajtovima
Neke veličine nisu kao takve prisutne u uređaju. Popunjenost particije mora se izračunati iz zauzete memorije i ukupne veličine; temperaturni senzori često daju skalirane cijele brojeve – 235 za 23,5 stepeni.
Tačka podataka zato može preuzeti vrijednost kako je prijavljena, pomnožiti je faktorom ili izračunati kao postotak druge OID. Za granične vrijednosti to je presudno: granica od 90 % vrijedi za svaku veličinu diska. Granica u gigabajtima morala bi se održavati za svaki disk.
Niko ne mora znati OID-ove napamet
Kod Windows i Linux servera HOST-RESOURCES-MIB je standardiziran: diskovi i radna memorija nalaze se na poznatom mjestu. Prepoznavanje uređaja čita tablicu, preračunava popunjenost u postotke i jednim klikom kreira tačke podataka zajedno s granicom alarma.
Za sve ostalo postoji SNMP preglednik koji prolazi kroz OID stablo i prikazuje svaki pronađeni OID s njegovom trenutnom vrijednošću – i, ako je poznat u katalogu, s imenom, opisom i jedinicom iz uvezenog MIB-a proizvođača. Dovoljno je označiti.
Šta naši kupci imaju od toga
Uređaji i tačke podataka dodijeljeni su kupcima. U korisničkom portalu pod Moje SNMP vrijednosti pronalazite trenutne mjerne vrijednosti svojih uređaja i historiju posljednjih 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šem preduzeću.
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 primijetite.
Šta modul namjerno nije
Nije zamjena za potpuni monitoring s provjerama dostupnosti, lancima eskalacije i stablima zavisnosti. Ne prima SNMP trapove, nego aktivno ispituje. I ne zatvara tiket automatski – odjava alarma je poruka, a ne promjena statusa.
Radi se o tačno jednoj dionici: od mjerne vrijednosti preko granice do tehničara koji se time bavi. Ta dionica je sada onoliko kratka koliko može biti.
Ako želite uključiti svoje servere, mrežne uređaje ili senzore u ovaj nadzor, obratite nam se.