Hi Michael,
Per documentation means the master and client are configured according to :
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-configuration-local
The part about recovery messages only being sent to those that receive the
down makes sense, however in our scenario the down message would have gone
to a support mail which would log a ticket and then mail our team, another
mail would just have logged another ticket, not updated the previous
ticket, whereas the up message would only go to the team thereby closing
the loop on the down message submitted via the ticketing systems.
I'll redesign the notifications accordingly.
Regards
Henti
On Tue, Mar 24, 2015 at 10:59 AM, Michael Friedrich <
michael.friedr...@netways.de> wrote:
> Am 24.03.2015 um 09:35 schrieb Henti Smith:
>
> [2015-03-24 10:19:59 +0200] information/Notification: Attempting to send
> notifications for notification object 'hostname.domain!http!mail-infra'.
> [2015-03-24 10:19:59 +0200] debug/Notification: FType=8, TypeFilter=511
> [2015-03-24 10:19:59 +0200] notice/Notification: Not sending notifications
> for notification object 'hostname.domain!http!mail-infra': state filter
> does not match
>
>
> Compare that to your configuration.
>
> template Notification "infra-service-notification" {
> command = "mail-service-notification"
> states = [ OK ]
> types = [ Problem, Acknowledgement, Recovery, Custom,
> FlappingStart, FlappingEnd,
> DowntimeStart, DowntimeEnd, DowntimeRemoved ]
> period = "24x7"
> }
>
> apply Notification "mail-infra" to Service {
> import "infra-service-notification"
> user_groups = host.vars.notification.mail.groups
> assign where host.vars.notification.mail
> }
>
> Apart from that, it does not make sense to filter only for OK messages
> (=recovery) in that regard. Icinga 2 only sends recovery notifications to
> users which have been notified of problems before. See the discussion on
> this list some months ago (look for "trivago").
>
> I suspect that the last debug line is not coming from the notification
> itself, but the user which is missing in that regard (as said, fixed in
> master).
>
> The problem is now that we still don't know which users are set on the
> host (or its imported templates).
>
> Am 23.03.2015 um 20:13 schrieb Henti Smith:
> > The host config is from the client as per the documentation. There is no
> > host object appart from the dummy ones created in the repository.
>
> Run
>
> icinga2 object list --type Host --name *yourhostname*
>
> and paste the output. I have no idea what "per the documentation" actually
> means in your scenario.
>
>
> Btw - that thread is already horribly long. 2.3 introduces a new way of
> collecting troubleshoot information. You might want to use just that in the
> future when putting questions here.
>
> icinga2 troubleshoot --include-vars --include-objects
>
> Kind regards,
> Michael
>
>
>
>
>
>
> --
> Michael Friedrich, DI (FH)
> Application Developer
>
> NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> GF: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
> http://www.netways.de | michael.friedr...@netways.de
>
> ** OSDC 2015 - April - osdc.de **
> ** Puppet Camp Berlin 2015 - April - netways.de/puppetcamp **
> ** OSBConf 2015 - September - osbconf.org **
>
> _______________________________________________
> icinga-users mailing list
> icinga-users@lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users
>
>
--
-- <X-Clacks-Overhead: GNU Terry Pratchett>
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
