mirror of https://github.com/Icinga/icinga2.git
49 lines
1.3 KiB
Markdown
49 lines
1.3 KiB
Markdown
## Using Templates
|
|
|
|
Templates may be used to apply a set of similar settings to more than one
|
|
object.
|
|
|
|
For example, rather than manually creating a `ping` service object for each of
|
|
your hosts you can use templates to avoid having to copy & paste parts of your
|
|
configuration:
|
|
|
|
template Host "linux-server" {
|
|
services["ping"] = {
|
|
check_command = "ping4"
|
|
},
|
|
|
|
check = "ping"
|
|
}
|
|
|
|
object Host "my-server1" inherits "linux-server" {
|
|
macros["address"] = "10.0.0.1"
|
|
}
|
|
|
|
object Host "my-server2" inherits "linux-server" {
|
|
macros["address"] = "10.0.0.2"
|
|
}
|
|
|
|
In this example both `my-server1` and `my-server2` each get their own `ping`
|
|
service check. Each host gets its own host `check` defined as the `ping`
|
|
service too.
|
|
|
|
Objects as well as templates themselves can inherit from an arbitrary number of
|
|
templates. Attributes inherited from a template can be overridden in the
|
|
object if necessary.
|
|
|
|
Templates can also be used in service and notification definitions using the
|
|
`templates` attribute:
|
|
|
|
template Service "weekend-service" {
|
|
check_interval = 0.5m,
|
|
check_period = "weekend"
|
|
}
|
|
|
|
object Host "my-server1" {
|
|
services["backup"] {
|
|
check_command = "backup-check",
|
|
|
|
templates = [ "weekend-service" ]
|
|
}
|
|
}
|