Monitorimi SNMP në Odoo 19: Kufiri u tejkalua, tiketi u hap
Serverë, switch-e, sisteme UPS, sensorë temperature në dhomën e serverëve: pothuajse gjithçka që është e lidhur në një rrjet flet SNMP dhe mund të japë informacion për gjendjen e vet. Pyetja është vetëm kush dëgjon – dhe çfarë ndodh kur një vlerë del nga kontrolli.
Për infrastrukturën që mirëmbajmë për klientët tanë, këtë zinxhir e kemi sjellë tani në një vend: Odoo 19 ynë pyet pajisjet, krahason vlerat me kufijtë, dhe kur arrihet një kufi, hap një tiket në Helpdesk – te klienti të cilit i përket pajisja. Jo një sistem i veçantë monitorimi që shkruan me email në Helpdesk, por i njëjti sistem ku klienti, pajisja dhe tiketi janë gjithsesi të lidhura.
Modulin e kemi zhvilluar për operimin tonë. Nuk është një publikim për komunitetin si modulet tona për pasqyrat bankare ose faturat elektronike, por pjesë e platformës sonë të brendshme të mirëmbajtjes – ashtu si gjurmimi, për të cilin raportuam së fundmi.
Nga vlera e matur te tiketi
Rrjedha është mbajtur qëllimisht e thjeshtë:
- Një pajisje krijohet me adresë dhe të dhëna hyrjeje (SNMP v1, v2c ose v3 me autentikim dhe enkriptim). Gjatë ruajtjes Odoo merr përshkrimin e sistemit, emrin e sistemit dhe uptime – konfirmimi më i ndershëm që adresa dhe të dhënat e hyrjes janë të sakta.
- Në pajisje përcaktohen pika të dhënash: një OID, një njësi, një caktim klienti.
- Një orar pyet të gjitha pikat aktive të të dhënave. Për çdo pajisje lidhet një herë, jo për çdo pikë të dhënash – me njëzet OID në një switch, kjo është dallimi midis një dhe njëzet sesioneve.
- Çdo pikë të dhënash mund të monitorojë kufij: një kufi të sipërm, një kufi të poshtëm ose të dyja.
- Nëse një kufi tejkalohet, krijohet një tiket Helpdesk.
Një tiket për çdo incident, jo për çdo matje
Pika më e rëndësishme në logjikën e alarmit: Vetëm ndryshimi i gjendjes llogaritet. Kush krijon një tiket për çdo matje, pas një nate me një sensor që ngec ose rrëzëllen ka treqind tiketa – kjo nuk është alarmim, kjo është mjegullim.
Prandaj moduli mban mend për çdo pikë të dhënash nëse ndodhet në gjendjen „Normal“ ose „Alarm“. Gjatë tejkalimit të parë të kufirit gjendja ndryshon, një mesazh shfaqet në Chatter-in e pajisjes dhe hapet një tiket – me klientin e prekur si partner, me pikën e të dhënave, pajisjen, vlerën e matur dhe kufirin e shkelur në tekst. Për sa kohë vlera mbetet jashtë kufirit, nuk ndodh asgjë tjetër: tiketi është i hapur, teknikët tanë janë në dijeni.
Kur vlera kthehet në zonën normale, moduli shkruan një shenjë qetësimi në të njëjtin tiket dhe e zgjidh lidhjen. Nëse tiketi mbyllet pastaj, vendos sërish një njeri – një vlerë që bie për pak nën kufi nuk do të thotë ende se shkaku është eliminuar.
Kufijtë kontrollohen me çdo matje, pavarësisht nëse vlera ruhet. Një vlerë vazhdimisht shumë e lartë mbetet një alarm. Dhe një alarm nuk duhet të dështojë kurrë për shkak se një tiket nuk mund të krijohet – nëse krijimi dështon, protokolli dhe mesazhi te pajisja mbeten gjithsesi.
Ruhet vetëm ajo që ndryshon
Një pikë të dhënash që pyetet çdo pesë minuta jep 105.000 vlera në vit. Me njëqind pika të dhënash janë mbi dhjetë milionë rreshta – për vlera që në shumicën e rasteve nuk kanë ndryshuar fare.
Prandaj ruhet vetëm ajo që ndryshon nga vlera e fundit e ruajtur me më shumë se një prag i caktuar – për çdo pikë të dhënash si diferencë absolute (rreth 0,5 °C), si shmangie në përqind ose me çdo ndryshim. Vlera aktuale dhe koha e pyetjes së fundit ndodhen gjithsesi gjithmonë te pika e të dhënave; vetëm historiku hollohet.
Ku shkruhen vlerat është gjithashtu i rregullueshëm: në bazën e të dhënave Odoo, në një MongoDB ose si skedarë CSV në filestore-in e Odoo. Kështu i mbajmë vlerat e matura jashtë bazës së të dhënave ERP – i njëjti parim si te të dhënat e pozicionit të gjurmimit. Historiku mund të shfaqet në çdo rast si diagram, me dendësim sipas orës si mesatare, jo si shumë.
Niveli i mbushjes në përqind në vend të bajteve
Disa madhësi nuk gjenden si të tilla në pajisje. Niveli i mbushjes së një particioni duhet llogaritur nga memoria e zënë dhe madhësia totale; sensorët e temperaturës shpesh japin numra të plotë të shkallëzuar – 235 për 23,5 gradë.
Prandaj një pikë të dhënash mund ta marrë vlerën siç raportohet, ta shumëzojë me një faktor ose ta llogarisë si përqindje të një OID të dytë. Për kufijtë kjo është vendimtare: një kufi prej 90 % vlen për çdo madhësi disku. Një kufi në gigabajt do të duhej mirëmbajtur për çdo disk.
Askush nuk duhet t'i dijë OID-et përmendësh
Te serverët Windows dhe Linux, HOST-RESOURCES-MIB është i normuar: disqet dhe memoria operative ndodhen në vend të njohur. Një njohje pajisjesh e lexon tabelën, i konverton nivelet e mbushjes në përqind dhe i krijon pikat e të dhënave së bashku me kufirin e alarmit me një klikim.
Për gjithçka tjetër ekziston një SNMP Browser që përshkon pemën OID dhe shfaq çdo OID të gjetur me vlerën e saj aktuale – dhe, nëse njihet në katalog, me emër, përshkrim dhe njësi nga MIB-i i importuar i prodhuesit. Mjafton të shënohet.
Çfarë përfitojnë klientët tanë
Pajisjet dhe pikat e të dhënave u janë caktuar klientëve. Në portalin e klientëve gjeni te Vlerat e mia SNMP vlerat aktuale të matura të pajisjeve tuaja dhe historikun e 24 orëve, 7 ditëve, 30 ditëve ose 12 muajve të fundit si diagram – të njëjtat vlera që shohim edhe ne. Është i dukshëm ekskluzivisht ajo që i është caktuar ndërmarrjes suaj.
Dhe kur një kufi tejkalohet, nuk duhet të bëni asgjë: tiketi është tashmë te ne, me pajisjen, vlerën dhe orën, përpara se ta vini re.
Çfarë nuk është qëllimisht moduli
Nuk është zëvendësim për një monitorim të plotë me kontrolle disponueshmërie, zinxhirë përshkallëzimi dhe pemë varësish. Nuk pranon SNMP trap-e, por pyet në mënyrë aktive. Dhe nuk mbyll automatikisht asnjë tiket – shenja e qetësimit është një mesazh, jo një ndryshim statusi.
Bëhet fjalë për saktësisht një rrugë: nga vlera e matur përmes kufirit te teknikët që merret me të. Kjo rrugë është tani aq e shkurtër sa mund të jetë.
Nëse dëshironi t'i përfshini serverët, pajisjet e rrjetit ose sensorët tuaj në këtë monitorim, na kontaktoni.