Notification for a present problem, when timeperiod starts

[hhamester]

Good morning,

I have a timeperiod “exthours” from 05:30am - 06:00pm. A host/ service going down at 04:11am and will not send notification - ok.

My question:
How can I realize a notification at 05:30am when the host/ service still down?

apply Service "dhcp-vlan4" {
        import "generic-service"
        check_command = "check-dhcp"

        vars.network = host.vars.dhcp_vlan4
        vars.sla = "exthours"

        vars.notification["mail"] = {
                groups = [ "operating", "windows" ]
        }

        assign where host.vars.dhcp_vlan4 != ""
}

object TimePeriod "exthours" {
  import "legacy-timeperiod"
  display_name = "Operating present"
  ranges = {
        "monday"        = "05:30-18:00"
        "tuesday"       = "05:30-18:00"
        "wednesday"     = "05:30-18:00"
        "thursday"      = "05:30-18:00"
        "friday"        = "05:30-16:00"
  }
}

template Service "generic-service" {
    max_check_attempts = 5
    check_interval = 3m
    retry_interval = 1m
    enable_flapping = true
}

template Notification "service-exthours" {
  interval = 1d

  command = "mail-service-notification"

  states = [ OK, Warning, Critical ]
  types = [ Problem, Acknowledgement, Recovery, Custom,
                        FlappingStart, FlappingEnd,
                        DowntimeStart, DowntimeEnd, DowntimeRemoved ]

  period = "exthours"
}

[dnsmichi]

The interval is the problem here, just 1d. You need to lower it to allow the next notification in shorter cycle. Still it wouldn't entirely solve the problem of sending the notification "just once", or delay it til period start. Dunno how one should influence this setting (cannot be the default, breaks current behaviour), how do others feel about it?

[dnsmichi]

As discussed offline here at NETWAYS, it might be an idea to use times.begin and times.end instead of the timeperiod and the high interval setting. I don't know whether there's a different solution for this.

[peterbraken]

Hello @dnsmichi,

I have a similar issue, i've setup icinga2/web/director for my firm to replace nagios. I did basicly the same as hhamester and used timetables to allow messages to be sent. In my opinion nagios did hold the message until beginning of the next timetable concerning and send it if problem still persists.

You speak of times.begin and times.end where can that be set?

[widhalmt]

ref/NC/627311

[dnsmichi]

Imho this is a feature request, and as such, you're invited to ask for sponsoring. Similar thing to the notification after downtime ends issue where customers invested time as well.

[widhalmt]

Good point. We'll discuss this internally and approach the customer for sponsoring. Might fix a problem which hit many users.

[dnsmichi]

Notes:

• tp->IsInside() is called for notifications (runtime triggered and reminder notifications)
• tp->IsInside() comes from two places
  • notification.period
  • user.period
• Update SetSupressedNotifications - needs clarification
  • For the general notification TP suppressing event
  • Use a secondary attribute for suppressed_user_notifications where the username is the key and the bitmask is the value
  • Sync that with the existing cluster event for HA clusters
  • Additional timer handler for firing them later on the user level with Utility::QueueAsyncCallback(std::bind(&Notification::ExecuteNotificationHelper, this, type, user, cr, force, author, text));