Monitorovanie SNMP v Odoo 19: Hraničná hodnota prekročená, tiket otvorený
Servery, prepínače, zdroje UPS, teplotné senzory v serverovni: Takmer všetko, čo visí v sieti, hovorí SNMP a vie podať informáciu o svojom stave. Otázkou je len, kto počúva – a čo sa stane, keď sa niektorá hodnota vymkne spod kontroly.
Pre infraštruktúru, ktorú spravujeme pre našich zákazníkov, sme túto reťaz teraz umiestnili na jedno miesto: Naše Odoo 19 vypytuje zariadenia, porovnáva hodnoty s hraničnými hodnotami a keď sa dosiahne hranica, otvorí tiket v helpdesku – u zákazníka, ktorému zariadenie patrí. Nie samostatný monitorovací systém, ktorý píše e-mailom do helpdesku, ale ten istý systém, v ktorom zákazník, zariadenie a tiket aj tak spolu súvisia.
Modul sme vyvinuli pre vlastnú prevádzku. Nie je to komunitné vydanie ako naše moduly pre bankové výpisy alebo e-faktúry, ale súčasť našej internej platformy na správu – rovnako ako sledovanie polohy, o ktorom sme nedávno písali.
Od nameranej hodnoty k tiketu
Priebeh je zámerne jednoduchý:
- Zariadenie sa vytvorí s adresou a prístupovými údajmi (SNMP v1, v2c alebo v3 s autentifikáciou a šifrovaním). Pri uložení si Odoo zistí popis systému, názov systému a uptime – najúprimnejšie potvrdenie, že adresa a prístupové údaje sedia.
- Na zariadení sa definujú dátové body: OID, jednotka, priradenie zákazníka.
- Plán vypytuje všetky aktívne dátové body. Pre každé zariadenie sa pripája raz, nie pre každý dátový bod – pri dvadsiatich OID na jednom prepínači je to rozdiel medzi jednou a dvadsiatimi reláciami.
- Každý dátový bod môže sledovať hraničné hodnoty: hornú hranicu, dolnú hranicu alebo obe.
- Ak sa hranica prekročí, vznikne tiket helpdesku.
Jeden tiket na incident, nie na meranie
Najdôležitejší bod v logike alarmov: Počíta sa len zmena stavu. Kto vytvára tiket pri každom meraní, má po jednej noci so zaseknutým alebo kmitajúcim senzorom tristo tiketov – to nie je alarmovanie, to je zahmlievanie.
Modul si preto pre každý dátový bod pamätá, či je v stave „Normálny“ alebo „Alarm“. Pri prvom prekročení hranice sa stav zmení, správa pristane v chattere zariadenia a otvorí sa tiket – s dotknutým zákazníkom ako partnerom, s dátovým bodom, zariadením, nameranou hodnotou a porušenou hranicou v texte. Kým hodnota zostáva mimo hranice, nič ďalšie sa nedeje: Tiket je otvorený, naši technici o tom vedia.
Keď sa hodnota vráti do normálneho rozsahu, modul zapíše do toho istého tiketu odvolanie poplachu a zruší prepojenie. O tom, či sa tiket potom uzavrie, naďalej rozhoduje človek – hodnota, ktorá na chvíľu klesne pod hranicu, ešte neznamená, že príčina je odstránená.
Hraničné hodnoty sa kontrolujú pri každom meraní, bez ohľadu na to, či sa hodnota ukladá. Trvalo príliš vysoká hodnota zostáva alarmom. A alarm nikdy nesmie zlyhať na tom, že sa tiket nedá vytvoriť – ak vytvorenie zlyhá, protokol a správa pri zariadení aj tak zostanú.
Ukladať len to, čo sa mení
Dátový bod, ktorý sa vypytuje každých päť minút, dá 105.000 hodnôt za rok. Pri sto dátových bodoch je to cez desať miliónov riadkov – pre hodnoty, ktoré sa väčšinou vôbec nezmenili.
Ukladá sa preto len to, čo sa oproti poslednej uloženej hodnote líši o viac než nastavený prah – pre každý dátový bod ako absolútny rozdiel (napríklad 0,5 °C), ako percentuálna odchýlka alebo pri každej zmene. Aktuálna hodnota a čas posledného vypytovania sú napriek tomu vždy pri dátovom bode; zriedi sa len história.
Kam sa hodnoty zapisujú, je tiež nastaviteľné: do databázy Odoo, do MongoDB alebo ako súbory CSV do filestore Odoo. Namerané hodnoty tak držíme mimo databázy ERP – rovnaká zásada ako pri údajoch o polohách pri sledovaní polohy. História sa dá v každom prípade zobraziť ako graf, pri hodinovom zhustení ako priemer, nie ako súčet.
Naplnenie v percentách namiesto v bajtoch
Niektoré veličiny nie sú v zariadení uvedené ako také. Naplnenie oddielu sa musí vypočítať z obsadenej pamäte a celkovej veľkosti; teplotné senzory často dodávajú škálované celé čísla – 235 pre 23,5 stupňa.
Dátový bod preto môže hodnotu prevziať tak, ako je hlásená, vynásobiť ju faktorom alebo vypočítať ako percento druhej OID. Pre hraničné hodnoty je to rozhodujúce: Hranica 90 % platí pre každú veľkosť disku. Hranicu v gigabajtoch by bolo treba udržiavať zvlášť pre každú jednotku.
Nikto si nemusí pamätať OID naspamäť
Pri serveroch s Windows a Linuxom je HOST-RESOURCES-MIB normovaná: Jednotky a operačná pamäť sú na známom mieste. Rozpoznávanie zariadenia prečíta tabuľku, prepočíta naplnenie na percentá a vytvorí dátové body vrátane hranice alarmu jedným kliknutím.
Pre všetko ostatné existuje prehliadač SNMP, ktorý prechádza strom OID a zobrazuje každú nájdenú OID s jej aktuálnou hodnotou – a, ak je v katalógu známa, s názvom, popisom a jednotkou z importovanej MIB výrobcu. Stačí zaškrtnúť.
Čo z toho majú naši zákazníci
Zariadenia a dátové body sú priradené zákazníkom. V zákazníckom portáli nájdete v časti Moje hodnoty SNMP aktuálne namerané hodnoty svojich zariadení a históriu za posledných 24 hodín, 7 dní, 30 dní alebo 12 mesiacov ako graf – tie isté hodnoty, ktoré vidíme aj my. Viditeľné je výlučne to, čo je priradené Vašej firme.
A keď sa hraničná hodnota prekročí, nemusíte robiť nič: Tiket je u nás už založený, so zariadením, hodnotou a časom, skôr než si to všimnete.
Čím modul zámerne nie je
Nie je náhradou za úplné monitorovanie s kontrolami dostupnosti, eskalačnými reťazcami a stromami závislostí. Neprijíma SNMP trapy, ale vypytuje aktívne. A žiadny tiket automaticky neuzatvára – odvolanie poplachu je správa, nie zmena stavu.
Ide presne o jednu trasu: od nameranej hodnoty cez hranicu k technikovi, ktorý sa o to postará. Táto trasa je teraz taká krátka, aká len môže byť.
Ak chcete svoje servery, sieťové zariadenia alebo senzory zaradiť do tohto monitorovania, obráťte sa na nás.