Good Practices : Service templates, why you should be using it!

In the previous article, we explained you why we thought that to attach a service to an host group wasn’t such a good idea. At the end, we suggested that you prefer service template for the configuration of your monitoring platform.
So, you will find in this article all good reasons to use service templates (ease, flexibility…) and a detailled example on how to use them efficiently.

Definition

A service template is a Centreon monitoring object that has all the characteristics needed to define a service. Basically, we use it like a base to configure a large number of services.
So, a service template is in practice some kind of preconfigured service : some information are already there. Of course you don’t to definite all service information within the service template.

For instance, a service have some compulsory/necessary parameters, it won’t work without them. A service template doesn’t have this constraint. For example, to definite a template service, you have to go on the page « Configuration → Services → Templates» and to click on “add” :

01_creation_modele_de_serviceIn the screen-shot above, only the first two lines are compulsory : the service name (“Alias”) and the service template name (“Service Template Model”). Some other parameters such as the monitoring command (“Check command”) and arguments (“args”) are already set up too.

Service legacy/inheritance with a service template

A service can inherit from a service template : when you define a service, you need to indicate that it refers to a service template. So, it inherits all parameters which have been set up in the “parent” service template. For example, when you create a service, you can choose the service template from which this service will inherit thanks to the “Service Template” configuration option:

02_creation_service_base_sur_modeleIn the screen-shot below, a service has been created and is based on “SNMP-DISK-/” model/template.

Overload

When a service inherits from a service template, you always have the option to “force/overload” a parameter. You can force the parameter for a specific service even if you have already defined it in its “parent” service template. In practical terms, this specific service will keep all parameters defined in the parent template but get the very parameter you defined just for him.

Service template legacy with service template

A service template can inherit from a service template as well. The concept is the same than described above: legacy and overload. This feature is pretty important because it is the very best way to create and industrialize your monitoring configuration.

03_heritage_modele_de_serviceIn the below example, the service template called “SNMP-DISK-/” is based on a service template called “generic service”.

An example of a hierarchical system using Service Template Legacy

Take, for example, a service template called “generic service”. Its role is to define a generic model with all default settings.

Name of parameter
Parameter Value
Comment
Alias
generic-service
Required parameter: it defines the name of service, as it will appear in monitoring
Service Template Name
generic-service
Required parameter: it defines the name of service template
Is volatile
No
By default, any service is volatile.
Check Period
24×7
By default, all services are monitored in 24×7
Max Check Attempts
3
By default, all of my services get 3 consecutive attempts in error before to be in confirmed error status
Normal Check Interval
15
By default, interval between 2 tests
Retry Check Interval
1
By default, interval between 2 tests when the error status is not confirmed
Active Checks Enabled
yes
By default, all my tests are active
Passive Checks Enabled
No
By default, all my tests are not passive
Notification Enabled
Yes
By default, notifications are activated
Notification Interval
0
By default, only one notification is sent.
Notifcation Period
24×7
By default, notification is 24×7
Notification Type
Warning, Critical
By default, I notify only warning “critics” and “attention”

The configuration below is a configuration that I consider by default. All my services need this configuration.

Take a second service template called “p1-services”: the priority 1 services that we monitor frequently :

Name of parameter
Parameter Value
Comment
Alias
p1-service
Required parameter: it defines the name of service, as it will appear in monitoring
Service Template Name
p1-service
Required parameter: it defines the name of service template
Service Template Model
generic-service
The service template “p1-service” inherits from the service template “generic-service”..
Normal Check Interval
5
Overloaded parameter: Interval between two shorter tests: priority service.

Take a third service template called “p2-services”: the priority 2 service that we monitor less frequently:

Name of parameter
Parameter Value
Comment
Alias
p2-service
Required parameter: it defines the name of service, as it will appear in monitoring
Service Template Name
p2-service
Required parameter: it defines the name of service template
Service Template Model
generic-service
The service template “p2-service” inherits from the service template “generic-service”..

I don’t change any other parameter: a parameter by default is well suited.

Take a fourth service template called “p3-service”: the priority 3 service that we monitor less frequently:

Name of parameter
Parameter Value
Comment
Alias
p3-service
Required parameter: it defines the name of service, as it will appear in monitoring
Service Template Name
p3-service
Required parameter: it defines the name of service template
Service Template Model
generic-service
The service template “p3-service” inherits from the service template “generic-service”..
Normal Check Interval
60
Overloaded parameter: Interval between two longer tests: less priority service.

A service template that can monitor an important process of my system:

Name of parameter
Parameter Value
Comment
Alias
proc-syslog
Required parameter: it defines the name of service, as it will appear in monitoring
Service Template Name
SNMP-PROC-SYSLOG
Required parameter: it defines the name of service template
Service Template Model
p1-service
The service template “p1-service” inherits from the service template “generic-service”..
Check Command
check_centreon_process
Using the command within we can monitor a process
Args
SNMP version : 2c
community : public
process name: syslogd
Command arguments

The interest of this below case is to show a simple organisation as an example: a standard configuration is presented in the high level model (“root object”). All service templates inherit from this model by default.

Strategy

We wanted to focus on service templates since they really bring added-value for monitoring admins: simplicity and ease of conception.
To get the best of service templates you need to define your monitoring policy and your roll out and conception strategy. Most of the time, customers have 2 types of behaviours:

  1. The most frequent one: a divided organisation. There are 5 hierarchical levels between the high level model and the service. The models are so divided than we can’t read the configuration and therefore, if you want to modify a service, you have to modify several service templates.
  2. The less frequent: an organisation not enough divided. There is only one level between the high level model and the service. Actually, all models define all parameters. It’s not really enough since you will probably have to overload several characters and you will not save time …

It would be hard to define the “right number” for the total number of models or hierarchical level models. It depends of the numbers of different equipments, IT organisation and teams. But, we can say that you need at least 2 hierarchical levels in service templates and to have more than 5 levels is too hard to manage. Stay tuned for the next articles!

Incoming search terms:

  • content

Leave a Reply