SNMP monitoring v Odoo 19: Překročena mezní hodnota, otevřen tiket
Servery, switche, UPS, teplotní čidla v serverovně: téměř vše, co je v síti zapojeno, mluví protokolem SNMP a může podávat informace o svém stavu. Otázka je jen, kdo poslouchá – a co se stane, když se nějaká hodnota vymkne kontrole.
Pro infrastrukturu, kterou pro naše zákazníky spravujeme, jsme tento řetězec nyní umístili na jedno místo: naše Odoo 19 zařízení dotazuje, porovnává hodnoty s mezními hodnotami, a když je dosažena mez, otevře tiket v helpdesku – u zákazníka, kterému zařízení patří. Žádný samostatný monitorovací systém, který píše e-mailem do helpdesku, ale týž systém, ve kterém zákazník, zařízení a tiket stejně spolu souvisejí.
Modul jsme vyvinuli pro vlastní provoz. Není to komunitní zveřejnění jako naše moduly pro bankovní výpisy nebo e-faktury, ale součást naší interní platformy pro správu – stejně jako sledování, o němž jsme naposledy informovali.
Od naměřené hodnoty k tiketu
Postup je záměrně jednoduchý:
- Zařízení se založí s adresou a přístupovými údaji (SNMP v1, v2c nebo v3 s autentizací a šifrováním). Při uložení si Odoo načte popis systému, název systému a uptime – nejupřímnější potvrzení, že adresa a přístupové údaje souhlasí.
- Na zařízení se definují datové body: OID, jednotka, přiřazení zákazníka.
- Plánovač dotazuje všechny aktivní datové body. Na každé zařízení se připojí jednou, nikoli na každý datový bod – při dvaceti OID na jednom switchi je to rozdíl mezi jednou a dvaceti relacemi.
- Každý datový bod může sledovat mezní hodnoty: horní mez, dolní mez, nebo obojí.
- Pokud je mez překročena, vznikne tiket v helpdesku.
Jeden tiket na incident, nikoli na měření
Nejdůležitější bod v logice alarmů: Rozhoduje pouze změna stavu. Kdo vytváří tiket při každém měření, má po noci s vadným nebo zákmitávajícím čidlem tři sta tiketů – to není alarmování, to je zamlžování.
Modul si proto u každého datového bodu pamatuje, zda je ve stavu „Normální“ nebo „Alarm“. Při prvním překročení meze se stav změní, zpráva se objeví v chatteru zařízení a otevře se tiket – s dotčeným zákazníkem jako partnerem, s datovým bodem, zařízením, naměřenou hodnotou a porušenou mezí v textu. Dokud hodnota zůstává mimo mez, nic dalšího se neděje: tiket je otevřený, naši technici o tom vědí.
Pokud se hodnota vrátí do normálního rozsahu, modul zapíše do téhož tiketu odvolání poplachu a zruší propojení. Zda se tiket poté uzavře, rozhoduje nadále člověk – hodnota, která krátce klesne pod mez, ještě neznamená, že byla odstraněna příčina.
Mezní hodnoty se kontrolují při každém měření, bez ohledu na to, zda se hodnota ukládá. Trvale příliš vysoká hodnota zůstává alarmem. A alarm nikdy nesmí selhat kvůli tomu, že nelze vytvořit tiket – pokud vytvoření selže, protokol i zpráva u zařízení přesto zůstanou.
Ukládat jen to, co se mění
Datový bod dotazovaný každých pět minut poskytne ročně 105 000 hodnot. Při stovce datových bodů je to přes deset milionů řádků – pro hodnoty, které se většinou vůbec nezměnily.
Ukládá se proto jen to, co se oproti poslední uložené hodnotě liší o více než nastavený práh – u každého datového bodu jako absolutní rozdíl (například 0,5 °C), jako procentuální odchylka nebo při každé změně. Aktuální hodnota a čas posledního dotazu jsou u datového bodu přesto vždy k dispozici; ředí se pouze historie.
Kam se hodnoty zapisují, lze rovněž nastavit: do databáze Odoo, do MongoDB nebo jako soubory CSV do filestoru Odoo. Naměřené hodnoty tak držíme mimo databázi ERP – tatáž zásada jako u dat o polohách ve sledování. Průběh lze v každém případě zobrazit jako graf, při hodinovém zhuštění jako průměr, nikoli jako součet.
Zaplnění v procentech místo v bajtech
Některé veličiny zařízení jako takové neuvádí. Zaplnění oddílu se musí vypočítat z obsazené paměti a celkové velikosti; teplotní čidla často dodávají škálovaná celá čísla – 235 pro 23,5 stupně.
Datový bod proto může hodnotu převzít tak, jak byla hlášena, vynásobit ji faktorem nebo vypočítat jako procento druhého OID. Pro mezní hodnoty je to rozhodující: mez 90 % platí pro každou velikost disku. Mez v gigabajtech by se musela udržovat zvlášť pro každý disk.
Nikdo nemusí znát OID zpaměti
U serverů s Windows a Linuxem je HOST-RESOURCES-MIB standardizována: disky a operační paměť jsou na známém místě. Detekce zařízení přečte tabulku, přepočte zaplnění na procenta a založí datové body včetně meze alarmu jedním kliknutím.
Pro vše ostatní existuje prohlížeč SNMP, který prochází strom OID a u každého nalezeného OID ukazuje jeho aktuální hodnotu – a pokud je v katalogu znám, i název, popis a jednotku z importované MIB výrobce. Stačí zaškrtnout.
Co z toho mají naši zákazníci
Zařízení a datové body jsou přiřazeny zákazníkům. V zákaznickém portálu najdete pod Moje hodnoty SNMP aktuální naměřené hodnoty svých zařízení a průběh za posledních 24 hodin, 7 dní, 30 dní nebo 12 měsíců jako graf – tytéž hodnoty, které vidíme i my. Viditelné je výhradně to, co je přiřazeno vaší společnosti.
A pokud je mezní hodnota překročena, nemusíte dělat nic: tiket je u nás již založen, se zařízením, hodnotou a časem, dříve než si toho všimnete.
Čím modul záměrně není
Není náhradou za plnohodnotný monitoring s kontrolami dostupnosti, eskalačními řetězci a stromy závislostí. Nepřijímá SNMP trapy, ale aktivně se dotazuje. A žádný tiket automaticky neuzavírá – odvolání poplachu je zpráva, nikoli změna stavu.
Jde přesně o jednu trať: od naměřené hodnoty přes mez k technikovi, který se o věc postará. Tato trať je nyní tak krátká, jak jen může být.
Pokud chcete své servery, síťová zařízení nebo čidla zařadit do tohoto monitoringu, obraťte se na nás.