You could use a combination of $notification.name$-$host.name$-$service.name$ or similar being computed in your notification script. There’s a discussion going on here as well.
Well, I’m not being able to deal with high quantities of tickets, cause I can’t relate a Down state ticket with an Up state ticket. In my case, using OTRS to manage the tickets, notification.name isn’t enough. Anyway, maybe I could use notification_number runtime attribute for notifications.
If you have a good proposal for such an ID in mind, please add it to the GitHub issue. Be it a timestamp, a checksum, a counter? This also involves storing and persisting it somewhere.
Well, the only workaround I thought was keeping all the down notifications (containing host/service names) inside a database (like NoSQL), and everytime an up state comes, he gets his “last_state_change_id” value from the “notification_id” that is stored inside the database. After that, the up state notification will have two variables:
notification_id : Which is going to be his self id
last_state_change_id: which is going to be the down notification id
Example:
Host1 is down. Send notification. notification_id = 1. Store in the database.
Host1 is up. Send notification. Gets value from database. notification_id = 2, last_state_change_id: 1.