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
