Sorry, it's been a while since this thread drained away ... I would also be very interested in a change that made the zone parameter work as Gerald suggested. One of my customers has a multi-zone environment where adding a second channel to send notifications from the master would be a lot of hassle, while doing it from the satellite zone is a breeze ... having 'zone' pin the place where a notification runs to the notification-enabled hosts in that zone would be great.
I was considering 'command-endpoint' for that purpose as well, but that would not proide automatic failover in case of redundant satellite setup (which is how the environment is planned to be built). I've opened feature request #5398 for this <https://github.com/Icinga/icinga2/issues/5398>. It would be great if it could be implemented. Cheers, Peter. > On 9. Sep 2016, at 10:29, Gerald Vogt <[email protected]> wrote: > > Hi Michael, > > but wouldn't it be a good idea if icinga2 honored the zone configuration of a > notification object and only sends out notifications from the zone set? > > I find it confusing that checkables are only checked on the zone configured > while notifications are sent from all zones in which the notification exists, > thereby duplicating notifications... > > Thanks, > > Gerald > > > On 09.09.16 10:16, Michael Friedrich wrote: >> >>> On 09 Sep 2016, at 09:38, Gerald Vogt <[email protected]> wrote: >>> >>> Hi! >>> >>> What's the purpose of the zone parameter in the Notification object of >>> icinga2? >>> >>> I thought it would say which zone sends the notifications but that seems >>> not the case. If you have a master-satellite setup, notifications for >>> checks of the satellite zone are duplicated and sent from the satellite and >>> the master. I find that unexpected as for checks the zone parameter defines >>> which zone runs the check so I have expected the same for notifications. >>> >>> So it seems to me that the "zone" parameter in the Notification object >>> doesn't really have a purpose. Is that right? >>> >>> We use the satellite to monitor the master and want to send out >>> notifications from the satellite only for the checks on the satellite… >> >> You can safely ignore it if you are for instance using the top down config >> sync method in zones.d (which takes care of virtually mapping the zones >> directory to that zone attribute). Specifying that manually requires >> advanced knowledge and probably only makes sense with checkable objects >> (hosts, services, as mentioned in the distributed monitoring docs). The >> documentation table lists it just because we are documenting any attribute >> made available to the user, either via config object type in static config >> files, or inside the REST API. >> >> Kind regards, >> Michael > _______________________________________________ > icinga-users mailing list > [email protected] > https://lists.icinga.org/mailman/listinfo/icinga-users _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
