Also send notifications outside or irrespective of any incident

[nilmerg]

We have currently only so-called event rules which handle incoming events to map them to such. This needs to be extended in order to be able to handle incoming events, that may not be related to an incident, let alone cause one. To achieve this in Icinga Notifications, the user will be able to set up escalation rules (what event rules were) and notification rules. This is about what the latter are and how they' re handled.

Database schema

Notification rules differ to escalation rules only in that they do not have escalations. So, I'm inclined to suggest to add an additional enum column to table rule and be done with it. Though, recipients remain, and rule_escalation_recipient is bound to rule_escalation, so either decouple this somewhat or introduce a new table.

How it should work

As mentioned, notification rules should be able to trigger notifications without any relation to an incident. But they should of course be respected to not duplicate notifications just like it is done in case several escalation rules trigger notifications to the same recipient.

stateDiagram-v2
    direction LR
    [*] --> Event
    Event --> EscalationRule
    Event --> NotificationRule
    EscalationRule --> Recipient
    NotificationRule --> Recipient
    Recipient --> [*]

Loading

Events are to be matched using a separate property called properties. The value is the same as for the relations as described in #406. Though, its purpose is to describe the event, not the object and hence, Icinga DB may include type: Downtime or previous_hard_state: ok. properties are also expected to take part in attribute negotiation.

In contrast to escalation rules, notification rules may match based on properties and relations. Both should be merged before filter evaluation, but preferably only after validation when the negotiation is finished.