Presentation Pt2: Users and Contacts

Now that we know how to integrate the two auth’s into our business we can begin to look at how we manage the actual Nagios configuration files. Assuming that your business is size-able enough then you will be working in a team driven environment which makes that 1-to-1 relationship between individual people and your hosts/services harder to manage. I mean sure you can drop them all in host groups but more often than not you would prefer alarms were logged to a team support address and you also end up building a bit of a rod for your back when some one needs to view a host/service but not receive alerts about it.

So to combat these potential ills I would recommend making a clean logical distinction in your head to differentatiate between Users and Contacts despite both being a “contact object”. The end result would look something like this from a configuration perspective:

Usercontact

Let’s focus on the Contact portion for now. There’s nothing special about the configuration of the Contact object, it’s more or less the Contact object you know and love… except now rather than the contact being “Joe”, the contact is going to be called “Network support”. We’re also going to have a 1-to-1 relationship between a Contact and a Contact-group… so we will also have a Contact-group called “Network support group”.

This is all course to:

A. Facilitate our new team based structure

and

B.  Ensure we have an incredible degree of flexibility with the ability to bend individual contacts, users and even groups in any which way we end up deeming necessary.

As an example your actual configuration would look a little like this (I really need a code-highlighter that has better indentation support):

define contact {
  name contact-user
  host_notifications_enabled 1
  service_notifications_enabled 1
  host_notification_period 24x7
  service_notification_period 24x7
  host_notification_options d,u
  service_notification_options c
  host_notification_commands notify-h-email
  service_notification_commands notify-s-email
  register 0
}

define contact {
  contact_name cu-contact
  contactgroups cg-main
  email network-support@domain.com
  use contact-user
}

define contactgroup {
  contactgroup_name cg-main
  alias Contact
  contactgroup_members vg-team
}

So to summarize, for every method of contacting a team (email, SMS, Ticket system, etc) you will have a separate contact object and then for every one of those you will also have a corresponding group.

Contact

Lets look at the User portion now so that we can make sense of creating all those groups for seemingly no good reason. The sole purpose of the User contact-object is so that we can provide authorization to our users (see part 1 for more information on this). Ideally you would synchronize the AD distribution groups for the relevant business teams with Nagios then attach those groups to the related contact groups for your Contact objects. Difficult to explain in text so hopefully this configuration example clears it up:

define contact {
  name read-contact
  host_notifications_enabled 0
  service_notifications_enabled 0
  host_notification_period none
  service_notification_period none
  host_notification_options n
  service_notification_options n
  host_notification_commands check_none
  service_notification_commands check_none
  register 0
}

define contact {
  contact_name jsm            #A user Lan logon
  contactgroups vg-team
  use read-contact
}

define contactgroup {
  contactgroup_name vg-team   #Ideally an AD Group for jsm's team
  alias IT Team
}

define contactgroup {
  contactgroup_name cg-main
  alias Contact
  contactgroup_members vg-team
}

As you can see a User object never receives notifications it is merely a stub for matching logon credentials and providing authorization for that user.

Hopefully now you can see the method to the madness, this distinction in object types gives us a tremendous amount of flexibility both with how we present Nagios to our users and with how we are able to manipulate our actual notifications. You can set one-to-one or one-to-many relationships in so many different ways with this configuration structure that you should never end up stuck handling that ‘one’ inevitable exception.

Links

Presentation Pt1: User Permissions

Presentation Pt2: Users and Contacts

Presentation Pt3: Hosts and Services

Presentation Pt4: The art of service dependencies

comments powered by Disqus