Icinga 2 is not transmitting a runtime update in case only the plugin output of a checkable changes. Such an update is only available in redis as long as no hard state change occurs. Icinga DB Web accesses redis directly to visualize the most recent outputs in the UI.
Icinga Notifications does not have direct access like this and will never have it, so it's Icinga DB's responsiblity that transmitted notifications contain the most recent output as well. In order for this to work, it needs to poll redis every 5 minutes for updated outputs.
This should be coupled with the /incidents API endpoint provided by Icinga Notifications:
- Fetch open incidents via API
- Fetch matching outputs via redis (1-2 queries, for hosts and services)
- Push updated incident messages via API
With #1139 the first fetch can receive only incidents for which it is responsible and the accompanying object tags should provide enough data to construct the redis key for each individual object to keep interactions with redis to a minimum.
Icinga 2 is not transmitting a runtime update in case only the plugin output of a checkable changes. Such an update is only available in redis as long as no hard state change occurs. Icinga DB Web accesses redis directly to visualize the most recent outputs in the UI.
Icinga Notifications does not have direct access like this and will never have it, so it's Icinga DB's responsiblity that transmitted notifications contain the most recent output as well. In order for this to work, it needs to poll redis every 5 minutes for updated outputs.
This should be coupled with the
/incidentsAPI endpoint provided by Icinga Notifications:With #1139 the first fetch can receive only incidents for which it is responsible and the accompanying object tags should provide enough data to construct the redis key for each individual object to keep interactions with redis to a minimum.