Overslaan naar inhoud

Odoo 19 Community: SNMP-monitoring met automatische ticketaanmaak – onze open-sourcemodule

18 september 2026 in
Odoo 19 Community: SNMP-monitoring met automatische ticketaanmaak – onze open-sourcemodule
Alexander Biringer | Biricon IT Services GmbH

SNMP-monitoring in Odoo 19: drempelwaarde overschreden, ticket geopend

Servers, switches, UPS-installaties, temperatuursensoren in de serverruimte: bijna alles wat aan een netwerk hangt, spreekt SNMP en kan informatie geven over zijn toestand. De vraag is alleen wie luistert – en wat er gebeurt als een waarde uit de hand loopt.

Voor de infrastructuur die we voor onze klanten beheren, hebben we deze keten nu op één plek ondergebracht: ons Odoo 19 bevraagt de apparaten, vergelijkt de waarden met drempelwaarden, en als een grens wordt bereikt, opent het een ticket in de helpdesk – bij de klant aan wie het apparaat toebehoort. Geen apart monitoringsysteem dat per e-mail naar de helpdesk schrijft, maar hetzelfde systeem waarin klant, apparaat en ticket toch al samenhangen.

De module hebben we voor ons eigen bedrijf ontwikkeld. Het is geen communitypublicatie zoals onze modules voor bankafschriften of e-facturen, maar onderdeel van ons interne beheerplatform – net als de tracking, waarover we onlangs hebben bericht.

Van meetwaarde tot ticket

Het verloop is bewust eenvoudig gehouden:

  1. Een apparaat wordt aangemaakt met adres en toegangsgegevens (SNMP v1, v2c of v3 met authenticatie en versleuteling). Bij het opslaan haalt Odoo systeembeschrijving, systeemnaam en uptime op – de eerlijkste bevestiging dat adres en toegangsgegevens kloppen.
  2. Op het apparaat worden datapunten gedefinieerd: een OID, een eenheid, een klanttoewijzing.
  3. Een tijdschema bevraagt alle actieve datapunten. Per apparaat wordt één keer verbinding gemaakt, niet per datapunt – bij twintig OID's op een switch is dat het verschil tussen één en twintig sessies.
  4. Elk datapunt kan drempelwaarden bewaken: een bovengrens, een ondergrens of beide.
  5. Wordt een grens overschreden, dan ontstaat er een helpdeskticket.

Eén ticket per incident, niet per meting

Het belangrijkste punt in de alarmlogica: alleen de toestandswisseling telt. Wie bij elke meting een ticket aanmaakt, heeft na een nacht met een klemmende of stuiterende sensor driehonderd tickets – dat is geen alarmering, dat is verhulling.

De module onthoudt daarom per datapunt of het zich in de toestand “Normaal” of “Alarm” bevindt. Bij de eerste overschrijding van de grens wisselt de toestand, komt er een bericht in de chatter van het apparaat en wordt een ticket geopend – met de betrokken klant als partner, met datapunt, apparaat, gemeten waarde en geschonden grens in de tekst. Zolang de waarde buiten de grens blijft, gebeurt er verder niets: het ticket is open, onze technici weten ervan.

Keert de waarde terug naar het normale bereik, dan schrijft de module een herstelmelding in hetzelfde ticket en heft de koppeling op. Of het ticket dan wordt gesloten, beslist nog steeds een mens – een waarde die kort onder de grens zakt, betekent nog niet dat de oorzaak is verholpen.

Drempelwaarden worden bij elke meting gecontroleerd, ongeacht of de waarde wordt opgeslagen. Een constant te hoge waarde blijft een alarm. En een alarm mag er nooit op stuklopen dat een ticket niet kan worden aangemaakt – mislukt de aanmaak, dan blijven logboek en bericht bij het apparaat toch staan.

Alleen opslaan wat verandert

Een datapunt dat elke vijf minuten wordt bevraagd, levert 105.000 waarden per jaar op. Bij honderd datapunten zijn dat meer dan tien miljoen regels – voor waarden die meestal helemaal niet zijn veranderd.

Opgeslagen wordt daarom alleen wat meer dan een ingestelde drempel verschilt van de laatst opgeslagen waarde – per datapunt als absoluut verschil (bijvoorbeeld 0,5 °C), als procentuele afwijking of bij elke wijziging. De actuele waarde en het tijdstip van de laatste bevraging staan toch altijd bij het datapunt; alleen het verloop wordt uitgedund.

Waarheen de waarden worden geschreven, is eveneens instelbaar: naar de Odoo-database, naar een MongoDB of als csv-bestanden naar de Odoo-filestore. Zo houden we de meetwaarden buiten de ERP-database – hetzelfde uitgangspunt als bij de positiegegevens van de tracking. Het verloop kan in elk geval als diagram worden weergegeven, bij uurlijkse verdichting als gemiddelde, niet als som.

Vulgraad in procenten in plaats van in bytes

Sommige grootheden staan niet als zodanig in het apparaat. De vulgraad van een partitie moet worden berekend uit bezet geheugen en totale grootte; temperatuursensoren leveren vaak geschaalde gehele getallen – 235 voor 23,5 graden.

Een datapunt kan daarom de waarde overnemen zoals gemeld, met een factor vermenigvuldigen of berekenen als percentage van een tweede OID. Voor drempelwaarden is dat beslissend: een grens van 90 % geldt voor elke schijfgrootte. Een grens in gigabytes zou per station moeten worden bijgehouden.

Niemand hoeft OID's uit het hoofd te kennen

Bij Windows- en Linux-servers is de HOST-RESOURCES-MIB genormeerd: stations en werkgeheugen staan op een bekende plek. Een apparaatherkenning leest de tabel, rekent vulgraden om naar procenten en maakt de datapunten inclusief alarmgrens met één klik aan.

Voor al het andere is er een SNMP-browser die de OID-boom doorloopt en elke gevonden OID met zijn actuele waarde toont – en, als die in de catalogus bekend is, met naam, beschrijving en eenheid uit de geïmporteerde fabrikant-MIB. Aanvinken volstaat.

Wat onze klanten eraan hebben

Apparaten en datapunten zijn aan klanten toegewezen. In het klantenportaal vindt u onder Mijn SNMP-waarden de actuele meetwaarden van uw apparaten en het verloop van de afgelopen 24 uur, 7 dagen, 30 dagen of 12 maanden als diagram – dezelfde waarden die ook wij zien. Zichtbaar is uitsluitend wat aan uw bedrijf is toegewezen.

En als een drempelwaarde wordt overschreden, hoeft u niets te doen: het ticket is al bij ons, met apparaat, waarde en tijdstip, voordat u het opmerkt.

Wat de module bewust niet is

Het is geen vervanging voor een volledige monitoring met beschikbaarheidscontroles, escalatieketens en afhankelijkheidsbomen. Het ontvangt geen SNMP-traps, maar bevraagt actief. En het sluit geen ticket automatisch – de herstelmelding is een bericht, geen statuswijziging.

Het gaat om precies één traject: van de meetwaarde via de grens naar de technicus die zich erom bekommert. Dit traject is nu zo kort als het maar kan.

Als u uw servers, netwerkapparaten of sensoren in deze bewaking wilt opnemen, neem dan contact met ons op.