Thanks much for the detailed and clear answer.
I think for our use-case adding metadata to the service, and applying notifications based on that metadata is the easiest way to go.
Neil Katin
On 02/10/2015 12:27 AM, Michael Friedrich wrote:
Am 09.02.2015 um 23:08 schrieb Neil Katin:Hi there. I'm migrating from nagios it icinga2, and I wanted to see if I'm missing an icinga2 trick. In Nagios we set the 'service_notification_commands' in some of our contacts to do special functions (like send pages, or send alerts to external notification systems). We used that in order to be able to treat these contacts just like any other contact, and have different contacts execute different commands. Looking at the icinga2 data model this binding seems to only happen at the NotificationCommand level, which are bound to Notifications. And if I'm reading things correctly: I can bind Notifications to hosts and services based on properties in the host and service, but not in the user. The only solution I see is to create multiple notification bindings based on the user-types to be notified, but I wanted to make sure I'm not missing a simpler pattern.The problem with the old-fashioned style of assinging contacts to hosts/services is rather, that you would duplicate contacts just for their notification type. In the end, at least I had "michi" (for cgi auth), "michi-mail", "michi-sms", "michi-xmpp" which had to be assigned to hosts/contacts (or mapped through their contactgroup membership). For Icinga 2 we've been sitting together and having that design in mind for the reasons mentioned above, and even further: We don't want to have that contact/contact_groups relation when generating hosts/services. That should run independent from getting your $tool (editor, cmdb, cfgmgmt, etc). For that very reason, you'll define different notifications for hosts/services, basically for each type defined by the notification command you're using, or the users/user_groups assigned to this notification. In the end, you wouldn't manually create notification objects for hosts/services - you'll just use the apply rules and generate notifications based on rules with pattern matches. E.g. assign a notification using the mail notification, take the user providing the 'email' attribute, and match on all services with the custom attribute 'production_env' set to 'NUE-*'. Or the host.name, or any other object related attribute, like assign where "web-server" in host.groups.http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#notificationsYou might of course trick Icinga2 into the old style by defining a dictionary with notification users on your host, iterating over that using apply-for loops and generating notifications out of that. But that's fairly advanced and complicates the configuration. Although it is shipped in the default example configuration to illustrate its usage.http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/getting-started#notifications-confRegarding a migration, you might find the following hints useful:http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#manual-config-migration-hints-notificationsKind regards, MichaelThanks in advance. Neil Katin _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users-- 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 | [email protected] ** CeBIT 2015 - 16.-20. März 2015 - http://www.netways.de/cebit ** ** OSDC 2015 - April - osdc.de ** ** Puppet Camp Berlin 2015 - April - netways.de/puppetcamp ** ** OSBConf 2015 - September - osbconf.org ** _______________________________________________ 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
