We want to show Icinga Notifications history entries alongside our own history entries. Icinga Notifications v1.0 will provide a new API endpoint GET /notifications?since=<timestamp> for this.
Database
Since there's already a notification_history table, I'd go with alert_history.
Note that this isn't intended as 1:1 relation with history, but as 1:n (history.id <-> alert_history.history_id) relation. The linked history row is supposed to be the event that is identified by event_id.
Visualization Related Changes
Icinga DB Web needs to be able to join alert_history on demand. For this a new column history.alert_count is required. i.e. The total amount of alert_history rows linked to it. The goal is to be able to easily determine, based on a particular history row, if any related entries in alert_history exist. And because the alert_history relation is not always joined, the number of entries must be derived from this column as well.
We want to show Icinga Notifications history entries alongside our own history entries. Icinga Notifications v1.0 will provide a new API endpoint
GET /notifications?since=<timestamp>for this.Database
Since there's already a
notification_historytable, I'd go withalert_history.Note that this isn't intended as 1:1 relation with
history, but as1:n(history.id<->alert_history.history_id) relation. The linkedhistoryrow is supposed to be the event that is identified byevent_id.Visualization Related Changes
Icinga DB Web needs to be able to join
alert_historyon demand. For this a new columnhistory.alert_countis required. i.e. The total amount ofalert_historyrows linked to it. The goal is to be able to easily determine, based on a particularhistoryrow, if any related entries inalert_historyexist. And because thealert_historyrelation is not always joined, the number of entries must be derived from this column as well.