SNMP-övervakning i Odoo 19: Gränsvärde överskridet, ärende öppnat
Servrar, switchar, UPS-anläggningar, temperaturgivare i serverrummet: Nästan allt som hänger i ett nätverk talar SNMP och kan lämna besked om sitt tillstånd. Frågan är bara vem som lyssnar – och vad som händer när ett värde skenar iväg.
För den infrastruktur vi betjänar åt våra kunder har vi nu samlat denna kedja på ett ställe: Vår Odoo 19 frågar av enheterna, jämför värdena med gränsvärden, och när en gräns nås öppnar den ett ärende i helpdesken – hos den kund som äger enheten. Inget separat övervakningssystem som skriver till helpdesken via e-post, utan samma system där kund, enhet och ärende ändå hänger ihop.
Modulen har vi utvecklat för vår egen verksamhet. Det är ingen community-publicering som våra moduler för kontoutdrag eller e-fakturor, utan en del av vår interna supportplattform – precis som spårningen som vi nyligen berättade om.
Från mätvärde till ärende
Flödet är medvetet hållet enkelt:
- En enhet skapas med adress och inloggningsuppgifter (SNMP v1, v2c eller v3 med autentisering och kryptering). Vid sparande hämtar Odoo systembeskrivning, systemnamn och uptime – den ärligaste bekräftelsen på att adress och inloggningsuppgifter stämmer.
- På enheten definieras datapunkter: en OID, en enhet, en kundkoppling.
- Ett schema avfrågar alla aktiva datapunkter. Per enhet ansluts man en gång, inte per datapunkt – vid tjugo OID:er på en switch är det skillnaden mellan en och tjugo sessioner.
- Varje datapunkt kan övervaka gränsvärden: en övre gräns, en undre gräns eller båda.
- Överskrids en gräns uppstår ett helpdesk-ärende.
Ett ärende per incident, inte per mätning
Den viktigaste punkten i larmlogiken: Endast tillståndsbytet räknas. Den som skapar ett ärende vid varje mätning har efter en natt med en fastnad eller studsande sensor trehundra ärenden – det är inte larmning, det är försvåring av överblicken.
Modulen kommer därför ihåg per datapunkt om den befinner sig i tillståndet ”Normal” eller ”Larm”. Vid första överskridandet av gränsen byts tillståndet, ett meddelande hamnar i enhetens chatter och ett ärende öppnas – med den berörda kunden som partner, med datapunkt, enhet, uppmätt värde och överträdd gräns i texten. Så länge värdet förblir utanför gränsen händer inget mer: Ärendet är öppet, våra tekniker har fått besked.
Återgår värdet till normalområdet skriver modulen en avslutande avisering i samma ärende och löser upp kopplingen. Om ärendet därefter stängs avgör fortfarande en människa – ett värde som kort faller under gränsen betyder inte ännu att orsaken är åtgärdad.
Gränsvärden kontrolleras vid varje mätning, oberoende av om värdet sparas. Ett konstant för högt värde förblir ett larm. Och ett larm får aldrig misslyckas på grund av att ett ärende inte kan skapas – om skapandet misslyckas blir protokoll och meddelande vid enheten ändå kvar.
Spara bara det som ändras
En datapunkt som avfrågas var femte minut ger 105 000 värden per år. Vid hundra datapunkter blir det över tio miljoner rader – för värden som oftast inte alls har ändrats.
Därför sparas bara det som skiljer sig från det senast sparade värdet med mer än en inställd tröskel – per datapunkt som absolut skillnad (till exempel 0,5 °C), som procentuell avvikelse eller vid varje ändring. Det aktuella värdet och tidpunkten för den senaste avfrågningen finns ändå alltid vid datapunkten; det är bara förloppet som glesas ut.
Vart värdena skrivs är likaså inställbart: i Odoo-databasen, i en MongoDB eller som CSV-filer i Odoo-filestore. Därmed håller vi mätvärdena utanför ERP-databasen – samma grundprincip som för spårningens positionsdata. Förloppet kan i varje fall visas som diagram, vid timvis förtätning som medelvärde, inte som summa.
Fyllnadsgrad i procent i stället för i byte
Vissa storheter finns inte som sådana i enheten. Fyllnadsgraden för en partition måste beräknas utifrån upptaget lagringsutrymme och total storlek; temperatursensorer levererar ofta skalade heltal – 235 för 23,5 grader.
En datapunkt kan därför ta över värdet som rapporterat, multiplicera det med en faktor eller beräkna det som procentsats av en andra OID. För gränsvärden är det avgörande: En gräns på 90 % gäller för varje diskstorlek. En gräns i gigabyte skulle behöva underhållas per enhet.
Ingen behöver kunna OID:er utantill
För Windows- och Linux-servrar är HOST-RESOURCES-MIB standardiserad: Enheter och arbetsminne finns på känd plats. En enhetsidentifiering läser tabellen, räknar om fyllnadsgrader till procent och skapar datapunkterna inklusive larmgräns med ett klick.
För allt annat finns en SNMP-browser som går igenom OID-trädet och visar varje hittad OID med dess aktuella värde – och, om den är känd i katalogen, med namn, beskrivning och enhet ur den importerade tillverkar-MIB:en. Det räcker att kryssa i.
Vad våra kunder får ut av det
Enheter och datapunkter är kopplade till kunder. I kundportalen hittar du under Mina SNMP-värden de aktuella mätvärdena för dina enheter och förloppet för de senaste 24 timmarna, 7 dagarna, 30 dagarna eller 12 månaderna som diagram – samma värden som även vi ser. Synligt är uteslutande det som är kopplat till ditt företag.
Och när ett gränsvärde överskrids behöver du inte göra något: Ärendet finns redan hos oss, med enhet, värde och klockslag, innan du hinner märka det.
Vad modulen medvetet inte är
Det är ingen ersättning för en fullständig övervakning med tillgänglighetskontroller, eskaleringskedjor och beroendeträd. Den tar inte emot SNMP-traps, utan avfrågar aktivt. Och den stänger inget ärende automatiskt – den avslutande aviseringen är ett meddelande, ingen statusändring.
Det handlar om exakt en sträcka: från mätvärdet via gränsen till teknikern som tar hand om det. Den sträckan är nu så kort den kan bli.
Om du vill ta in dina servrar, nätverksenheter eller sensorer i den här övervakningen, kontakta oss.