How do I properly resolve alerts that are raised based on SNMP traps?
I’m working on developing SNMP Trap handlers and the associated Alerting for Nutanix clusters. I’ve successfully got all the traps working, and they show appropriately in the event logs. When a trap is sent from the cluster to Libre, I have an alert rule so that it will then send a notification. When you either manually acknowledge and resolve the issue on the cluster or the issue resolves on it’s own, a second trap gets sent (ntxTrapResolved), this includes some identifying information on the original trap. I’m trying to understand how do I get the two to relate together in order to appropriately resolve the Alert that gets generated from the original trap?
I’m thinking that I need to use the alerts unique id, provided by the cluster when it sends the first trap and in my handler for the ntxTrapResolved notification, I need to hunt down that event and somehow show it as resolved, and then that would then impact the alert itself? Or do I need to make sure the alert template includes that UUID and then on the database side find the alert and then change it’s status via the handler? That seems wrought with peril as it’s dependent on no one mucking with the alert template.
I looked through a number of the existing snmp trap handlers and didn’t really see anything that aligned to this pattern, so wasn’t sure where to go from here.
Any help is appreciated.
librenms@sffdsrv05:~$ ./validate.php
| Component | Version |
|---|---|
| LibreNMS | 22.1.0-43-g722de2ebe |
| DB Schema | 2021_12_02_113537_ports_stp_designated_cost_change_to_int (234) |
| PHP | 7.4.3 |
| Python | 3.8.10 |
| MySQL | 8.0.28-0ubuntu0.20.04.3 |
| RRDTool | 1.7.2 |
| SNMP | 5.8 |
====================================
[OK] Composer Version: 2.2.6
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct