NotificationCommand env variables available

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi,
    Hopefully a simple one, but I cannot find it in the documentation.
    What env values are available for "NotificationCommand", as I used to use "$HOSTNOTIFICATIONID$" in Icinga1 but cannot see the translation to the ID for the notification in Icinga2.

    Please can you help or point me to the part of documentation that lists all env values I can use?

    Thank you

  • Just expanding on this after talking to @icinga on twitter, it seems $HOSTNOTIFICATIONID$ is no longer available.
    What I need is a unique numeric ID that I can send in email and sms. This then allows the receiver to reply and contain that unique ID with a command (such as ACK, check now, disable, etc), we use our own code to receive incoming SMS that will parse for the ID and the command which it then sends to Icinga using the command pipe, so it's this behaviour we want to replicate on icinga2.

    I do see in icinga2idomysql.icinga_notifications a notification_id but I suspect this isn't a variable that can easily be passed through to my "object NotificationCommand "sms-host-notification" {" code or env variables that ultimately get passed to my shell script (that does the SMS sending).

    Thanks in advance!

  • Hey Andy,

    as far as I know Notification and Problem IDs are not readily available for configuration. Since I do not use Icinga 1 I'm not quite sure what to use them for, so I can not offer you any workaround or further help without understanding your intent. :( 
    Does this ticket relate to your problem? Or might Runtime Macros help you out?

    Kind regards, crunsher

    EDIT: When I was writing that post your addendum wasn't there, sorry

  • Hi crunsher,
    Thanks for getting back to me, yes I've come to the same conclusion!

    I'm looking at alternatives now, and I think what I'll do is this:
    trigger external shell script from NotificationCommand
    In external shell script write host/service and relevant info to a mysql database with an auto_increment field. Use that in my notification emails and SMS so that I can then use that on replies to trigger relevant ACKs, etc.

    Thanks again for getting back to me

  • If anyone comes up with a reasonable design and implementation idea, why not - comment on the linked issue then please. I never understood the logic in Nagios/Icinga1 with incrementing problem numbers, exposing them somewhere. That doesn't work reliably in HA clusters and is bound to pure integer counting. In case you want to match a problem notification inside a ticket system, the safest approach is still the host/service name combination matching on problem/recovery notification types.