ScheduledDowntime objects should support Time Zones

philomory commented 6 years ago

Similar to #5374, but a distinct request insofar as ScheduledDowntime objects are not defined in terms of TimePeriod objects.

I'd like to see something like the following:

object Host "myhost" {
  ...
  vars = {
    time_zone = 'Pacific/Honolulu' // tz database zone name
    opening = "08:00"
    closing = "16:00"
  }
}

apply ScheduledDowntime "local-business-hours" to Host {
  ranges = {
    "monday - friday" = "00:00-" + host.vars.opening +  "," + host.vars.closing + "-24:00"
    "saturday - sunday" = "00:00-24:00"
  }
  time_zone = host.vars.time_zone
  assign where "business_hours_only" in host.groups
}

Expected Behavior

Downtimes are calculated in the specified timezone, allowing the same apply rule to be used for all devices globally.

Current Behavior

Downtime is scheduled at the specified times in UTC (or whatever the server timezone is).

You could attempt to emulate the desired by specifying opening and closing in UTC, but given the lack of support for ranges that cross midnight, as well as the lack of library functions for manipulating time range specifications, this becomes untenable once you get beyond a certain UTC offset. For instance, the above example in Pacific/Honolulu time would need to be translated to:

ranges = {
  "monday" = "00:00-18:00"
  "tuesday - friday" = "04:00-18:00"
  "saturday" = "04:00-24:00"
  "sunday" = "00:00-24:00"
}

This is hard to work out in your head (I'm not even sure I got it correct), Icinga doesn't provide the sort of library functions that would be necessary to calculate it automatically.

Possible Solution

The ability for ScheduledDowntime objects to include TimeZones in their definition would help address this issue. Providing library functions for manipulating range specifications would be a possible alternative solution; ideally, it'd be great to have both.

Context

We have systems we need to monitor in sites around the globe. Some of these systems are always-on, but many of them must be shut down at the end of (local) business hours. Worse, not all locations in a given time zone keep the same office hours. Manually managing 100+ scheduled downtime definitions is untenable; so far we've not come up with a good solution.

Your Environment

Version used (icinga2 --version): Application information: Installation root: /usr Sysconf directory: /etc Run directory: /run Local state directory: /var Package data directory: /usr/share/icinga2 State path: /var/lib/icinga2/icinga2.state Modified attributes path: /var/lib/icinga2/modified-attributes.conf Objects path: /var/cache/icinga2/icinga2.debug Vars path: /var/cache/icinga2/icinga2.vars PID path: /run/icinga2/icinga2.pid

System information: Platform: CentOS Linux Platform version: 7 (Core) Kernel: Linux Kernel version: 3.10.0-693.5.2.el7.x86_64 Architecture: x86_64

Build information: Compiler: GNU 4.8.5 Build host: unknown
Operating System and version: Centos 7 (mostly 7.4.1708)
Enabled features (icinga2 feature list): Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog Enabled features: api checker ido-pgsql mainlog notification
Icinga Web 2 version and modules (System - About): Icinga Web 2 Version: 2.5.0 Git commit: ebe1917b152b786cc708abe5215fd0c4be7c4237 Git commit date: 2017-11-27 director: 1.4.2 fileshipper: 1.0.1 monitoring: 2.5.0 puppetdb: 1.0.0
If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes. We do, but I don't think including 100+ copies of zones.conf would be helpful given that this issue isn't about zone config.

Crunsher commented 6 years ago

This depends on #5374

As soon as TimePeriods support Timezones, timezones work with everything.

philomory commented 6 years ago

I note that this issue has been given the tag "needs-sponsoring" (as has #5374). What does that actually mean in this project? Contributing.md doesn't actually mention sponsorship at all.

Crunsher commented 6 years ago

You can reach out here if you/your company wishes to sponsor a feature. In an issue context needs-sponsoring generally means "This would be nice to have, but it's currently not on the roadmap".

There is no enterprise version of Icinga 2 so all of these sponsored issues end up in the free Icinga release.

dnsmichi commented 6 years ago

I'm not a friend adding another feature to the buggy ScheduledDowntime object implementation, we should at first decide what to do with existing bugs and then decide whether we want to add more features onto it.

The hint with contributing and sponsoring is good, I will take a note on updating this accordingly, thanks.

dnsmichi commented 5 years ago

Blocked by #7288.

julianbrost commented 2 years ago

Implementing this would require looking into how this could be done consistently across platforms, so this could potentially require using/shipping (on Windows) a custom library/timezone database.

However, this is probably not only a feature request. Currently, each node locally evaluates these time ranges locally using the local timezone information. So if a cluster is spread across timezones, this can lead to inconsistent times for the same object across the cluster. So allowing to set the timezone would also allow fixing that problem.

Icinga / icinga2