Update documentation reflecting current changes.

Refs #5855
This commit is contained in:
Michael Friedrich 2014-04-04 18:41:54 +02:00
parent 31d54b2760
commit fb038b3e4f
16 changed files with 229 additions and 244 deletions

View File

@ -138,8 +138,8 @@ The `conf.d/localhost.conf` file contains our first host definition:
object Host "localhost" { object Host "localhost" {
import "linux-server" import "linux-server"
macros.address = "127.0.0.1" vars.address = "127.0.0.1"
macros.address6 = "::1" vars.address6 = "::1"
} }
This defines the host `localhost`. The `import` keyword is used to import This defines the host `localhost`. The `import` keyword is used to import
@ -147,9 +147,10 @@ the `linux-server` template which takes care of setting up the `ping4` and
`ping6` services for the host as well as adding the host to the `linux-servers` `ping6` services for the host as well as adding the host to the `linux-servers`
host group. host group.
The `macros` attribute can be used to define macros that are available for all The `vars` attribute can be used to define custom attributes that are available
services which belong to this host. Most of the templates in the Icinga Template for all services which belong to this host. Most of the templates in the Icinga
Library require an `address` macro. Template Library require an `address` custom attribute defined in the `vars`
dictionary.
apply Service "icinga" { apply Service "icinga" {
import "generic-service" import "generic-service"

View File

@ -57,7 +57,7 @@ UI installation URL:
> >
> Due to compatibility restrictions, not all features available in Icinga 1.x > Due to compatibility restrictions, not all features available in Icinga 1.x
> Classic UI will be available with Icinga 2. The different handling of > Classic UI will be available with Icinga 2. The different handling of
> [commands](#differences-1x-2-commands) and [macros](#differences-1x-2-macros) > [commands](#differences-1x-2-commands) and [custom attributes](#differences-1x-2-macros)
> renders the command expander invalid for example. > renders the command expander invalid for example.

View File

@ -15,7 +15,7 @@ on the same physical device.
Here is an example of a host object which defines two child services: Here is an example of a host object which defines two child services:
object Host "my-server1" { object Host "my-server1" {
macros.address = "10.0.0.1" vars.address = "10.0.0.1"
check = "ping4" check = "ping4"
} }

View File

@ -7,26 +7,14 @@ events should be handled.
> **Note** > **Note**
> >
> Define the global `PluginDir` constant (located in > Define the global `PluginDir` constant (located in
> `/etc/icinga2/conf.d/macros.conf` by default) and use > `/etc/icinga2/constants.conf` by default) and use
> it in all your command object definitions. > it in all your command object definitions.
> Put your plugins and scripts into the directory defined by the `PluginDir` constant > Put your plugins and scripts into the directory defined by the `PluginDir` constant
> and make sure they are executable by the Icinga 2 user. > and make sure they are executable by the Icinga 2 user.
### <a id="environment-macros"></a> Environment Macros ### <a id="command-environment-variables"></a> Environment Varialbes for Commands
If your plugins require environment macros instead of command arguments you have Please check [Runtime Custom Attributes as Environment Variables](#runtime-custom-attribute-env-vars).
to define all macros in the `export_macros` attribute as list.
export_macros = [
"HOSTNAME",
"SERVICEDESC",
"SERVICESTATE"
]
> **Note**
>
> Use templates to define global `export_macros` attributes for the three
> command types and let each command object inherit the attribute.
### <a id="check-commands"></a> Check Commands ### <a id="check-commands"></a> Check Commands
@ -49,15 +37,15 @@ all available options. Our example defines warning (`-w`) and
critical (`-c`) thresholds for the disk usage. Without any critical (`-c`) thresholds for the disk usage. Without any
partition defined (`-p`) it will check all local partitions. partition defined (`-p`) it will check all local partitions.
Define the default check command macros `wfree` and `cfree` (freely Define the default check command custom attribute `wfree` and `cfree` freely
definable naming schema) and their default threshold values. You can definable naming schema) and their default threshold values. You can
then use these macros on the command line. then use these custom attributes as runtime macros on the command line.
> **Note** > **Note**
> >
> The default macros can be overridden by the macros defined in > The default custom attributes can be overridden by the custom attributes
> the service using the check command `disk`. The macros can also > defined in the service using the check command `disk`. The custom attributes
> be inherited from a parent template using additive inheritance (`+=`). > can also be inherited from a parent template using additive inheritance (`+=`).
object CheckCommand "disk" { object CheckCommand "disk" {
import "plugin-check-command" import "plugin-check-command"
@ -68,19 +56,19 @@ then use these macros on the command line.
"-c", "$cfree$%" "-c", "$cfree$%"
], ],
macros.wfree = 20 vars.wfree = 20
macros.cfree = 10 vars.cfree = 10
} }
The host `localhost` with the service `disk` checks all disks with modified The host `localhost` with the service `disk` checks all disks with modified
macros (warning thresholds at `10%`, critical thresholds at `5%` free disk custom attributes (warning thresholds at `10%`, critical thresholds at `5%`
space). free disk space).
object Host "localhost" { object Host "localhost" {
import "generic-host" import "generic-host"
macros.address = "127.0.0.1" vars.address = "127.0.0.1"
macros.address6 = "::1" vars.address6 = "::1"
} }
apply Service "disk" { apply Service "disk" {
@ -88,8 +76,8 @@ space).
check_command = "disk" check_command = "disk"
macros.wfree = 10 vars.wfree = 10
macros.cfree = 5 vars.cfree = 5
} }
@ -105,10 +93,12 @@ interfaces (E-Mail, XMPP, IRC, Twitter, etc).
Below is an example using runtime macros from Icinga 2 (such as `$SERVICEOUTPUT$` for Below is an example using runtime macros from Icinga 2 (such as `$SERVICEOUTPUT$` for
the current check output) sending an email to the user(s) associated with the the current check output) sending an email to the user(s) associated with the
notification itself (`email` macro attribute provided as `$USERMACRO$`). notification itself (`email` custom attribute provided as `$USERMACRO$`).
If you require default macro definitions, you can add a macro dictionary as shown for the If you require default custom attribute definitions, you can add a `vars` dictionary
`CheckCommand` object. as shown for the `CheckCommand` object.
TODO
object NotificationCommand "mail-service-notification" { object NotificationCommand "mail-service-notification" {
import "plugin-notification-command" import "plugin-notification-command"
@ -168,7 +158,7 @@ as environment variables and can be used in the notification script:
Unlike notifications event commands are called on every service state change Unlike notifications event commands are called on every service state change
if defined. Therefore the `EventCommand` object should define a command line if defined. Therefore the `EventCommand` object should define a command line
evaluating the current service state and other service runtime attributes evaluating the current service state and other service runtime attributes
available through runtime macros. Runtime macros such as `$SERVICESTATETYPE$` available through runtime vars. Runtime macros such as `$SERVICESTATETYPE$`
and `$SERVICESTATE$` will be processed by Icinga 2 helping on fine-granular and `$SERVICESTATE$` will be processed by Icinga 2 helping on fine-granular
events being triggered. events being triggered.

View File

@ -1,25 +1,30 @@
## <a id="macros"></a> Macros ## <a id="custom-attributes"></a> Custom Attributes and Runtime Macros
> **Note** > **Note**
> >
> There is a limited set of special [global constants](#global-constants) which can be re-used and > There is a limited set of special [global constants](#global-constants) which can be re-used and
> also partly overridden such as `IcingaEnableChecks`. > also partly overridden such as `IcingaEnableChecks`.
### <a id="runtime-macros"></a> Runtime Macros ### <a id="runtime-custom-attributes"></a> Using Custom Attributes at Runtime
Macros may be used in command definitions to dynamically change how the command Custom attributes may be used in command definitions to dynamically change how the command
is executed. is executed.
Additionally there are Icinga 2 features for example the `PerfDataWriter` Additionally there are Icinga 2 features for example the `PerfDataWriter`
using the available runtime macros for output formatting. using the available Custom attributes for output formatting.
> **Tip**
>
> Custom attributes are identified by the 'vars' dictionary attribute as short name.
> Accessing the different attribute keys is possible using the '.' accessor.
> **Note** > **Note**
> >
> Macros are evaluated at runtime when executing a command. These macros cannot be > Custom attributes in command definitions or performance data templates are evaluated at
> used inside the configuration objects to add references or similar unless > runtime when executing a command. These custom attributes cannot be used/accessed inside
> stated otherwise. > the configuration objects to add references or similar unless stated otherwise.
Here is an example of a command definition which uses user-defined macros: Here is an example of a command definition which uses user-defined custom attributes:
object CheckCommand "my-ping" { object CheckCommand "my-ping" {
import "plugin-check-command" import "plugin-check-command"
@ -32,35 +37,33 @@ Here is an example of a command definition which uses user-defined macros:
"-c", "$crta$,$cpl$%", "-c", "$crta$,$cpl$%",
"-p", "$packets$", "-p", "$packets$",
"-t", "$timeout$" "-t", "$timeout$"
], ]
macros = { vars.wrta = 100
wrta = 100 vars.wpl = 5
wpl = 5 vars.crta = 200
vars.cpl = 15
crta = 200 vars.packets = 5
cpl = 15 vars.timeout = 0
packets = 5
timeout = 0
}
} }
> **Note** > **Note**
> >
> If you have previously used Icinga 1.x you may already be familiar with > If you have previously used Icinga 1.x you may already be familiar with
> user and argument macros (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x macros > user and argument macros (e.g., `USER1` or `ARG1`) and custom variables
> may have arbitrary names and arguments are no longer specified in the > (e.g., `_COMMUNITY public`). Unlike in Icinga 1.x macros may have arbitrary
> `check_command` setting. > names and arguments are no longer specified in the `check_command` setting.
> Custom variables are available as custom attributes in the `vars` dictionary
> without the `_` prefix.
Macro names must be enclosed in two `$` signs, e.g. `$address$`. When using Custom attribute names used at runtime must be enclosed in two `$` signs, e.g.
the `$` sign as single character, you need to escape it with an additional dollar `$address$`. When using the `$` sign as single character, you need to escape
sign (`$$`). it with an additional dollar sign (`$$`).
### <a id="runtime-macro-evaluation-order"></a> Runtime Macro Evaluation Order ### <a id="runtime-custom-attributes-evaluation-order"></a> Runtime Custom Attributes Evaluation Order
When executing commands Icinga 2 checks the following objects in this order to look When executing commands Icinga 2 checks the following objects in this order to look
up macros: up custom attributes and their respective values:
1. User object (only for notifications) 1. User object (only for notifications)
2. Service object 2. Service object
@ -68,43 +71,90 @@ up macros:
4. Command object 4. Command object
5. Global custom attributes in the IcingaVars constant 5. Global custom attributes in the IcingaVars constant
This execution order allows you to define default values for macros in your This execution order allows you to define default values for custom attributes
command objects. The `my-ping` command shown above uses this to set default in your command objects. The `my-ping` command shown above uses this to set
values for some of the latency thresholds and timeouts. default values for some of the latency thresholds and timeouts.
When using the `my-ping` command you can override all or some of the macros When using the `my-ping` command you can override all or some of the custom
in the service definition like this: attributes in the service definition like this:
apply Service "ping" { apply Service "ping" {
check_command = "my-ping" check_command = "my-ping"
macros.packets = 10 // Overrides the default value of 5 given in the command vars.packets = 10 // Overrides the default value of 5 given in the command
assign where host.name == "my-server1" assign where host.name == "my-server1"
} }
If a macro isn't defined anywhere an empty value is used and a warning is If a custom attribute isn't defined anywhere an empty value is used and a warning is
emitted to the Icinga 2 log. emitted to the Icinga 2 log.
> **Note**
>
> Macros in capital letters (e.g. `HOSTNAME`) are reserved for use by Icinga 2
> and should not be overwritten by users.
> **Best Practice** > **Best Practice**
> >
> By convention every host should have an `address` macro. Hosts > By convention every host should have an `address` custom attribute. Hosts
> which have an IPv6 address should also have an `address6` macro. > which have an IPv6 address should also have an `address6` custom attribute.
> This may also be mandatory requirement for using legacy interfaces, user interfaces
> and addons.
#### Custom Variables as Runtime Macros ### <a id="runtime-custom-attribute-env-vars"></a> Runtime Custom Attributes as Environment Variables
Custom variables are made available as macros using an underscore and the object type TODO
in uppercase characters as additional prefix. For example `_HOST`name "_HOST<name>"
where <name> is the name of the custom variable. The `export_macros` command object attribute requires a list of macros which should
be exported as environment variables prior to executing the command.
This is useful for example for hiding sensitive information on the command line output
when passing credentials to database checks:
object CheckCommand "mysql-health" {
import "plugin-check-command",
command = PluginDir + "/check_mysql -H $address$ -d $db$",
/* default custom attribute values */
vars = {
"MYSQLUSER" = "icinga_check",
"MYSQLPASS" = "1c1ng42r0xx"
},
export_macros = [
"MYSQLUSER",
"MYSQLPASS"
]
}
### <a id="configuration-macros"></a> Configuration Macros
Icinga 2 allows you to define constants which can be used in a limited
scope. For example, constant expressions can reference a pre-defined global constant
variable and calculate a value for the service check interval.
Example:
const MyCheckInterval = 10m
...
{
check_interval = MyCheckInterval / 2.5
}
More details in the chapter [Constant Expressions](#constant-expressions).
## <a id="runtime-macros"></a> Runtime Macros
Next to custom attributes there are additional runtime macros made available by Icinga 2.
These runtime macros reflect the current object state and may change over time while
custom attributes are configured statically (but can be modified at runtime using
external commands).
### <a id="host-runtime-macros"></a> Host Runtime Macros ### <a id="host-runtime-macros"></a> Host Runtime Macros
The following host macros are available in all commands that are executed for TODO
The following host custom attributes are available in all commands that are executed for
hosts or services: hosts or services:
Name | Description Name | Description
@ -132,15 +182,14 @@ hosts or services:
> **Note** > **Note**
> >
> `HOSTADDRESS` and `HOSTADDRESS6` macros are available as legacy macros. The > `HOSTADDRESS` and `HOSTADDRESS6` macros are available as legacy vars. The
> Icinga 2 Template Library (`ITL`) examples use the `$address$` macro instead > Icinga 2 Template Library (`ITL`) examples use the `$address$` macro instead
> requiring that macro key to be defined. > requiring that macro key to be defined.
Custom variables are made available as macros with the name "_HOST<name>"
where <name> is the name of the custom variable.
### <a id="service-runtime-macros"></a> Service Runtime Macros ### <a id="service-runtime-macros"></a> Service Runtime Macros
TODO
The following service macros are available in all commands that are executed for The following service macros are available in all commands that are executed for
services: services:
@ -170,12 +219,13 @@ services:
TOTALHOSTSERVICESUNKNOWN | Number of services associated with the host which are in an `UNKNOWN` state. TOTALHOSTSERVICESUNKNOWN | Number of services associated with the host which are in an `UNKNOWN` state.
TOTALHOSTSERVICESCRITICAL | Number of services associated with the host which are in a `CRITICAL` state. TOTALHOSTSERVICESCRITICAL | Number of services associated with the host which are in a `CRITICAL` state.
Custom variables are made available as macros with the name "_SERVICE<name>"
where <name> is the name of the custom variable.
### <a id="user-runtime-macros"></a> User Runtime Macros ### <a id="user-runtime-macros"></a> User Runtime Macros
The following macros are available in all commands that are executed for TODO
The following custom attributes are available in all commands that are executed for
users: users:
Name | Description Name | Description
@ -185,8 +235,6 @@ users:
USEREMAIL | This is an alias for the `email` macro. USEREMAIL | This is an alias for the `email` macro.
USERPAGER | This is an alias for the `pager` macro. USERPAGER | This is an alias for the `pager` macro.
Custom variables are made available as macros with the name "_USER<name>" and
"_CONTACT<name>" where <name> is the name of the custom variable. "_CONTACT<name>"
### <a id="notification-runtime-macros"></a> Notification Runtime Macros ### <a id="notification-runtime-macros"></a> Notification Runtime Macros
@ -196,6 +244,8 @@ where <name> is the name of the custom variable.
### <a id="global-runtime-macros"></a> Global Runtime Macros ### <a id="global-runtime-macros"></a> Global Runtime Macros
TODO
The following macros are available in all executed commands: The following macros are available in all executed commands:
Name | Description Name | Description
@ -206,45 +256,5 @@ The following macros are available in all executed commands:
DATE | Current date. Example: `2014-01-03` DATE | Current date. Example: `2014-01-03`
TIME | Current time including timezone information. Example: `11:23:08 +0000` TIME | Current time including timezone information. Example: `11:23:08 +0000`
### <a id="runtime-macros-env-vars"></a> Runtime Macros as Environment Variables
The `export_macros` command object attribute requires a list of macros which should
be exported as environment variables prior to executing the command.
This is useful for example for hiding sensitive information on the command line output
when passing credentials to database checks:
object CheckCommand "mysql-health" {
import "plugin-check-command",
command = PluginDir + "/check_mysql -H $address$ -d $db$",
/* default macro values */
macros = {
"MYSQLUSER" = "icinga_check",
"MYSQLPASS" = "1c1ng42r0xx"
},
export_macros = [
"MYSQLUSER",
"MYSQLPASS"
]
}
### <a id="configuration-macros"></a> Configuration Macros
Icinga 2 allows you to define constants which can be used in a limited
scope. For example, constant expressions can reference a pre-defined global constant
variable and calculate a value for the service check interval.
Example:
const MyCheckInterval = 10m
...
{
check_interval = MyCheckInterval / 2.5
}
More details in the chapter [Constant Expressions](#constant-expressions).

View File

@ -5,7 +5,7 @@ There are many ways of getting a notification to the actual receiver - Email, XM
IRC, Twitter, etc. The default method for executing a notification command are IRC, Twitter, etc. The default method for executing a notification command are
plugin scripts used for notifications. plugin scripts used for notifications.
These may either be shell commands to invoke a system call to the `mail` binary These may either be shell commands to invoke a system call to the `mail` binary
or your own script fetching available macro values and doing proper formatting or your own script fetching available custom attribute values and doing proper formatting
before sending the notification. before sending the notification.
Other mechanism will require writing the notification string into an api processing Other mechanism will require writing the notification string into an api processing
it there (for example ticket system integration). it there (for example ticket system integration).
@ -15,9 +15,10 @@ example on the [MonitoringExchange](http://www.monitoringexchange.org) or the
[Icinga Wiki](https://wiki.icinga.org). Or you'll write your own and share it. [Icinga Wiki](https://wiki.icinga.org). Or you'll write your own and share it.
A notification requires one or more users (and/or user groups) who will be notified A notification requires one or more users (and/or user groups) who will be notified
in case. These users must have all macro attributes defined which will be used in in case. These users must have all custom attributes defined which will be used in
the `NotificationCommand` on execution, for example `email` as macro dictionary key the `NotificationCommand` on execution.
is referenced as `$USEREMAIL$`.
TODO
The user `icingaadmin` in the example below will get notified only on `WARNING` and The user `icingaadmin` in the example below will get notified only on `WARNING` and
`CRITICAL` states and `problem` and `recovery` notification types. `CRITICAL` states and `problem` and `recovery` notification types.
@ -30,9 +31,8 @@ The user `icingaadmin` in the example below will get notified only on `WARNING`
StateFilterCritical) StateFilterCritical)
notification_type_filter = (NotificationFilterProblem | notification_type_filter = (NotificationFilterProblem |
NotificationFilterRecovery) NotificationFilterRecovery)
macros = { vars.email = "icinga@localhost"
"email" = "icinga@localhost" vars.pager = "+49123456789"
"pager" = "+49123456789"
} }
} }
@ -49,14 +49,14 @@ your environment.
> **Note** > **Note**
> >
> The chain of attribute inheritance including the (additive) macro dictionary for > The chain of attribute inheritance including the (additive) vars dictionary for
> notifications will allow granular macros for every specific use case, such as > notifications will allow granular custom attributes for every specific use case.
> `$mail$` or `$mobile$` as `User` macros available in `NotificationCommand`.
Service -> Notification -> Command -> User
There are various macros available at runtime execution of the `NotificationCommand`. There are various custom attributes available at runtime execution of the
The example below may or may not fit your needs. `NotificationCommand`. The example below may or may not fit your needs.
TODO
object NotificationCommand "mail-service-notification" { object NotificationCommand "mail-service-notification" {
import "plugin-notification-command" import "plugin-notification-command"
@ -88,6 +88,8 @@ You can add all shared attributes to a `Notification` template which is inherite
to the defined notifications. That way you'll save duplicated attributes in each to the defined notifications. That way you'll save duplicated attributes in each
`Notification` object. Attributes can be overridden locally. `Notification` object. Attributes can be overridden locally.
TODO
template Notification "generic-notification" { template Notification "generic-notification" {
notification_interval = 15m notification_interval = 15m
@ -154,16 +156,14 @@ notifications between start and end time.
display_name = "Icinga 2nd Level" display_name = "Icinga 2nd Level"
enable_notifications = true enable_notifications = true
macros = { vars.mobile = "+49123456781"
"mobile" = "+49123456781"
}
} }
object User "icinga-oncall-1st-level" { object User "icinga-oncall-1st-level" {
display_name = "Icinga 1st Level" display_name = "Icinga 1st Level"
enable_notifications = true enable_notifications = true
macros.mobile = "+49123456782" vars.mobile = "+49123456782"
} }
} }

View File

@ -17,13 +17,13 @@ configuration:
apply Service "ping4" { apply Service "ping4" {
import "generic-service" import "generic-service"
check_command = "ping4" check_command = "ping4"
assign where host.macros.address assign where host.vars.address
} }
apply Service "ping6" { apply Service "ping6" {
import "generic-service" import "generic-service"
check_command = "ping6" check_command = "ping6"
assign where host.macros.address6 assign where host.vars.address6
} }
In this example both `ping4` and `ping6` services inherit properties from the In this example both `ping4` and `ping6` services inherit properties from the

View File

@ -17,12 +17,12 @@ Then add your hosts to this hostgroup
object Host "mssql-srv1" { object Host "mssql-srv1" {
groups = [ "windows" ] groups = [ "windows" ]
macros.mssql_port = 1433 vars.mssql_port = 1433
} }
object Host "mssql-srv2" { object Host "mssql-srv2" {
groups = [ "windows" ] groups = [ "windows" ]
macros.mssql_port = 1433 vars.mssql_port = 1433
} }
} }
@ -34,7 +34,7 @@ Then add your hosts to this hostgroup
template Host "windows-mssql-template" { template Host "windows-mssql-template" {
groups = [ "windows" ] groups = [ "windows" ]
macros.mssql_port = 1433 vars.mssql_port = 1433
} }
} }
@ -60,13 +60,13 @@ the user groups are associated as attributes in `Notification` objects.
object User "win-mssql-noc" { object User "win-mssql-noc" {
import "generic-windows-mssql-users" import "generic-windows-mssql-users"
macros.email = "noc@example.com" vars.email = "noc@example.com"
} }
object User "win-mssql-ops" { object User "win-mssql-ops" {
import "generic-windows-mssql-users" import "generic-windows-mssql-users"
macros.email = "ops@example.com" vars.email = "ops@example.com"
} }
apply Service "ping4" { apply Service "ping4" {

View File

@ -1,9 +1,9 @@
## <a id="performance-data"></a> Performance Data ## <a id="performance-data"></a> Performance Data
When a service check is executed plugins should provide so-called When a host and service check is executed plugins should provide so-called
`performance data`. Next to that additional check performance data `performance data`. Next to that additional check performance data
can be fetched using Icinga 2 runtime macros such as the check latency can be fetched using Icinga 2 runtime macros such as the check latency
or the current service state. or the current service state (or additional custom attributes).
The performance data may be passed to external applications which The performance data may be passed to external applications which
then generate nice graphs for historical reporting and trending. then generate nice graphs for historical reporting and trending.
@ -23,7 +23,7 @@ the current performance files for their backend updates.
Therefore the Icinga 2 `PerfdataWriter` object allows you to define Therefore the Icinga 2 `PerfdataWriter` object allows you to define
the output template format for host and services backed with Icinga 2 the output template format for host and services backed with Icinga 2
runtime macros. runtime vars.
host_format_template = "DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$" host_format_template = "DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$"
service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$" service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$"

View File

@ -22,17 +22,17 @@ the `check_snmp` plugin binary, but there are plenty of [existing plugins](#inte
for specific use cases already around, for example monitoring Cisco routers. for specific use cases already around, for example monitoring Cisco routers.
The following example uses the [SNMP ITL](#itl-snmp) `CheckCommand` and just The following example uses the [SNMP ITL](#itl-snmp) `CheckCommand` and just
overrides the `oid` macro. A service is created for all hosts which overrides the `oid` custom attribute. A service is created for all hosts which
have the `community` macro set. have the `community` custom attribute set.
apply Service "uptime" { apply Service "uptime" {
import "generic-service" import "generic-service"
templates = [ "generic-service" ] templates = [ "generic-service" ]
check_command = "snmp" check_command = "snmp"
macros.oid = "1.3.6.1.2.1.1.3.0" vars.oid = "1.3.6.1.2.1.1.3.0"
assign where host.macros.community assign where host.vars.community
} }
#### SSH #### SSH
@ -53,7 +53,7 @@ its return code and output. `check_by_ssh` is available in the [Monitoring Plugi
apply Service "swap" { apply Service "swap" {
import "generic-service" import "generic-service"
check_command = "check_by_ssh_swap" check_command = "check_by_ssh_swap"
macros = { vars = {
"warn" = "50%" "warn" = "50%"
"crit" = "75%" "crit" = "75%"
} }
@ -89,7 +89,7 @@ Example:
import "generic-service" import "generic-service"
check_command = "check_nrpe" check_command = "check_nrpe"
macros.remote_nrpe_command = "check_users" vars.remote_nrpe_command = "check_users"
assign where host.name == "remote-nrpe-host" assign where host.name == "remote-nrpe-host"
} }
@ -126,7 +126,7 @@ Example:
"-s", "$pass$" "-s", "$pass$"
] ]
macros = { vars = {
"port" = "12489" "port" = "12489"
"pass" = "supersecret" "pass" = "supersecret"
} }
@ -137,7 +137,7 @@ Example:
check_command = "check_nscp" check_command = "check_nscp"
macros += { vars += {
remote_nscp_command = "USEDDISKSPACE" remote_nscp_command = "USEDDISKSPACE"
partition = "c" partition = "c"
warn = "70" warn = "70"

View File

@ -8,7 +8,7 @@ objects using the `object` keyword:
object Host "host1.example.org" { object Host "host1.example.org" {
display_name = "host1" display_name = "host1"
macros = { vars = {
address = "192.168.0.1" address = "192.168.0.1"
address6 = "::1" address6 = "::1"
} }
@ -24,7 +24,7 @@ them with a semi-colon:
object Host "host1.example.org" { object Host "host1.example.org" {
display_name = "host1" display_name = "host1"
macros = { address = "192.168.0.1"; address6 = "::1"; } vars = { address = "192.168.0.1"; address6 = "::1"; }
} }
The semi-colon after the last element (i.e. `address6`) may be omitted. The semi-colon after the last element (i.e. `address6`) may be omitted.
@ -333,20 +333,20 @@ Objects can import attributes from other objects.
Example: Example:
template Host "default-host" { template Host "default-host" {
macros.color = "red" vars.color = "red"
} }
template Host "test-host" { template Host "test-host" {
import "default-host" import "default-host"
macros.color = "blue" vars.color = "blue"
} }
object Host "localhost" { object Host "localhost" {
import "test-host" import "test-host"
macros.address = "127.0.0.1" vars.address = "127.0.0.1"
macros.address6 = "::1" vars.address6 = "::1"
} }
The `default-host` and `test-host` objects are marked as templates The `default-host` and `test-host` objects are marked as templates
@ -356,8 +356,8 @@ templates, however in general they are.
> **Note** > **Note**
> >
> The macros dictionary for the `localhost` object contains all three > The `vars` dictionary for the `localhost` object contains all three
> macros and the macro `color` has the value `"blue"`. > custom attributes and the custom attribute `color` has the value `"blue"`.
Parent objects are resolved in the order they're specified using the Parent objects are resolved in the order they're specified using the
`import` keyword. `import` keyword.
@ -401,8 +401,8 @@ ScheduledDowntime| Service | host, service
> **Note** > **Note**
> >
> Any valid config attribute can be accessed using the `host` and `service` > Any valid config attribute can be accessed using the `host` and `service`
> variables. For example, `host.macros.address` would return the host's > variables. For example, `host.vars.address` would return the host's
> "address" macro - or null if it doesn't have that macro. > "address" custom attribute - or null if it doesn't have that custom attribute.
### <a id="boolean-values"></a> Boolean Values ### <a id="boolean-values"></a> Boolean Values

View File

@ -27,7 +27,7 @@ Attributes:
display_name |**Optional.** A short description of the host. display_name |**Optional.** A short description of the host.
check |**Optional.** A service that is used to determine whether the host is up or down. This must be a service short name of a service that belongs to the host. check |**Optional.** A service that is used to determine whether the host is up or down. This must be a service short name of a service that belongs to the host.
groups |**Optional.** A list of host groups this host belongs to. groups |**Optional.** A list of host groups this host belongs to.
macros |**Optional.** A dictionary containing macros that are specific to this host. vars |**Optional.** A dictionary containing custom attributes that are specific to this host.
### <a id="objecttype-hostgroup"></a> HostGroup ### <a id="objecttype-hostgroup"></a> HostGroup
@ -66,7 +66,7 @@ Example:
check_command = "check_snmp" check_command = "check_snmp"
macros = { vars = {
community = "public" community = "public"
oid = "DISMAN-EVENT-MIB::sysUpTimeInstance" oid = "DISMAN-EVENT-MIB::sysUpTimeInstance"
} }
@ -84,7 +84,7 @@ Attributes:
host |**Required.** The host this service belongs to. There must be a `Host` object with that name. host |**Required.** The host this service belongs to. There must be a `Host` object with that name.
short_name |**Required.** The service name. Must be unique on a per-host basis (Similar to the service_description attribute in Icinga 1.x). short_name |**Required.** The service name. Must be unique on a per-host basis (Similar to the service_description attribute in Icinga 1.x).
display_name |**Optional.** A short description of the service. display_name |**Optional.** A short description of the service.
macros |**Optional.** A dictionary containing macros that are specific to this host. vars |**Optional.** A dictionary containing custom attributes that are specific to this host.
check\_command |**Required.** The name of the check command. check\_command |**Required.** The name of the check command.
max\_check\_attempts|**Optional.** The number of times a service is re-checked before changing into a hard state. Defaults to 3. max\_check\_attempts|**Optional.** The number of times a service is re-checked before changing into a hard state. Defaults to 3.
check\_period |**Optional.** The name of a time period which determines when this service should be checked. Not set by default. check\_period |**Optional.** The name of a time period which determines when this service should be checked. Not set by default.
@ -147,7 +147,7 @@ Attributes:
----------------|---------------- ----------------|----------------
host |**Required.** The name of the host this notification belongs to. host |**Required.** The name of the host this notification belongs to.
service |**Required.** The short name of the service this notification belongs to. service |**Required.** The short name of the service this notification belongs to.
macros |**Optional.** A dictionary containing macros that are specific to this notification object. vars |**Optional.** A dictionary containing custom attributes that are specific to this notification object.
users |**Optional.** A list of user names who should be notified. users |**Optional.** A list of user names who should be notified.
user_groups |**Optional.** A list of user group names who should be notified. user_groups |**Optional.** A list of user group names who should be notified.
times |**Optional.** A dictionary containing `begin` and `end` attributes for the notification. times |**Optional.** A dictionary containing `begin` and `end` attributes for the notification.
@ -242,7 +242,7 @@ Example:
notification_type_filter = (NotificationFilterProblem | notification_type_filter = (NotificationFilterProblem |
NotificationFilterRecovery) NotificationFilterRecovery)
macros = { vars = {
name = "Icinga 2 Admin" name = "Icinga 2 Admin"
email = "icinga@localhost" email = "icinga@localhost"
pager = "icingaadmin@localhost.localdomain" pager = "icingaadmin@localhost.localdomain"
@ -280,8 +280,7 @@ Attributes:
Name |Description Name |Description
----------------|---------------- ----------------|----------------
display_name |**Optional.** A short description of the user. display_name |**Optional.** A short description of the user.
macros |**Optional.** A dictionary containing macros that are specific to this user. vars |**Optional.** A dictionary containing custom attributes that are specific to this user.
custom |**Optional.** A dictionary containing custom attributes that are specific to this user.
groups |**Optional.** An array of group names. groups |**Optional.** An array of group names.
enable_notifications|**Optional.** Whether notifications are enabled for this user. enable_notifications|**Optional.** Whether notifications are enabled for this user.
notification_period|**Optional.** The name of a time period which determines when this notification should be triggered. Not set by default. notification_period|**Optional.** The name of a time period which determines when this notification should be triggered. Not set by default.
@ -413,7 +412,7 @@ Attributes:
### <a id="objecttype-checkcommand"></a> CheckCommand ### <a id="objecttype-checkcommand"></a> CheckCommand
A check command definition. Additional default command macros can be A check command definition. Additional default command custom attributes can be
defined here. defined here.
Example: Example:
@ -428,7 +427,7 @@ Example:
"-o", "$oid$" "-o", "$oid$"
] ]
macros = { vars = {
address = "127.0.0.1" address = "127.0.0.1"
community = "public" community = "public"
} }
@ -442,7 +441,7 @@ Attributes:
command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command.
export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command. export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command.
escape_macros |**Optional.** A list of macros which should be shell-escaped in the command. escape_macros |**Optional.** A list of macros which should be shell-escaped in the command.
macros |**Optional.** A dictionary containing macros that are specific to this command. vars |**Optional.** A dictionary containing custom attributes that are specific to this command.
timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes. timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes.
### <a id="objecttype-notificationcommand"></a> NotificationCommand ### <a id="objecttype-notificationcommand"></a> NotificationCommand
@ -482,7 +481,7 @@ Attributes:
command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command.
export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command. export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command.
escape_macros |**Optional.** A list of macros which should be shell-escaped in the command. escape_macros |**Optional.** A list of macros which should be shell-escaped in the command.
macros |**Optional.** A dictionary containing macros that are specific to this command. vars |**Optional.** A dictionary containing custom attributes that are specific to this command.
timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes. timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes.
### <a id="objecttype-eventcommand"></a> EventCommand ### <a id="objecttype-eventcommand"></a> EventCommand
@ -510,7 +509,7 @@ Attributes:
command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. command |**Required.** The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command.
export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command. export_macros |**Optional.** A list of macros which should be exported as environment variables prior to executing the command.
escape_macros |**Optional.** A list of macros which should be shell-escaped in the command. escape_macros |**Optional.** A list of macros which should be shell-escaped in the command.
macros |**Optional.** A dictionary containing macros that are specific to this command. vars |**Optional.** A dictionary containing custom attributes that are specific to this command.
timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes. timeout |**Optional.** The command timeout in seconds. Defaults to 5 minutes.
### <a id="objecttype-perfdatawriter"></a> PerfdataWriter ### <a id="objecttype-perfdatawriter"></a> PerfdataWriter

View File

@ -249,4 +249,4 @@ community | **Optional.** The SNMP community. Defaults to "public".
Check command for the built-in `icinga` check. This check returns performance Check command for the built-in `icinga` check. This check returns performance
data for the current Icinga instance. data for the current Icinga instance.
The `icinga` check command does not support any macros. The `icinga` check command does not support any vars.

View File

@ -21,11 +21,11 @@ further checks for the `ping4` service on host `google-dns` service should
be suppressed. This is achieved by setting the `disable_checks` attribute to `true`. be suppressed. This is achieved by setting the `disable_checks` attribute to `true`.
object Host "dsl-router" { object Host "dsl-router" {
macros.address = "192.168.1.1" vars.address = "192.168.1.1"
} }
object Host "google-dns" { object Host "google-dns" {
macros.address = "8.8.8.8" vars.address = "8.8.8.8"
} }
apply Service "ping4" { apply Service "ping4" {
@ -33,7 +33,7 @@ be suppressed. This is achieved by setting the `disable_checks` attribute to `tr
check_command = "ping4" check_command = "ping4"
assign where host.macros.address assign where host.vars.address
} }
apply Dependency "internet" { apply Dependency "internet" {

View File

@ -170,6 +170,8 @@ account by Icinga 1.x Classic UI and Web.
## <a id="differences-1x-2-custom-attributes"></a> Custom Attributes ## <a id="differences-1x-2-custom-attributes"></a> Custom Attributes
Icinga 2 allows you to define custom attributes in the `vars` dictionary.
### <a id="differences-1x-2-action-url-notes-url-notes"></a> Action Url, Notes Url, Notes ### <a id="differences-1x-2-action-url-notes-url-notes"></a> Action Url, Notes Url, Notes
Icinga 1.x objects support configuration attributes not required as runtime Icinga 1.x objects support configuration attributes not required as runtime
@ -178,10 +180,10 @@ The `notes`, `notes_url`, `action_url`, `icon_image`, `icon_image_alt`
attributes for host and service objects, additionally `statusmap_image` and attributes for host and service objects, additionally `statusmap_image` and
`2d_coords` for the host's representation in status maps. `2d_coords` for the host's representation in status maps.
These attributes can be set using the `custom` dictionary in Icinga 2 `Host` These attributes can be set using the `vars` dictionary in Icinga 2 `Host`
or `Service` objects: or `Service` objects:
custom = { vars = {
notes = "Icinga 2 is the best!" notes = "Icinga 2 is the best!"
notes_url = "http://docs.icinga.org" notes_url = "http://docs.icinga.org"
action_url = "http://dev.icinga.org" action_url = "http://dev.icinga.org"
@ -196,13 +198,15 @@ External interfaces will recognize and display these attributes accordingly.
### <a id="differences-1x-2-custom-variables"></a> Custom Variables ### <a id="differences-1x-2-custom-variables"></a> Custom Variables
Icinga 1.x custom variable attributes must be prefixed using an underscore (`_`). Icinga 1.x custom variable attributes must be prefixed using an underscore (`_`).
In Icinga 2 these attributes must be added to the `custom`dictionary. In Icinga 2 these attributes must be added to the `vars` dictionary as custom attributes.
custom = { vars = {
DN = "cn=icinga2-dev-host,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org" DN = "cn=icinga2-dev-host,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org"
CV = "my custom cmdb description" CV = "my custom cmdb description"
} }
TODO
> **Note** > **Note**
> >
> If you are planning to access custom variables as runtime macros you may access > If you are planning to access custom variables as runtime macros you may access
@ -222,7 +226,7 @@ using the `apply` keyword.
## <a id="differences-1x-2-users"></a> Users ## <a id="differences-1x-2-users"></a> Users
Contacts have been renamed to Users (same for groups). A user does not Contacts have been renamed to Users (same for groups). A user does not
only provide attributes and macros used for notifications, but is also only provide attributes and custom attributes used for notifications, but is also
used for authorization checks. used for authorization checks.
In Icinga 2 notification commands are not directly associated with users. In Icinga 2 notification commands are not directly associated with users.
@ -235,32 +239,19 @@ and their users.
## <a id="differences-1x-2-macros"></a> Macros ## <a id="differences-1x-2-macros"></a> Macros
TODO
Various object attributes and runtime variables can be accessed as macros in Various object attributes and runtime variables can be accessed as macros in
commands in Icinga 1.x - Icinga 2 supports all required [macros](#macros). commands in Icinga 1.x - Icinga 2 supports all required [custom attributes](#custom-attributes).
> **Note** ### <a id="differences-1x-2-command-arguments"></a> Command Arguments
>
> Due to the `contact`objects renamed to `user` objects the associated macros
> have changed.
> Furthermore an `alias` is now reflected as `display_name`. The Icinga 1.x
> notation is still supported for compatibility reasons.
Icinga 1.x Name | Icinga 2 Name
-----------------------|--------------
CONTACTNAME | USERNAME
CONTACTALIAS | USERDISPLAYNAME
CONTACTEMAIL | USEREMAIL
CONTACTPAGER | USERPAGER
### <a id="differences-1x-2-command-macros"></a> Command Macros
If you have previously used Icinga 1.x you may already be familiar with If you have previously used Icinga 1.x you may already be familiar with
user and argument macros (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x macros user and argument definitions (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x
may have arbitrary names and arguments are no longer specified in the the Icinga 2 custom attributes may have arbitrary names and arguments are no
`check_command` setting. longer specified in the `check_command` setting.
In Icinga 1.x argument macros are specified in the `check_command` attribute and In Icinga 1.x arguments are specified in the `check_command` attribute and
are separated from the command name using an exclamation mark (`!`). are separated from the command name using an exclamation mark (`!`).
define command { define command {
@ -275,7 +266,7 @@ are separated from the command name using an exclamation mark (`!`).
check_command ping4!100.0,20%!500.0,60% check_command ping4!100.0,20%!500.0,60%
} }
With the freely definable macros in Icinga 2 it looks like this: With the freely definable custom attributes in Icinga 2 it looks like this:
object CheckCommand "ping4" { object CheckCommand "ping4" {
command = PluginDir + "/check_ping -H $HOSTADDRESS$ -w $wrta$,$wpl%$ -c $crta$,$cpl%$" command = PluginDir + "/check_ping -H $HOSTADDRESS$ -w $wrta$,$wpl%$ -c $crta$,$cpl%$"
@ -283,22 +274,22 @@ With the freely definable macros in Icinga 2 it looks like this:
object Service "PING" { object Service "PING" {
check_command = "ping4" check_command = "ping4"
macros = { vars.wrta = 100
wrta = 100 vars.wpl = 20
wpl = 20 vars.crta = 500
crta = 500 vars.cpl = 60
cpl = 60
}
} }
> **Note** > **Note**
> >
> Tip: The above example uses the global `PluginDir` constant instead of the Icinga 1.x > Tip: The above example uses the global `PluginDir` constant instead of the Icinga 1.x
> $USER1$ macro. It also replaces the Icinga 1.x notation with $ARGn$ with freely > $USER1$ macro. It also replaces the Icinga 1.x notation with $ARGn$ with freely
> definable macros. > definable custom attributes.
### <a id="differences-1x-2-environment-macros"></a> Environment Macros ### <a id="differences-1x-2-environment-macros"></a> Environment Macros
TODO
The global configuration setting `enable_environment_macros` does not exist in The global configuration setting `enable_environment_macros` does not exist in
Icinga 2. Icinga 2.
@ -307,12 +298,6 @@ attribute in command objects.
## <a id="differences-1x-2-checks"></a> Checks ## <a id="differences-1x-2-checks"></a> Checks
### <a id="differences-1x-2-host-check"></a> Host Check
Unlike in Icinga 1.x hosts are not checkable objects in Icinga 2. Instead hosts
inherit their state from the service that is specified using the `check`
attribute.
### <a id="differences-1x-2-check-output"></a> Check Output ### <a id="differences-1x-2-check-output"></a> Check Output
Icinga 2 does not make a difference between `output` (first line) and Icinga 2 does not make a difference between `output` (first line) and
@ -337,7 +322,7 @@ Unlike in Icinga 1.x there are 3 different command types in Icinga 2:
For example in Icinga 1.x it is possible to accidently use a notification For example in Icinga 1.x it is possible to accidently use a notification
command as an event handler which might cause problems depending on which command as an event handler which might cause problems depending on which
macros are used in the notification command. runtime macros are used in the notification command.
In Icinga 2 these command types are separated and will generate an error on In Icinga 2 these command types are separated and will generate an error on
configuration validation if used in the wrong context. configuration validation if used in the wrong context.
@ -346,7 +331,7 @@ While Icinga 2 still supports the complete command line in command objects, it's
also possible to encapsulate all arguments into double quotes and passing them also possible to encapsulate all arguments into double quotes and passing them
as array to the `command_line` attribute i.e. for better readability. as array to the `command_line` attribute i.e. for better readability.
It's also possible to define default macros for the command itself which can be It's also possible to define default custom attributes for the command itself which can be
overridden by a service macro. overridden by a service macro.
## <a id="differences-1x-2-groups"></a> Groups ## <a id="differences-1x-2-groups"></a> Groups
@ -452,6 +437,8 @@ object for the escalation itself.
### <a id="differences-1x-2-notification-options"></a> Notification Options ### <a id="differences-1x-2-notification-options"></a> Notification Options
TODO
Unlike Icinga 1.x with the 'notification_options' attribute with comma-separated Unlike Icinga 1.x with the 'notification_options' attribute with comma-separated
state and type filters, Icinga 2 uses two configuration attributes for that. state and type filters, Icinga 2 uses two configuration attributes for that.
All state and type filter use long names or'd with a pipe together All state and type filter use long names or'd with a pipe together

View File

@ -30,13 +30,11 @@ object CheckCommand "ping4" {
"-t", "$timeout$" "-t", "$timeout$"
], ],
vars.wrta = 100, vars.wrta = 100
vars.wpl = 5, vars.wpl = 5
vars.crta = 200
vars.crta = 200, vars.cpl = 15
vars.cpl = 15, vars.packets = 5
vars.packets = 5,
vars.timeout = 0 vars.timeout = 0
} }