Hey guys,
So when I’m working with some notifications on Icinga2 and ran into a problem. When I was using Icinga1 I had those 2 variables:
However, they don’t exist in icinga2. I actually use them to open a UNIQUE ticket using HOSTPROBLEMID and closing a ticket with LASTHOSTPROBLEMID.
Is there any workaround on it? Maybe an alternative? Any idea how can I deal with this?
Thanks.
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.
Cheers,
Michael
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.
Thanks.
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.
But icinga does have an ID as a runtime attribute, doesnt it?
notification_number could work as one. But in my case, it doesn’t because I need to retrieve last ticket ID, which is not an option.
That linked ticket is a feature request to add it. If you propose a subtle solution, this may speed things up getting this added.
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.