Workaround for host problem ID

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?


You could use a combination of $$-$$-$$ 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, 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.

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


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.