Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #9016] Downtimes which have been triggered are not properly recorded in the database #2881

Closed
icinga-migration opened this issue Apr 8, 2015 · 6 comments
Labels
area/db-ido Database output bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

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

Created by elippmann on 2015-04-08 15:30:32 00:00

Assignee: mfriedrich
Status: Resolved (closed on 2015-04-12 12:43:26 00:00)
Target Version: 2.3.4
Last Update: 2015-04-12 12:43:26 00:00 (in Redmine)

Icinga Version: v2.3.0-82-gdda273d
Backport?: Already backported
Include in Changelog: 1

If a downtime is triggered, Icinga 2 seems to update the trigger_time column only.

debug.log wrote:

[2015-04-08 17:16:35 0200] notice/ExternalCommandProcessor: Creating downtime for service localhost!http
[2015-04-08 17:16:35 0200] notice/Checkable: Checkable 'localhost!http' already in a NOT-OK state. Triggering downtime now.
[2015-04-08 17:16:35 0200] notice/Checkable: Triggering downtime with ID '1368'.
[2015-04-08 17:16:35 0200] debug/DbEvents: updating triggered service downtime (id = 1368) for 'localhost!http'
[2015-04-08 17:16:35 0200] debug/DbEvents: add log entry history for 'localhost!http'
[2015-04-08 17:16:35 0200] notice/Checkable: Added downtime with ID '1368' between '2015-04-08 17:16:13' and '2015-04-08 17:17:13'.
[2015-04-08 17:16:35 0200] debug/DbEvents: removing service downtime (id = 1368) for 'localhost!http'
[2015-04-08 17:16:35 0200] debug/DbEvents: adding service downtime (id = 1368) for 'localhost!http'
[2015-04-08 17:16:35 0200] debug/DbEvents: adding service downtime (id = 1368) for 'localhost!http

MySQL wrote:

was_started: 0
actual_start_time: 0000-00-00 00:00:00
actual_start_time_usec: 0
is_in_effect: 0
trigger_time: 2015-04-08 17:16:35

Attachments

Changesets

2015-04-12 12:38:35 00:00 by (unknown) 37f2459

Trigger downtimes for NOT-OK states after OnDowntimeAdded()

The fix in #8389 must happen *after* adding the downtime which signals an
insert into the IDO DB.
Once the downtimes have been added to the database, the additional
trigger_time and is_in_effect can be updated accordingly, *if* the
current object is already in a NOT-OK state.

fixes #9016

2015-04-12 12:41:30 00:00 by (unknown) e659784

Trigger downtimes for NOT-OK states after OnDowntimeAdded()

The fix in #8389 must happen *after* adding the downtime which signals an
insert into the IDO DB.
Once the downtimes have been added to the database, the additional
trigger_time and is_in_effect can be updated accordingly, *if* the
current object is already in a NOT-OK state.

fixes #9016

Relations:

@icinga-migration
Copy link
Author

Updated by elippmann on 2015-04-09 09:01:09 00:00

  • Relates set to 8846

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-04-12 12:06:47 00:00

  • Relates set to 9014

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-04-12 12:37:58 00:00

  • File added Auswahl_146.png
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Target Version set to 2.4.0
  • Estimated Hours set to 2

Ok. That's actually a race-condition I've introduced with fixing the missing triggered downtime on schedule if the host/service is already in a NOT-OK state in #8389.

lib/icinga/checkable-downtime.cpp

  • TriggerDowntime() updates the downtime entry for the host/service including the trigger time (which does not exist at this point) in DbEvents::TriggerDowntime
  • OnDowntimeAdded() will fire DbEvents::AddDowntimeByType() deleting and inserting the downtime (replace into). At this point the trigger time is not written correctly.

My fix from #9014 is partially fixing this problem by not setting the trigger_time on a newly added downtime, but depending on the TriggerDowntime() function to do that - we'll fix this here.

Wrong

MariaDB [icinga]> select * from icinga_scheduleddowntime\G
*************************** 1. row ***************************
  scheduleddowntime_id: 1
           instance_id: 1
         downtime_type: 1
             object_id: 60223
            entry_time: 2015-04-12 14:26:09
           author_name: icingaadmin
          comment_data: test
  internal_downtime_id: 1
       triggered_by_id: 0
              is_fixed: 1
              duration: 0
  scheduled_start_time: 2015-04-12 14:25:56
    scheduled_end_time: 2015-04-12 15:25:56
           was_started: 0
     actual_start_time: 0000-00-00 00:00:00
actual_start_time_usec: 0
          is_in_effect: 0
          trigger_time: 2015-04-12 14:26:09
    endpoint_object_id: 58653
1 row in set (0,00 sec)

Fixed

MariaDB [icinga]> select * from icinga_scheduleddowntime\G
*************************** 1. row ***************************
  scheduleddowntime_id: 2
           instance_id: 1
         downtime_type: 1
             object_id: 60223
            entry_time: 2015-04-12 14:35:45
           author_name: icingaadmin
          comment_data: test
  internal_downtime_id: 1
       triggered_by_id: 0
              is_fixed: 1
              duration: 0
  scheduled_start_time: 2015-04-12 14:35:38
    scheduled_end_time: 2015-04-12 15:35:38
           was_started: 1
     actual_start_time: 2015-04-12 14:35:45
actual_start_time_usec: 135752
          is_in_effect: 1
          trigger_time: 2015-04-12 14:35:45
    endpoint_object_id: 58653
1 row in set (0,00 sec)

Auswahl_146.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-04-12 12:38:18 00:00

  • Relates set to 8389

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-04-12 12:41:55 00:00

  • Target Version changed from 2.4.0 to 2.3.4
  • Backport? changed from TBD to Yes

@icinga-migration
Copy link
Author

Updated by Anonymous on 2015-04-12 12:43:26 00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 37f2459.

@icinga-migration icinga-migration added bug Something isn't working area/db-ido Database output labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.3.4 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/db-ido Database output bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant