RFC: Escalations Sets

[Ethan Galstad]

Marcus Fleige wrote:
> Hi Ethan, hi List,
> 
> i'm playing around with the new inheritance features in Nagios 3, and 
> i'm pretty amazed about the possibilities they offer. Now, as i'm 
> preparing a presentation for the upcoming german nagios workshop about 
> configuration management, i'm evaluating the new prospects to build a 
> small, easy to handle, template based configuration.
> 
> the question coming up when it comes to escalations: Is there a cause 
> why Nagios lacks the feature to bind multiple escalations to a set of 
> escalations?
> 
> When i have a look at my prod config, a huge amount of config lines are 
> assigned to the escalations, repeating itself over and over again with 
> only very small changes (first_escalation, last_escalation). I'm using 
> three up to five step escalations, so for each defined service, i need 
> to define another 3 to 5 escalation blocks.
> 
> One small example:
> 
> These are standard escalations, as i need them for most services.
> 
> define serviceescalation { 
>  
>                                                     		contact_groups 
>        <Group1>
> 		first_notification      1 
> 
>                  last_notification       1 
>  
> 
>                  notification_interval   5 
> 
>                  host_name               <Host1>
>                  service_description     <Service1> 
> 
>          } 
>  
> 
>  
>  
> 
> define serviceescalation { 
>  
>                                                     		contact_groups 
>        <Group2>
> 		first_notification      2 
> 
>                  last_notification       2 
>  
> 
>                  notification_interval   10 
> 
>                  host_name               <Host1>
>                  service_description     <Service1> 
> 
>          } 
>  
> 
> 
> define serviceescalation { 
>  
>                                                     		contact_groups 
>        <Group2>, <Group3>
> 		first_notification      3 
> 
>                  last_notification       0 
>  
> 
>                  notification_interval   10 
> 
>                  host_name               <Host1>
>                  service_description     <Service1> 
> 
>          } 
>  
> 
> 
> Now, as these escalation form a logical unit, it would be nice to be 
> able to stick them together. Maybe it would be possible to name them 
> (like Hosts or Services) and bind them like Host-/Servicegroups:
> 
> define serviceescalation {
> 		name			standard-step1
> 		[...]
> }
> define serviceescalation {
> 		name			standard-step2
> 		[...]
> }
> define serviceescalation {
> 		name			standard-step2
> 		[...]
> }
> 
> define serviceescalationsset {
> 		name			standard-escalation
> 		use			standard-step1, standard-step2, standard-step3
> 		[...]
> }
> 
> In consequence, it would be rather simple to define escalations for 
> example by just combining service and escalationset:
> 
> define service {
> 		host_name		<Host1>
> 		service_description	<Service1>
> 		escalationset		standard-escalation
> 		[...]
> }
> 
> 
> What do you think about that? Would it be useful for anyone else? How 
> much work would it be to build such an enhancement?
> 
> 
> Regards,
> 
> Marcus Fleige
> 

I agree that this could be a useful feature.  You can't do this quite as
easily as you suggest, but you can at least make use of templates to
make shorter escalation definitions...

# TEMPLATES
define serviceescalation{
	name			se1-template
	first_notification	6
	last_notification	9
	contact_groups		somegroup
	register		0
	}

define serviceescalation{
	name			se2-template
	first_notification	10
	last_notification	0
	contact_groups		someothergroup
	register		0
	}

# ESCALATIONS
define serviceescalation{
	use			se1-template
	host_name		somehost
	service_description	someservice
	}

define serviceescalation{
	use			se2-template
	host_name		somehost
	service_description	someservice
	}

You can also use hostgroup_name and servicegroup_name directives in
escalation definitions and * wildcards for the service_description to
simplify the config.


Ethan Galstad
Nagios Developer
___
Email: nagios at nagios.org
Web:   www.nagios.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/