I get notifications for users outside their timeperiod

Icinga 2
1

Hi all,

I have a problem regarding timeperiods for users. We have a team of employees who are respectively in charge of the monitoring for a week in a round robin manner. So, I configured a timeperiod for every colleague containing multiple weeks as ranges:

object TimePeriod "escalation-alice" {
  ranges = {
    "2024-01-01 - 2024-01-07" = "00:00-24:00"
    "2024-01-22 - 2024-01-28" = "00:00-24:00"
    "2024-02-12 - 2024-02-18" = "00:00-24:00"
  }
}

object TimePeriod "escalation-bob" {
  ranges = {
    "2024-01-15 - 2024-01-21" = "00:00-24:00"
    "2024-02-05 - 2024-02-11" = "00:00-24:00"
    "2024-02-26 - 2024-03-03" = "00:00-24:00"
  }
}

object TimePeriod "escalation-charlie" {
  ranges = {
    "2024-01-08 - 2024-01-14" = "00:00-24:00"
    "2024-01-29 - 2024-02-04" = "00:00-24:00"
    "2024-02-19 - 2024-02-25" = "00:00-24:00"
  }
}

I reference these periods in the user objects (e.g. period = "escalation-alice"). Unfortunately this does not work as intended, because today (2024-01-15) I get notifications for both, Bob and Charlie, even though only Bob should get notifications (notifications are sent 24x7 to a usergroup which contains all relevant users).

I inspected the time period for Charlie in the icinga2 console (get_time_period(“escalation-charlie”)) and got this:

{
        __name = "escalation-charlie"
        active = true
        display_name = "escalation-charlie"
        excludes = [ ]
        extensions = {
                DbObject = {
                        type = "Object"
                }
        }
        ha_mode = 0.000000
        icingadb_identifier = ""
        includes = [ ]
        is_inside = true
        name = "escalation-charlie"
        original_attributes = null
        package = "_etc"
        pause_called = false
        paused = false
        prefer_includes = true
        ranges = {
                "2024-01-08 - 2024-01-14" = "00:00-24:00"
                "2024-01-29 - 2024-02-04" = "00:00-24:00"
                "2024-02-19 - 2024-02-25" = "00:00-24:00"
        }
        resume_called = true
        segments = [ {
                begin = 1705273200.000000
                end = 1705359600.000000
        } ]
        source_location = {
                first_column = 1.000000
                first_line = 120.000000
                last_column = 48.000000
                last_line = 120.000000
                path = "/etc/icinga2/conf.d/system/timeperiods.conf"
        }
        start_called = true
        state_loaded = true
        stop_called = false
        templates = [ "escalation-charlie", "legacy-timeperiod" ]
        type = "TimePeriod"
        update = {
                arguments = [ "tp", "begin", "end" ]
                deprecated = false
                name = "Internal#LegacyTimePeriod"
                side_effect_free = false
                type = "Function"
        }
        valid_begin = 1705308331.641184
        valid_end = 1705446000.000000
        vars = null
        version = 0.000000
        zone = ""
}

But I’m not sure how to interpret this correctly. Why is there a template “legacy-timeperiod” referenced? I never did include something like that anywhere. What is the meaning of “valid_begin” and “valid_end”? And shouldn’t there be three segments instead of one, as there are three ranges?

The syntax for the range definition is adapted from here.

Further information:

  • System: Debian 11 + Icinga2 2.14.0 (installed via icinga2 repository)
  • Enabled features: api checker debuglog ido-mysql mainlog notification

I’m not sure how to debug this problem further and would appreciate your help. If you need any more information, let me know.

Thanks in advance!

2

Hey,
how are the notifications apply rules configured, where the periods are set?

3

Well, I have a period “out-of-office” which is applied to notifications, and several per-week timeperiods for the users. Unfortunately I found this issue which seems exactly the problem I have, which is in turn marked as duplicate of issue #8741 where a member commented along the lines of “we don’t fix that anytime soon”.

4

Yea, this looks really bad as one of the core features of Icinga2 is scheduling and it’s broken as soon as one tries to use advances stuff hinted at by the documentation and the names includes and excludes. No amount of focus into the new notification module coming “soon” and migrated to a lot later, will help with the same bugs in scheduling checks.

To us this is core and critical and I can’t understand, why this isn’t, at least, a half of the hands on deck situation. We also should have a support ticket open about this.

5

Yeah, I was also a bit shocked that this is a thing, and that it’s present since at least 2021 and that there are no plans to solve this as soon as possible.

I don’t even consider this use case “advanced”, apparently most of the available definitions are simply broken.

We solved our particular problem by doing as less as possible with timeperiods and handling notifications ourselves, via some self-written python scripts. I usually don’t want to complain about open-source software, but that this core-feature is apparently so broken that no one can fix it easily almost made us discard the idea of using icinga completely. In the end we put already too much time in configuring it, so we use it anyway, but it still leaves a bland taste. We use icinga2 since three weeks in production and I check the system at least twice a day (including late-night, when out-of-office periods are active), hoping that every check and every notification works as expected.