SNMP monitoring in Odoo 19: threshold exceeded, ticket opened
Servers, switches, UPS units, temperature sensors in the server room: almost everything connected to a network speaks SNMP and can report on its condition. The question is who is listening, and what happens when a reading goes out of range.
For the infrastructure we manage for our customers, we have now brought this whole process into one place: our Odoo 19 installation queries the devices, compares readings against thresholds and, when a threshold is reached, opens a Helpdesk ticket for the customer who owns the device. The monitoring runs in the same system that already links the customer, device and ticket, without a separate monitoring system sending emails to the Helpdesk.
We developed this module for our own operations. Unlike our bank statement and e-invoicing modules, it is not a community release. It forms part of our internal service management platform, like the tracking system we recently wrote about.
From reading to ticket
The process is deliberately kept simple:
- A device is created with its address and credentials (SNMP v1, v2c or v3 with authentication and encryption). When saving, Odoo fetches the system description, system name and uptime – the most honest confirmation that the address and credentials are correct.
- Data points are defined for the device, each with an OID, a unit and an assigned customer.
- A scheduled task polls all active data points. It connects once per device rather than once per data point. With twenty OIDs on a switch, that is the difference between one session and twenty.
- Each data point can monitor an upper threshold, a lower threshold or both.
- If a threshold is breached, a Helpdesk ticket is created.
One ticket per incident, rather than per reading
The most important point in the alerting logic: Only the change of state counts. Anyone who creates a ticket for every measurement has three hundred tickets after one night with a stuck or bouncing sensor – that is not alerting, that is obfuscation.
The module therefore remembers, for each data point, whether it is in the “Normal” or “Alarm” state. When the limit is first exceeded, the state changes, a message lands in the device's chatter, and a ticket is opened – with the affected customer as partner, with data point, device, measured value and violated limit in the text. As long as the value stays outside the limit, nothing more happens: the ticket is open, our technicians know about it.
When the reading returns to the normal range, the module posts an all-clear message in the same ticket and removes the link. A person still decides whether to close the ticket: a reading briefly dropping below the threshold does not mean the underlying cause has been resolved.
Thresholds are checked on every reading, regardless of whether the value is stored. A consistently excessive reading remains an alert. And an alert must never be lost because a ticket cannot be created: if ticket creation fails, the log and message are still retained on the device record.
Only store what changes
A data point polled every five minutes produces 105,000 readings a year. With a hundred data points, that amounts to over ten million rows, mostly for values that have not changed at all.
We therefore only store readings that differ from the last stored value by more than a configured threshold. Each data point can use an absolute difference (such as 0.5 °C), a percentage deviation or record every change. The current value and the time of the last poll are always available on the data point; only the historical data is reduced.
The storage destination is also configurable: readings can be written to the Odoo database, a MongoDB database or CSV files in the Odoo filestore. This lets us keep readings out of the ERP database, following the same principle as with tracking position data. In all cases, the history can be displayed as a chart, with hourly aggregation using averages rather than sums.
Storage usage as a percentage rather than in bytes
Some measurements are not available directly from the device. A partition's usage percentage has to be calculated from used space and total capacity; temperature sensors often return scaled integers, such as 235 for 23.5 degrees.
A data point can therefore use the value as reported, multiply it by a factor or calculate it as a percentage of a second OID. This is crucial for thresholds: a 90% threshold applies to any disk size, whereas a threshold in gigabytes would need to be maintained separately for each drive.
No one needs to memorise OIDs
For Windows and Linux servers, HOST-RESOURCES-MIB is standardised: drives and memory are found at known locations. Device discovery reads the table, converts usage levels into percentages and creates the data points along with their alert thresholds in a single click.
For everything else, there is an SNMP browser that walks the OID tree and displays every OID it finds with its current value — and, where listed in the catalogue, its name, description and unit from the imported vendor MIB. Simply tick the boxes.
What our customers gain
Devices and data points are assigned to customers. In the customer portal, under My SNMP values, you can view your devices' current readings and charts covering the last 24 hours, 7 days, 30 days or 12 months — the same values we see. You can only see what is assigned to your company.
And if a threshold is exceeded, you do not need to do anything: we already have the ticket, complete with the device, reading and time, before you notice.
What the module is deliberately not
It is no replacement for a full monitoring system with availability checks, escalation chains and dependency trees. It actively polls devices rather than receiving SNMP traps. And it never closes a ticket automatically — the all-clear is a message, rather than a status change.
It focuses on a single path: from a reading crossing a threshold to the technician who takes care of it. That path is now as short as it can be.
If you would like to include your servers, network devices or sensors in this monitoring, please get in touch.