You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assignee: mfriedrich
Status: Resolved (closed on 2016-08-17 14:57:56 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-17 14:57:56 +00:00 (in Redmine)
Icinga Version: 2.4.10
Backport?: Not yet backported
Include in Changelog: 1
When I connect to the event stream the API provides for the Downtime there are three different types, but they do not exactly provide the information needed. I would like to get information about Downtimes starting and ending with the corresponding host/service.
DowntimeTriggered provides the following information:
So DowntimeRemoved provides the information about ending downtimes because it will always trigger a remove event afterwards, but also if it is removed by other events.
So my preference would be adding the additional information to DowntimeTriggered and trigger an event during start and end of a downtime. This would allow to simply connect to one type and get all required information.
This issue has been migrated from Redmine: https://dev.icinga.com/issues/12464
Created by dgoetz on 2016-08-17 11:57:28 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2016-08-17 14:57:56 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-17 14:57:56 +00:00 (in Redmine)
When I connect to the event stream the API provides for the Downtime there are three different types, but they do not exactly provide the information needed. I would like to get information about Downtimes starting and ending with the corresponding host/service.
DowntimeTriggered provides the following information:
If this would provide information on which host/service it was triggered, I would have the the starting information.
DowntimeAdded and DowntimeRemoved provides the following information:
So DowntimeRemoved provides the information about ending downtimes because it will always trigger a remove event afterwards, but also if it is removed by other events.
So my preference would be adding the additional information to DowntimeTriggered and trigger an event during start and end of a downtime. This would allow to simply connect to one type and get all required information.
Changesets
2016-08-17 14:57:22 +00:00 by mfriedrich e5566a6
The text was updated successfully, but these errors were encountered: