search

Icinga / icinga2

The core of our monitoring platform with a powerful configuration language and REST API.
https://icinga.com/docs/icinga2/latest
GNU General Public License v2.0
2.01k stars 577 forks source link

Scheduled-Downtime over midnight will not be scheduled #5261

Closed NRGYDrink closed 5 years ago

NRGYDrink commented 7 years ago

Behavior

I have set a scheduled downtime before and after midnight but only the time before 00:00 will be scheduled.

vars.wiederkehrende_downtime= "20:00-24:00,00:00-04:00"

There should be a downtime for 20:00-24:00 and 00:00-04:00 but only the downtime for 20:00-24:00 appears. Switching the times ("00:00-04:00,20:00-24:00") will still only accept the 20:00-24:00 downtime.

More info: https://monitoring-portal.org/index.php?thread/40408-scheduled-downtime-%C3%BCber-mitternacht-wird-nicht-eingerichtet/

Steps to Reproduce (for bugs)

  1. add to downtimes.conf: 
    apply ScheduledDowntime "wiederkehrende-downtime" to Host {
comment = "Wiederkehrende Downtime fuer Host"
author = "icingaadmin"
ranges = {
monday = host.vars.wiederkehrende_downtime
tuesday = host.vars.wiederkehrende_downtime
wednesday = host.vars.wiederkehrende_downtime
thursday = host.vars.wiederkehrende_downtime
friday = host.vars.wiederkehrende_downtime
saturday = host.vars.wiederkehrende_downtime
sunday = host.vars.wiederkehrende_downtime
}
assign where host.vars.wiederkehrende_downtime != ""
}
  2. add to a host: vars.wiederkehrende_downtime= "20:00-24:00,00:00-04:00"
  3. service icinga2 reload
  4. check your GUI or "icinga2 object list --type downtime"

Context

How has this issue affected me? I cant set scheduled downtimes for daily/weekly backups so everytime the backup is running, icinga2 might not be able to check the host/service so it will send out alerts (sms)

My Environment

icinga2 --version

icinga2 - The Icinga 2 network monitoring daemon (version: r2.6.3-1)

Copyright (c) 2012-2017 Icinga Development Team (https://www.icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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: Ubuntu
  Platform version: 14.04.5 LTS, Trusty Tahr
  Kernel: Linux
  Kernel version: 4.4.0-66-generic
  Architecture: x86_64

Build information:
  Compiler: GNU 4.8.4
  Build host: lgw01-43

icinga2 feature list

Disabled features: debuglog gelf graphite icingastatus influxdb livestatus opentsdb syslog
Enabled features: api checker command compatlog ido-mysql mainlog notification perfdata statusdata

icinga2 daemon -C

information/cli: Icinga application loader (version: r2.6.3-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: icinga2.domain.local
information/ConfigItem: Instantiated 1 ApiUser.
information/ConfigItem: Instantiated 1 ApiListener.
information/ConfigItem: Instantiated 3 Zones.
information/ConfigItem: Instantiated 1 FileLogger.
information/ConfigItem: Instantiated 2 Endpoints.
information/ConfigItem: Instantiated 6 NotificationCommands.
information/ConfigItem: Instantiated 5120 Notifications.
information/ConfigItem: Instantiated 210 CheckCommands.
information/ConfigItem: Instantiated 33 Downtimes.
information/ConfigItem: Instantiated 162 Hosts.
information/ConfigItem: Instantiated 1 IcingaApplication.
information/ConfigItem: Instantiated 15 HostGroups.
information/ConfigItem: Instantiated 2 Comments.
information/ConfigItem: Instantiated 55 Dependencies.
information/ConfigItem: Instantiated 4 UserGroups.
information/ConfigItem: Instantiated 8 Users.
information/ConfigItem: Instantiated 1800 Services.
information/ConfigItem: Instantiated 8 TimePeriods.
information/ConfigItem: Instantiated 27 ServiceGroups.
information/ConfigItem: Instantiated 20 ScheduledDowntimes.
information/ConfigItem: Instantiated 1 CompatLogger.
information/ConfigItem: Instantiated 1 StatusDataWriter.
information/ConfigItem: Instantiated 2 ExternalCommandListeners.
information/ConfigItem: Instantiated 1 CheckerComponent.
information/ConfigItem: Instantiated 1 IdoMysqlConnection.
information/ConfigItem: Instantiated 1 NotificationComponent.
information/ConfigItem: Instantiated 1 PerfdataWriter.
information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
information/cli: Finished validating the configuration file(s).

icinga2 object list --type Endpoint

Object 'icinga2-sat.domain.local' of type 'Endpoint':
  % declared in '/etc/icinga2/zones.conf', lines 20:1-20:49
  * __name = "icinga2-sat.domain.local"
  * host = "192.168.63.100"
    % = modified in '/etc/icinga2/zones.conf', lines 21:2-21:23
  * log_duration = 86400
  * name = "icinga2-sat.domain.local"
  * package = "_etc"
  * port = "5665"
  * templates = [ "icinga2-sat.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 20:1-20:49
  * type = "Endpoint"
  * zone = ""

Object 'icinga2.domain.local' of type 'Endpoint':
  % declared in '/etc/icinga2/zones.conf', lines 10:1-10:40
  * __name = "icinga2.domain.local"
  * host = "10.124.16.100"
    % = modified in '/etc/icinga2/zones.conf', lines 11:2-11:22
  * log_duration = 86400
  * name = "icinga2.domain.local"
  * package = "_etc"
  * port = "5665"
    % = modified in '/etc/icinga2/zones.conf', lines 12:2-12:14
  * templates = [ "icinga2.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 10:1-10:40
  * type = "Endpoint"
  * zone = ""

icinga2 object list --type Zone

Object 'global-templates' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 6:1-6:30
  * __name = "global-templates"
  * endpoints = null
  * global = true
    % = modified in '/etc/icinga2/zones.conf', lines 7:3-7:15
  * name = "global-templates"
  * package = "_etc"
  * parent = ""
  * templates = [ "global-templates" ]
    % = modified in '/etc/icinga2/zones.conf', lines 6:1-6:30
  * type = "Zone"
  * zone = ""

Object 'SAT' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 24:1-24:21
  * __name = "SAT"
  * endpoints = [ "icinga2-sat.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 25:2-25:50
  * global = false
  * name = "SAT"
  * package = "_etc"
  * parent = "master"
    % = modified in '/etc/icinga2/zones.conf', lines 26:2-26:18
  * templates = [ "SAT" ]
    % = modified in '/etc/icinga2/zones.conf', lines 24:1-24:21
  * type = "Zone"
  * zone = ""

Object 'master' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 15:1-15:20
  * __name = "master"
  * endpoints = [ "icinga2.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 17:2-17:41
  * global = false
  * name = "master"
  * package = "_etc"
  * parent = ""
  * templates = [ "master" ]
    % = modified in '/etc/icinga2/zones.conf', lines 15:1-15:20
  * type = "Zone"
  * zone = ""
leeclemens commented 7 years ago

I am not able to reproduce this issue, testing without IDO but the same host.vars style configuration. Also not using a wrap-around midnight timeframe (see below).

The downtimes for each perspective window are indeed created, although it could be in an unanticipated manner.

I ran icinga2 daemon -C before running icinga2 object list --type downtime.

vars.wiederkehrende_downtime = "13:40-13:45,13:45-13:50"

Sat Jun 24 13:38:37 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498325916-0' of type 'Downtime':
* start_time = 1498326000  # Saturday, June 24, 2017 1:40:00 PM
* end_time = 1498326300    # Saturday, June 24, 2017 1:45:00 PM

Sat Jun 24 13:40:38 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498325916-0' of type 'Downtime':
* start_time = 1498326000  # Saturday, June 24, 2017 1:40:00 PM
* end_time = 1498326300    # Saturday, June 24, 2017 1:45:00 PM
Object 'testhost-timeperiod-5261!testmaster-1498326036-3' of type 'Downtime':
* start_time = 1498326300  # Saturday, June 24, 2017 1:45:00 PM
* end_time = 1498326600    # Saturday, June 24, 2017 1:50:00 PM

Sat Jun 24 13:45:39 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498326036-3' of type 'Downtime':
* start_time = 1498326300  # Saturday, June 24, 2017 1:45:00 PM
* end_time = 1498326600    # Saturday, June 24, 2017 1:50:00 PM
Object 'testhost-timeperiod-5261!testmaster-1498326336-4' of type 'Downtime':
* start_time = 1498412400  # Sunday, June 25, 2017 1:40:00 PM
* end_time = 1498412700    # Sunday, June 25, 2017 1:45:00 PM

Sat Jun 24 13:50:41 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498326336-4' of type 'Downtime':
* start_time = 1498412400  # Sunday, June 25, 2017 1:40:00 PM
* end_time = 1498412700    # Sunday, June 25, 2017 1:45:00 PM

Test system: CentOS Linux release 7.3.1611

commit 0e423df4a0e366680dd322af6ec3968f5e8790ab
Merge: 04757d1 c8b4fee
Author: Michael Friedrich <michael.friedrich@icinga.com>
Date:   Fri Jun 23 12:56:05 2017 +0200

I will set up a script to run overnight to test the edge-case specific to midnight, but wanted to provide these observations here.

While I can see how it can be observed as a bug (specifically the first iteration) and due to the caching of object list, there doesn't seem to be a functional issue here (unless running daemon -C circumvented an issue, but I haven't seen the issue in practice).

leeclemens commented 7 years ago

The test overnight seems to have produced similar results, the second downtime is created but not until the first time window is entered.

vars.wiederkehrende_downtime = "20:00-24:00,00:00-04:00"

Sat Jun 24 19:59:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498344314-0' of type 'Downtime':
* start_time = 1498348800  # Saturday, June 24, 2017 8:00:00 PM
* end_time = 1498363200    # Sunday, June 25, 2017 12:00:00 AM

Sat Jun 24 20:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498344314-0' of type 'Downtime':
* start_time = 1498348800  # Saturday, June 24, 2017 8:00:00 PM
* end_time = 1498363200    # Sunday, June 25, 2017 12:00:00 AM
Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498348814-2' of type 'Downtime':
* start_time = 1498363200  # Sunday, June 25, 2017 12:00:00 AM
* end_time = 1498377600    # Sunday, June 25, 2017 4:00:00 AM

Sun Jun 25 00:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498348814-2' of type 'Downtime':
* start_time = 1498363200  # Sunday, June 25, 2017 12:00:00 AM
* end_time = 1498377600    # Sunday, June 25, 2017 4:00:00 AM
Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498363213-3' of type 'Downtime':
* start_time = 1498435200  # Sunday, June 25, 2017 8:00:00 PM
* end_time = 1498449600    # Monday, June 26, 2017 12:00:00 AM

Sun Jun 25 04:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498363213-3' of type 'Downtime':
* start_time = 1498435200  # Sunday, June 25, 2017 8:00:00 PM
* end_time = 1498449600    # Monday, June 26, 2017 12:00:00 AM
jgrammen-agilitypr commented 6 years ago

This is still an issue, and it is very annoying that I cannot schedule a period across midnight. monday = "00:00-1:00,21:30-24:00" The above does not work. To fix i had to create two separate ScheduledDowntime

Mikesch-mp commented 6 years ago

My solution over midnight is like this

ranges = {
  "monday" = "20:00-26:00"
}

in my scheduledDowntimes objects.

Crunsher commented 6 years ago

If this workaround works reliably we should document it at least as this question comes up a lot. I did not know about this.

Mikesch-mp commented 6 years ago

I found it once in an issue, but dont ask me which one :)

Al2Klimov commented 5 years ago

If the "clock overflow" @Mikesch-mp shown works... I exactly know how to fix this one...

Al2Klimov commented 5 years ago

Hello guys!

Please could you test the linked PR?

Best, AK

nilmerg commented 5 years ago

Just had the pleasure to encounter this bug as well. The clock overflow workaround works perfectly.

apply ScheduledDowntime "test-downtime" to Host {
  author = "icingaadmin"
  comment = "Scheduled downtime for test"

  ranges = {
    monday = "17:00-19:00,22:00-30:00"
    tuesday = "17:00-19:00,22:00-30:00"
    wednesday = "17:00-19:00,22:00-30:00"
    thursday = "17:00-19:00,22:00-30:00"
    friday = "17:00-19:00,22:00-30:00"
  }

  assign where host.name == "localhost"
}

What I noticed as well, is that what @leeclemens mentioned about subsequent time windows. The second time window above (22:00-30:00) is not planned by Icinga (not visible in Icinga Web 2) until the first is active. Kind of irritating, but it works.

dnsmichi commented 5 years ago

The unit tests are a bit sparse for the timeperiod class, I'll enhance them in order to test the PR.

dnsmichi commented 5 years ago

Unfortunately the PR doesn't work, see my comments there.