Notifications in host/service history from zones

We have a top down config sync setup. When I configure the satellite to do the notifications, it works, but they don’t appear in the history of a host:

There should be a ‘bell’ icon.

Looking at the debug log, the satellite relays the notification:

[2020-04-09 13:53:58 +0200] notice/ApiListener: Relaying 'event::NotificationSentToAllUsers' message
[2020-04-09 13:53:58 +0200] notice/ApiListener: Relaying 'event::NotificationSentToAllUsers' message
[2020-04-09 13:53:58 +0200] notice/ApiListener: Relaying 'event::NotificationSentUser' message
[2020-04-09 13:53:58 +0200] notice/ApiListener: Relaying 'event::NotificationSentUser' message

The master receives it:

[2020-04-09 14:04:33 +0200] notice/JsonRpcConnection: Received 'event::NotificationSentToAllUsers' message from identity 'sentinel.bla.com'.
[2020-04-09 14:04:33 +0200] notice/JsonRpcConnection: Received 'event::NotificationSentToAllUsers' message from identity 'sentinel.bla.com'.
[2020-04-09 14:04:33 +0200] notice/JsonRpcConnection: Received 'event::NotificationSentUser' message from identity 'sentinel.bla.com'.
[2020-04-09 14:04:33 +0200] notice/JsonRpcConnection: Received 'event::NotificationSentUser' message from identity 'sentinel.bla.com'.

I can’t find anything in the docs on api, objects or zones that allow accepting these kind of relays. Can it be configured to do so? Or is it not implemented?

Hi,

as long the satellites dont write it to the same ido db (which they should not do) you will not see any notification send out by them. Anyway why you want to let the satellites send out messages?

Regards,
Carsten

We have two zones, each with an icinga host, and it made sense to me to make them independent, with one dashboard. You also have situations like net split, split brain, etc. This would make it easy to deal with, I thought.

1 Like

Actually we did it all the time until last update like you described it.
For me it makes also total sense to have notification on satellites and i would have expected it all the time the default for distributed setups. each satellite has dedicated hardware with sms modem for special situations ( dc-split ).
at least i would have expect that the relaying logic has some fallback when the master is not reachable to send via satellite.

How it was done:
mail-hostzone-notification.sh created from mail-host-notification.sh

added a new parameter ZONENAME

ZONENAME_CONST="<satelite_zone>"
...
  -z ZONENAME (\$host.zone\$)
...
    z) ZONENAME=$OPTARG ;; # required
...
for P in LONGDATETIME HOSTNAME HOSTDISPLAYNAME HOSTOUTPUT HOSTSTATE USEREMAIL NOTIFICATIONTYPE ZONENAME ; do
...
if [ "$ZONENAME_CONST" = "$ZONENAME" ]; then
...
else
...
fi

similar with mail-servicezone-notification.sh created from mail-service-notification.sh