> Am 10.02.2015 um 18:01 schrieb Neil Katin <[email protected]>: > > > Thanks much for the detailed and clear answer.
You're welcome :) > > I think for our use-case adding metadata to the service, and applying > notifications based on that metadata is the easiest way to go. Keep us updated how the migration goes, and become an icinga user :-) https://www.icinga.org/community/icinga-users/ Kind regards, Michael > > 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#notifications >> >> You 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-conf >> >> Regarding a migration, you might find the following hints useful: >> >> http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/migration#manual-config-migration-hints-notifications >> >> >> Kind regards, >> Michael >> >> >>> >>> Thanks 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 -- 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
