SNMP-monitorozás az Odoo 19-ben: határérték túllépve, ticket megnyitva
Szerverek, switchek, szünetmentes tápegységek, szerverszobai hőmérséklet-érzékelők: szinte minden, ami egy hálózatban van, SNMP-t beszél, és információt tud adni az állapotáról. A kérdés csak az, hogy ki hallgatja – és mi történik, ha egy érték elszáll.
Az ügyfeleink számára gondozott infrastruktúrához ezt a láncot most egy helyre tettük: az Odoo 19-ünk lekérdezi az eszközöket, összeveti az értékeket a határértékekkel, és ha egy határt elérnek, ticketet nyit a Helpdeskben – annál az ügyfélnél, akié az eszköz. Nem egy különálló monitorozó rendszer, amely e-mailben ír a Helpdeskbe, hanem ugyanaz a rendszer, amelyben az ügyfél, az eszköz és a ticket amúgy is összefügg.
A modult saját üzemünkhöz fejlesztettük. Nem közösségi közzététel, mint a bankszámlakivonatokhoz vagy az e-számlákhoz készült moduljaink, hanem belső gondozási platformunk része – mint a nyomkövetés, amelyről legutóbb beszámoltunk.
A mérési értéktől a ticketig
A folyamat szándékosan egyszerű:
- Egy eszközt címmel és hozzáférési adatokkal hoznak létre (SNMP v1, v2c vagy v3 hitelesítéssel és titkosítással). Mentéskor az Odoo lekéri a rendszerleírást, a rendszernevet és az uptime-ot – ez a legőszintébb megerősítés arra, hogy a cím és a hozzáférési adatok helyesek.
- Az eszközön adatpontokat definiálnak: egy OID-t, egy mértékegységet, egy ügyfél-hozzárendelést.
- Egy ütemterv lekérdezi az összes aktív adatpontot. Eszközönként egyszer csatlakozik, nem adatpontonként – húsz OID esetén egy switchen ez a különbség egy és húsz munkamenet között.
- Minden adatpont figyelhet határértékeket: egy felső határt, egy alsó határt, vagy mindkettőt.
- Ha egy határt túllépnek, Helpdesk-ticket keletkezik.
Egy ticket incidensenként, nem mérésenként
A riasztási logika legfontosabb pontja: Csak az állapotváltás számít. Aki minden méréskor ticketet hoz létre, egy beragadt vagy pattogó érzékelővel töltött éjszaka után háromszáz ticketet kap – ez nem riasztás, hanem elködösítés.
A modul ezért adatpontonként megjegyzi, hogy „Normál” vagy „Riasztás” állapotban van-e. A határ első túllépésekor az állapot vált, egy üzenet kerül az eszköz Chatterébe, és egy ticket nyílik – az érintett ügyféllel mint partnerrel, az adatponttal, az eszközzel, a mért értékkel és a megsértett határral a szövegben. Amíg az érték a határon kívül marad, nem történik más: a ticket nyitva van, technikusaink tudnak róla.
Ha az érték visszatér a normál tartományba, a modul egy riasztás-megszűnést jelző üzenetet ír ugyanabba a ticketbe, és megszünteti a kapcsolatot. Hogy a ticket ezután lezárásra kerül-e, továbbra is ember dönti el – az, hogy egy érték rövid időre a határ alá esik, még nem jelenti, hogy az ok megszűnt.
A határértékeket minden méréskor ellenőrzi, függetlenül attól, hogy az érték mentésre kerül-e. Egy tartósan túl magas érték továbbra is riasztás marad. És egy riasztás soha nem hiúsulhat meg azon, hogy egy ticketet nem lehet létrehozni – ha a létrehozás sikertelen, a napló és az üzenet az eszközön ettől függetlenül megmarad.
Csak azt tároljuk, ami változik
Egy ötpercenként lekérdezett adatpont évente 105.000 értéket szolgáltat. Száz adatpontnál ez tízmillió sor fölött van – olyan értékekre, amelyek többnyire egyáltalán nem változtak.
Ezért csak az kerül mentésre, ami az utoljára mentett értékhez képest egy beállított küszöbnél jobban eltér – adatpontonként abszolút különbségként (például 0,5 °C), százalékos eltérésként vagy minden változásnál. Az aktuális érték és az utolsó lekérdezés időpontja ettől függetlenül mindig az adatponton áll; csak az előzmények ritkulnak.
Az is beállítható, hová kerülnek az értékek: az Odoo-adatbázisba, egy MongoDB-be vagy CSV-fájlokként az Odoo filestore-ba. Így a mérési értékeket távol tartjuk az ERP-adatbázistól – ugyanaz az alapelv, mint a nyomkövetés pozícióadatainál. Az előzmények minden esetben megjeleníthetők diagramként, óránkénti sűrítésnél átlagként, nem összegként.
Telítettség százalékban bájtok helyett
Egyes mennyiségek nem ilyenként találhatók meg az eszközben. Egy partíció telítettségét a foglalt tárhelyből és a teljes méretből kell kiszámítani; a hőmérséklet-érzékelők gyakran skálázott egész számokat adnak – 235-öt a 23,5 fokra.
Egy adatpont ezért átveheti az értéket a jelentett módon, megszorozhatja egy tényezővel, vagy kiszámíthatja egy második OID százalékaként. A határértékeknél ez döntő: a 90 %-os határ minden lemezméretre érvényes. Egy gigabájtban megadott határt meghajtónként kellene utánvezetni.
Senkinek nem kell fejből ismernie az OID-kat
Windows- és Linux-szervereknél a HOST-RESOURCES-MIB szabványosított: a meghajtók és a memória ismert helyen találhatók. Egy eszközfelismerés beolvassa a táblát, a telítettséget százalékra számolja át, és egyetlen kattintással létrehozza az adatpontokat a riasztási határral együtt.
Minden másra van egy SNMP-böngésző, amely bejárja az OID-fát, és minden talált OID-t megmutat az aktuális értékével – és, ha ismert a katalógusban, névvel, leírással és mértékegységgel az importált gyártói MIB-ből. Elég bejelölni.
Mit nyernek ebből ügyfeleink
Az eszközök és adatpontok ügyfelekhez vannak rendelve. Az ügyfélportálon a Saját SNMP-értékeim alatt megtalálja eszközei aktuális mérési értékeit és az elmúlt 24 óra, 7 nap, 30 nap vagy 12 hónap előzményeit diagramként – ugyanazokat az értékeket, amelyeket mi is látunk. Kizárólag az látható, ami az Ön vállalkozásához van rendelve.
És ha egy határértéket túllépnek, Önnek nem kell semmit tennie: a ticket már nálunk van, eszközzel, értékkel és időponttal, mielőtt Ön észrevenné.
Mi a modul szándékosan nem
Nem helyettesíti a teljes értékű monitorozást rendelkezésre állási ellenőrzésekkel, eszkalációs láncokkal és függőségi fákkal. Nem fogad SNMP-trapeket, hanem aktívan lekérdez. És nem zár le automatikusan ticketet – a riasztás-megszűnés egy üzenet, nem állapotváltozás.
Pontosan egy szakaszról van szó: a mérési értéktől a határon át a technikusig, aki foglalkozik vele. Ez a szakasz most olyan rövid, amilyen csak lehet.
Ha szervereit, hálózati eszközeit vagy érzékelőit be szeretné vonni ebbe a felügyeletbe, forduljon hozzánk.