SNMP stebėsena Odoo 19: riba viršyta, bilietas atidarytas
Serveriai, jungikliai, nepertraukiamo maitinimo šaltiniai, temperatūros jutikliai serverinėje: beveik viskas, kas prijungta prie tinklo, kalba SNMP ir gali pranešti apie savo būseną. Klausimas tik, kas klausosi – ir kas nutinka, kai reikšmė išeina iš normos.
Infrastruktūrai, kurią prižiūrime savo klientams, šią grandinę dabar sudėjome į vieną vietą: mūsų Odoo 19 apklausia įrenginius, lygina reikšmes su ribomis, o kai riba pasiekiama, Helpdesk atidaro bilietą – pas klientą, kuriam įrenginys priklauso. Ne atskira stebėsenos sistema, rašanti el. paštu į Helpdesk, o ta pati sistema, kurioje klientas, įrenginys ir bilietas ir taip susiję.
Modulį sukūrėme savo veiklai. Tai nėra bendruomenės leidinys kaip mūsų moduliai banko išrašams ar e. sąskaitoms faktūroms, o mūsų vidinės priežiūros platformos dalis – kaip ir sekimas, apie kurį neseniai rašėme.
Nuo matavimo reikšmės iki bilieto
Eiga sąmoningai paprasta:
- Įrenginys sukuriamas su adresu ir prisijungimo duomenimis (SNMP v1, v2c arba v3 su autentifikavimu ir šifravimu). Išsaugojus Odoo gauna sistemos aprašą, sistemos pavadinimą ir veikimo laiką (uptime) – sąžiningiausią patvirtinimą, kad adresas ir prisijungimo duomenys teisingi.
- Įrenginyje apibrėžiami duomenų taškai: OID, vienetas, kliento priskyrimas.
- Tvarkaraštis apklausia visus aktyvius duomenų taškus. Prie kiekvieno įrenginio jungiamasi vieną kartą, o ne kiekvienam duomenų taškui – esant dvidešimčiai OID viename jungiklyje tai yra skirtumas tarp vienos ir dvidešimties sesijų.
- Kiekvienas duomenų taškas gali stebėti ribas: viršutinę, apatinę arba abi.
- Kai riba viršijama, sukuriamas Helpdesk bilietas.
Vienas bilietas vienam incidentui, o ne vienam matavimui
Svarbiausias aliarmų logikos punktas: skaičiuojamas tik būsenos pakeitimas. Kas kuria bilietą kiekvienam matavimui, po nakties su strigančiu ar šokinėjančiu jutikliu turi tris šimtus bilietų – tai ne įspėjimas, tai užtemdymas.
Todėl modulis kiekvienam duomenų taškui įsimena, ar jis yra būsenoje „Norma“ ar „Aliarmas“. Pirmą kartą viršijus ribą būsena pasikeičia, žinutė patenka į įrenginio Chatter ir atidaromas bilietas – su paveiktu klientu kaip partneriu, su duomenų tašku, įrenginiu, išmatuota reikšme ir pažeista riba tekste. Kol reikšmė lieka už ribos, daugiau nieko nevyksta: bilietas atviras, mūsų technikai žino.
Kai reikšmė grįžta į normos sritį, modulis į tą patį bilietą įrašo atšaukimo pranešimą ir panaikina susiejimą. Ar bilietas tada uždaromas, ir toliau sprendžia žmogus – reikšmė, trumpam nukritusi žemiau ribos, dar nereiškia, kad priežastis pašalinta.
Ribos tikrinamos kiekvieno matavimo metu, nepriklausomai nuo to, ar reikšmė išsaugoma. Nuolat per didelė reikšmė lieka aliarmu. O aliarmas niekada neturi žlugti dėl to, kad bilieto nepavyksta sukurti – jei sukūrimas nepavyksta, protokolas ir žinutė prie įrenginio vis tiek lieka.
Saugoti tik tai, kas keičiasi
Duomenų taškas, apklausiamas kas penkias minutes, per metus pateikia 105 000 reikšmių. Turint šimtą duomenų taškų, tai daugiau nei dešimt milijonų eilučių – reikšmėms, kurios dažniausiai apskritai nepasikeitė.
Todėl saugoma tik tai, kas nuo paskutinės išsaugotos reikšmės skiriasi daugiau nei nustatytas slenkstis – kiekvienam duomenų taškui kaip absoliutus skirtumas (pvz., 0,5 °C), kaip procentinis nuokrypis arba kiekvieno pasikeitimo atveju. Dabartinė reikšmė ir paskutinės apklausos laikas vis tiek visada pateikiami prie duomenų taško; retinama tik istorija.
Kur reikšmės rašomos, taip pat nustatoma: į Odoo duomenų bazę, į MongoDB arba kaip CSV failai į Odoo filestore. Taip matavimo reikšmes laikome atokiau nuo ERP duomenų bazės – tas pats principas kaip ir sekimo padėties duomenims. Istoriją bet kuriuo atveju galima rodyti kaip diagramą, o valandinio sutankinimo atveju kaip vidurkį, o ne sumą.
Užpildymas procentais, o ne baitais
Kai kurių dydžių įrenginyje kaip tokių nėra. Skaidinio užpildymą reikia apskaičiuoti iš užimtos atminties ir bendro dydžio; temperatūros jutikliai dažnai pateikia mastelio sveikuosius skaičius – 235 reiškia 23,5 laipsnio.
Todėl duomenų taškas gali perimti reikšmę taip, kaip pranešta, padauginti iš koeficiento arba apskaičiuoti kaip antrojo OID procentą. Ribų atžvilgiu tai lemiamas dalykas: 90 % riba tinka bet kokio dydžio diskui. Gigabaitais išreikštą ribą tektų prižiūrėti kiekvienam diskui atskirai.
Niekam nereikia mintinai žinoti OID
Windows ir Linux serveriuose HOST-RESOURCES-MIB yra standartizuotas: diskai ir operatyvioji atmintis yra žinomoje vietoje. Įrenginių aptikimas nuskaito lentelę, užpildymą perskaičiuoja į procentus ir vienu paspaudimu sukuria duomenų taškus su aliarmo riba.
Visam kitam yra SNMP naršyklė, kuri perbėga OID medį ir rodo kiekvieną rastą OID su dabartine reikšme – o jei žinoma kataloge, ir su pavadinimu, aprašu bei vienetu iš importuoto gamintojo MIB. Pakanka pažymėti.
Ką tai duoda mūsų klientams
Įrenginiai ir duomenų taškai priskirti klientams. Klientų portale skiltyje Mano SNMP reikšmės rasite savo įrenginių dabartines matavimo reikšmes ir pastarųjų 24 valandų, 7 dienų, 30 dienų ar 12 mėnesių istoriją kaip diagramą – tas pačias reikšmes, kurias matome ir mes. Matoma tik tai, kas priskirta jūsų įmonei.
O kai riba viršijama, jums nieko daryti nereikia: bilietas jau pas mus, su įrenginiu, reikšme ir laiku, dar prieš jums tai pastebint.
Kuo modulis sąmoningai nėra
Tai ne visavertės stebėsenos su prieinamumo patikromis, eskalavimo grandinėmis ir priklausomybių medžiais pakaitalas. Jis nepriima SNMP trap, o aktyviai apklausia. Ir jis automatiškai neuždaro bilieto – atšaukimas yra pranešimas, o ne būsenos pakeitimas.
Kalbama būtent apie vieną atkarpą: nuo matavimo reikšmės per ribą iki technikos specialisto, kuris tuo pasirūpina. Ši atkarpa dabar tokia trumpa, kokia tik gali būti.
Jei norite į šią stebėseną įtraukti savo serverius, tinklo įrenginius ar jutiklius, kreipkitės į mus.