Hello Team,
I want to set a 1-minute hysteresis delay for warning alarms.
However, based on the protocol logic, traps are received continuously, and if the Trap ID (primary key) remains the same, the table record is updated instead of creating a new entry. A new record is only created if the Trap ID is unique.
This logic is implemented to prevent duplication since the same trap data is received repeatedly. Essentially, each record monitors a specific channel.
The issue is that the hysteresis time resets to zero every time the record is updated, preventing the alarm from being triggered.
Could you suggest a way to resolve this?
My current approach is to introduce an update count column in the table. This count would increment only if the data in all columns remains unchanged (indicating a duplicate trap). Then, in the alarm template, a condition can be set to trigger an alarm when the count exceeds a certain threshold.
However, I'm unsure if this is the most efficient solution. What do you think?
Hi Ramesh,
Please could you elaborate how do you update the trap in the row? (I am assuming that you are updating a table since you mention a primary key).
Is the row removed and created again when a duplicate trap arrives? It could be the case that I am overlooking something but as long as the row is available in table, the hysteresis should not be reset.
I'm led to think the alarm hysteresis is mainly intended to deal with continuous parameters – e.g. temperature value, processor load…
In DM, you'd use "Hyst On" to delay raising alarms and "Hyst off" to delay the clearing.
Any SNMP trap, on the other hand, would either be raised or solved (more like ON/OFF): as such, whether the hysteresis is applicable or not may depend on the logic for the specific protocol.
Subscribing to get more insights from the community