SNMP Monitoring in Odoo 19: Threshold Exceeded, Ticket Opened
Servers, switches, UPS systems, temperature sensors in the server room: almost everything attached to a network speaks SNMP and can provide information about its state. The only question is who is listening – and what happens when a value goes out of range.
For the infrastructure we look after for our customers, we have now put this chain in one place: our Odoo 19 polls the devices, compares the values with thresholds, and when a limit is reached, it opens a ticket in the helpdesk – for the customer who owns the device. Not a separate monitoring system that writes into the helpdesk by email, but the same system in which customer, device and ticket are connected anyway.
We developed the module for our own operations. It is not a community release like our modules for bank statements or e-invoices, but part of our internal service platform – like the tracking we reported on recently.
From Measured Value 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 on the device: an OID, a unit, a customer assignment.
- A schedule polls all active data points. A connection is made once per device, not per data point – with twenty OIDs on a switch, that is the difference between one and twenty sessions.
- Each data point can monitor thresholds: an upper limit, a lower limit or both.
- If a limit is exceeded, a helpdesk ticket is created.
One Ticket per Incident, Not per Measurement
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 value returns to the normal range, the module writes an all-clear into the same ticket and removes the link. Whether the ticket is then closed is still decided by a human – a value that briefly drops below the limit does not yet mean that the cause has been fixed.
Thresholds are checked on every measurement, regardless of whether the value is stored. A value that is constantly too high remains an alarm. And an alarm must never fail because a ticket cannot be created – if creation fails, the log and the message on the device remain in place anyway.
Store Only What Changes
A data point polled every five minutes yields 105,000 values a year. With a hundred data points, that is over ten million rows – for values that mostly have not changed at all.
Only what differs from the last stored value by more than a configured threshold is therefore stored – per data point as an absolute difference (for example 0.5 °C), as a percentage deviation or on every change. The current value and the time of the last poll are nevertheless always shown on the data point; only the history is thinned out.
Where the values are written is also configurable: to the Odoo database, to a MongoDB or as CSV files in the Odoo filestore. This keeps the measured values out of the ERP database – the same principle as with the position data in tracking. In every case, the history can be displayed as a chart, with hourly aggregation as an average, not as a sum.
Fill Level in Percent Instead of Bytes
Some quantities are not available as such in the device. The fill level of a partition has to be calculated from used storage and total size; temperature sensors often deliver scaled integers – 235 for 23.5 degrees.
A data point can therefore take over the value as reported, multiply it by a factor or calculate it as a percentage of a second OID. For thresholds, this is crucial: a limit of 90% applies to every disk size. A limit in gigabytes would have to be maintained for each drive.
Nobody Has to Know OIDs by Heart
On Windows and Linux servers, the HOST-RESOURCES-MIB is standardised: drives and memory are at a known location. A device discovery reads the table, converts fill levels into percent and creates the data points, complete with an alarm threshold, with one click.
For everything else, there is an SNMP browser that walks the OID tree and shows each OID found with its current value – and, if known in the catalogue, with name, description and unit from the imported vendor MIB. Ticking a box is enough.
What Our Customers Get Out of It
Devices and data points are assigned to customers. In the customer portal, under My SNMP Values, you will find the current measured values of your devices and the history of the last 24 hours, 7 days, 30 days or 12 months as a chart – the same values that we see. Only what is assigned to your company is visible.
And when a threshold is exceeded, you do not have to do anything: the ticket is already with us, with device, value and time, before you notice it.
What the Module Deliberately Is Not
It is not a replacement for full monitoring with availability checks, escalation chains and dependency trees. It does not receive SNMP traps but polls actively. And it does not close a ticket automatically – the all-clear is a message, not a status change.
It is about exactly one path: from the measured value, across the 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, get in touch.