SNMP monitoring v Odoo 19: překročený limit, vytvořený požadavek
Servery, switche, záložní zdroje UPS, teplotní čidla v serverovně: téměř vše, co je připojené k síti, komunikuje přes SNMP a dokáže poskytovat informace o svém stavu. Otázkou je jen, kdo je sleduje – a co se stane, když se některá hodnota vymkne kontrole.
U infrastruktury, kterou spravujeme pro naše zákazníky, jsme nyní celý tento proces soustředili na jedno místo: naše Odoo 19 se dotazuje zařízení, porovnává hodnoty s limity a při dosažení limitu vytvoří požadavek v helpdesku – u zákazníka, kterému zařízení patří. Vše tak probíhá ve stejném systému, v němž už jsou zákazník, zařízení a požadavek propojené, bez samostatného monitorovacího systému, který by posílal e-maily do helpdesku.
Modul jsme vyvinuli pro vlastní provoz. Na rozdíl od našich modulů pro bankovní výpisy nebo elektronické faktury není zveřejněný pro komunitu, ale je součástí naší interní platformy pro správu a podporu – stejně jako sledování, o kterém jsme psali minule.
Od naměřené hodnoty k požadavku
Postup je záměrně jednoduchý:
- Zařízení se založí s adresou a přístupovými údaji (SNMP v1, v2c nebo v3 s ověřováním a šifrováním). Při uložení Odoo načte popis systému, jeho název a dobu běhu – nejspolehlivější potvrzení, že adresa i přístupové údaje jsou správné.
- U zařízení se definují datové body: OID, jednotka a přiřazení k zákazníkovi.
- Naplánovaná úloha načítá všechny aktivní datové body. Ke každému zařízení se připojí jednou, nikoli zvlášť pro každý datový bod – u dvaceti OID na jednom switchi je to rozdíl mezi jednou a dvaceti relacemi.
- U každého datového bodu lze sledovat limity: horní, dolní nebo oba.
- Při překročení limitu vznikne požadavek v helpdesku.
Jeden požadavek na incident, nikoli na každé 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í.
Jakmile se hodnota vrátí do normálního rozmezí, modul do stejného požadavku zapíše zprávu o návratu do normálu a zruší propojení. O tom, zda se požadavek uzavře, nadále rozhoduje člověk – krátkodobý pokles hodnoty pod limit ještě neznamená, že byla odstraněna příčina.
Limity se kontrolují při každém měření bez ohledu na to, zda se hodnota ukládá. Trvale příliš vysoká hodnota stále znamená alarm. A zaznamenání alarmu nikdy nesmí ztroskotat na tom, že nelze vytvořit požadavek – pokud se jeho vytvoření nezdaří, 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.
Proto se ukládají pouze hodnoty, které se od poslední uložené hodnoty liší o více než nastavený práh. Pro každý datový bod lze nastavit absolutní rozdíl (například 0,5 °C), procentní odchylku nebo ukládání při každé změně. Aktuální hodnota a čas posledního načtení jsou přesto u datového bodu vždy k dispozici; omezuje se pouze množství záznamů v historii.
Nastavit lze i to, kam se hodnoty ukládají: do databáze Odoo, do MongoDB nebo jako soubory CSV do souborového úložiště Odoo. Naměřené hodnoty tak uchováváme mimo databázi ERP – podle stejné zásady jako údaje o poloze ve sledovacím systému. Historii lze ve všech případech zobrazit jako graf; při agregaci po hodinách se počítá průměr, nikoli součet.
Zaplnění v procentech místo v bajtech
Některé veličiny zařízení přímo neposkytuje. Zaplnění diskového oddílu je nutné vypočítat z obsazeného místa a celkové kapacity; teplotní čidla často vracejí celá čísla v určitém měřítku – například 235 pro 23,5 stupně.
Datový bod proto může převzít hodnotu tak, jak ji zařízení hlásí, vynásobit ji koeficientem nebo ji vypočítat jako procentní podíl vůči hodnotě druhé OID. Pro limity je to zásadní: hranice 90 % platí pro jakoukoli kapacitu disku. Limit v gigabajtech by se musel nastavovat a udržovat pro každý disk zvlášť.
OID si nikdo nemusí pamatovat zpaměti
U serverů se systémy Windows a Linux je HOST-RESOURCES-MIB standardizovaná: údaje o discích a operační paměti se nacházejí na známých místech. Funkce rozpoznání zařízení načte tabulku, převede zaplnění na procenta a jediným kliknutím vytvoří datové body včetně limitu pro alarm.
Pro vše ostatní je k dispozici prohlížeč SNMP, který prochází strom OID a zobrazuje každou nalezenou OID s aktuální hodnotou – a pokud je známá v katalogu, také s názvem, popisem a jednotkou z importované MIB výrobce. Stačí zaškrtnout.
Co to přináší našim zákazníkům
Zařízení a datové body jsou přiřazeny zákazníkům. V zákaznickém portálu najdete v části Moje hodnoty SNMP aktuální naměřené hodnoty svých zařízení a graf jejich vývoje za posledních 24 hodin, 7 dní, 30 dní nebo 12 měsíců — stejné hodnoty, které vidíme i my. Zobrazují se výhradně údaje přiřazené vaší společnosti.
A pokud dojde k překročení mezní hodnoty, nemusíte nic dělat: Tiket už máme u nás, včetně zařízení, hodnoty a času, ještě než si problému všimnete.
Čím modul záměrně není
Nenahrazuje komplexní monitoring s kontrolami dostupnosti, eskalačními postupy a stromy závislostí. Nepřijímá SNMP trapy, ale aktivně se dotazuje. A žádný tiket automaticky neuzavírá — oznámení o návratu do normálu je zpráva, nikoli změna stavu.
Jde o jedinou cestu: od naměřené hodnoty přes překročení limitu k technikovi, který se o problém postará. Tato cesta je teď tak krátká, jak jen může být.
Pokud chcete do tohoto monitoringu zapojit své servery, síťová zařízení nebo senzory, ozvěte se nám.