[dev.icinga.com #7860] notification.vars are not accessible from within a NotificationCommand

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/7860

Created by agherardi on 2014-11-26 17:01:31 +00:00

Assignee: agherardi Status: Resolved (closed on 2014-12-02 10:07:35 +00:00) Target Version: (none) Last Update: 2014-12-02 10:07:35 +00:00 (in Redmine)

Icinga Version: 2.1.0-1

---

I'm trying to figure out if it's possible to pass custom parameters from a Notification to a NotificationCommand. I tried the following:

object NotificationCommand "my_notify" {
  import "plugin-notification-command"

  command = [ PluginDir + "/my_notify" ]

  arguments = {
    "-type" = "$notification.vars.mytype$"
    "-source" = "$address$"
    "-time" = "$icinga.long_date_time$"
    "-properties" = "$notification.vars.properties$"
  }
}

apply Notification "notify_my_service_down" to Service {
  command = "my_notify"
  vars.mytype = "my_service_down"
  vars.properties = ""
  period = "24x7"
  interval = 0 // disable re-notification
  states = [ Critical ]
  types = [ Problem ]
  users = [ "my_user" ]
  assign where match(service.name, "My Service")
}

icinga2.log shows that it ran:

'/usr/lib/nagios/plugins/my_notify' '-source' '192.168.240.24' '-time' '2014-11-25 12:51:52 -0800' '-type' ''

So the type is an empty string instead of the expected my_service_down.

my_notify takes the following parameters: -source IP address of the host -time timestamp -type a string that represents our own, non-Icinga notification type -properties some optional properties

Basically, I'm trying to map Icinga notifications - based on notification state, type and service that triggered it - to our own internal notifications. If possible, I'd like to define that mapping via the Icinga configuration.

[icinga-migration]

Updated by mfriedrich on 2014-11-27 08:59:06 +00:00

• Description updated
• Status changed from New to Feedback
• Assigned to set to agherardi

Please re-test that with 2.2.0 if the problem persists, as already asked at the forums.

[icinga-migration]

Updated by agherardi on 2014-12-01 22:07:40 +00:00

The problem is fixed in 2.2.0.

However, 2.2.0 introduces a new issue. I'd like to have 2 separate notifications, one for "service down" and one for "service up". Something along these lines:

apply Notification "notify_my_service_down" to Service { command = "my_notify" vars.mytype = "my_service_down" states = [ Critical ] types = [ Problem ] users = [ "my_user" ] assign where match(service.name, "My Service") }

apply Notification "notify_my_service_up" to Service { command = "my_notify" vars.mytype = "my_service_up" states = [ OK] types = [ Recovery ] users = [ "my_user" ] assign where match(service.name, "My Service") }

Apparently, logic was added in 2.2.0 that prevents a recovery notification to be sent unless the user was previously notified via the same Notification object. So when the service goes down, the notification is sent, as expected. However, when the service comes back up, the notification is NOT sent and I see the following in the logs:

[2014-12-01 12:57:16 -0800] notice/Notification: We did not notify user 'my_user' before. Not sending recovery notification.

Is there a way around this?

[icinga-migration]

Updated by gbeutner on 2014-12-02 10:07:35 +00:00

• Status changed from Feedback to Resolved

Ok, cool. Can you submit a separate ticket for the new problem?