## What is Icinga 2?
-Icinga 2 is a network monitoring application.
+Icinga 2 is an enterprise-grade open source monitoring system which keeps watch over networks and any conceivable network resource, notifies the user of errors and recoveries and generates performance data for reporting. Scalable and extensible, Icinga can monitor complex, large environments across dispersed locations.
## Licensing
Icinga 2 is split up into several packages:
You can install Icinga 2 by using your distribution's package manager
-to install the *icinga2* package. Some parts of Icinga 2's functionality
+to install the `icinga2` package. Some parts of Icinga 2's functionality
are available as separate packages:
Name | Description
In case you're running a distribution for which Icinga 2 packages are
not yet available you will have to use the release tarball which you
can download from the [Icinga website](https://www.icinga.org/). The
-release tarballs contain an *INSTALL* file with further instructions.
+release tarballs contain an `INSTALL` file with further instructions.
### Installation Paths
### icinga2.conf
-An example configuration file is installed for you in */etc/icinga2/icinga2.conf*.
+An example configuration file is installed for you in `/etc/icinga2/icinga2.conf`.
Here's a brief description of the example config:
include <itl/itl.conf>
-The *include* directive can be used to include other files. The *itl/itl.conf*
+The `include` directive can be used to include other files. The `itl/itl.conf`
file is distributed as part of Icinga 2 and provides a number of useful templates
and constants you can use to configure your services.
include "features-enabled/*.conf"
This include directive takes care of including the configuration files for all
-the features which have been enabled with *i2enfeature*. See
+the features which have been enabled with `i2enfeature`. See
[Enabling/Disabling Features](#features) for more details.
/**
*/
include "conf.d/*.conf"
-You can put your own configuration files in the *conf.d* directory. This
+You can put your own configuration files in the `conf.d` directory. This
directive makes sure that all of your own configuration files are included.
### macros.conf
-The *conf.d/macros.conf* file can be used to define global macros:
+The `conf.d/macros.conf` file can be used to define global macros:
/**
* Global macros
### localhost.conf
-The *conf.d/localhost.conf* file contains our first host definition:
+The `conf.d/localhost.conf` file contains our first host definition:
/**
* A host definition. You can create your own configuration files
This defines a host named "localhost" which has a couple of services. Services
may inherit from one or more service templates.
-The templates *ping4*, *ping6*, *http_ip*, *ssh*, *load*, *processes*, *users*
-and *disk* are all provided by the Icinga Template Library (short ITL) which
-we enabled earlier by including the itl/itl.conf configuration file.
+The command objects `ping4`, `ping6`, `http_ip`, `ssh`, `load`, `processes`, `users`
+and `disk` are all provided by the Icinga Template Library (short ITL) which
+we enabled earlier by including the `itl/itl.conf` configuration file.
-The *macros* attribute can be used to define macros that are available for all
+The `macros` attribute can be used to define macros that are available for all
services which belong to this host. Most of the templates in the Icinga Template
-Library require an *address* macro.
+Library require an `address` macro.
## Setting up Icinga Classic UI
-Icinga 2 can write *status.dat* and *objects.cache* files in the format that
+Icinga 2 can write `status.dat` and `objects.cache` files in the format that
is supported by the Icinga 1.x Classic UI. External commands (a.k.a. the
"command pipe") are also supported. It also supports writing Icinga 1.x
log files which are required for the reporting functionality in the Classic UI.
-These features are implemented as part of the *compat* library and are enabled
-by default in the example configuration file.
-
-You should be able to find the *status.dat* and *objects.cache* files in
-*/var/cache/icinga2*. The log files can be found in */var/log/icinga2/compat*.
-The command pipe can be found in */var/run/icinga2*.
-
### Installing Icinga Classic UI
You can install Icinga 1.x Classic UI in standalone mode using the
### Configuring Icinga 2
-By default Icinga 2 does not write *status.dat* and *objects.cache* files which are used
+By default Icinga 2 does not write `status.dat` and `objects.cache` files which are used
by the Classic UI. The command pipe is also not enabled by default.
You can use i2enfeature to enable these features:
# /etc/init.d/icinga2 restart
+You should be able to find the `status.dat` and `objects.cache` files in
+`/var/cache/icinga2`. The log files can be found in `/var/log/icinga2/compat`.
+The command pipe can be found in `/var/run/icinga2/cmd/icinga2.cmd`.
+
### Configuring the Classic UI
After installing the Classic UI you will need to update the following
-settings in your *cgi.cfg* configuration file in the *STANDALONE (ICINGA 2)
-OPTIONS* section:
+settings in your `cgi.cfg` configuration file in the `STANDALONE (ICINGA 2)
+OPTIONS` section:
Configuration Setting |Value
------------------------------------|------------------------------------
> might be different.
In order for commands to work you will need to add your web server user to
-the *icingacmd* group:
+the `icingacmd` group:
# usermod -a -G icingacmd www-data
> **Note**
>
-> Change "www-data" to the user name your web server is running as.
+> Change `www-data` to the user name your web server is running as.
Verify that your Icinga 1.x Classic UI works by browsing to your Classic
UI installation URL, e.g.
On its own Icinga 2 does not know how to check external services. The
[Nagios Plugins Project](https://www.nagios-plugins.org/) provides an extensive
-set of *plugins* which can be used by Icinga 2 to check whether services are
+set of plugins which can be used by Icinga 2 to check whether services are
working properly.
The recommended way of installing these standard plugins is to use your
OS X (MacPorts) | nagios-plugins | /opt/local/libexec
Depending on which directory your plugins are installed into you may need to
-update the *plugindir* macro in your Icinga 2 configuration. This macro is used
+update the `plugindir` macro in your Icinga 2 configuration. This macro is used
by the service templates contained in the Icinga Template Library to determine
where to find the plugin binaries.
\ No newline at end of file
### Installing the IDO module
-Once you've set up your database you have to install the *icinga2-ido-mysql*
+Once you've set up your database you have to install the `icinga2-ido-mysql`
package using your distribution's package manager.
The package provides a new configuration file that is installed in
-*/etc/icinga2/features-available/ido-mysql.conf*. You will need to update the
+`/etc/icinga2/features-available/ido-mysql.conf`. You will need to update the
database credentials in this file.
-You can enable the ido-mysql feature configuration file using *i2enfeature*:
+You can enable the ido-mysql feature configuration file using `i2enfeature`:
# i2enfeature ido-mysql
Module 'ido-mysql' was enabled.
# /etc/init.d/icinga2 restart
-By default the Livestatus socket is available in */var/run/icinga2/cmd/livestatus*.
+By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
In order for queries and commands to work you will need to add your query user
-(e.g. your web server) to the *icingacmd* group:
+(e.g. your web server) to the `icingacmd` group:
# usermod -a -G icingacmd www-data
### Init Script
-Icinga 2's init script is installed in */etc/init.d/icinga2* by default:
+Icinga 2's init script is installed in `/etc/init.d/icinga2` by default:
# /etc/init.d/icinga2
Usage: /etc/init.d/icinga2 {start|stop|restart|reload|checkconfig|status}
Command | Description
--------------------|------------------------
- start | The *start* action starts the Icinga 2 daemon.
- stop | The *stop* action stops the Icinga 2 daemon.
- restart | The *restart* action is a shortcut for running the *stop* action followed by *start*.
- reload | The *reload* action sends the HUP signal to Icinga 2 which causes it to restart. Unlike the *restart* action *reload* does not wait until Icinga 2 has restarted.
- checkconfig | The *checkconfig* action checks if the */etc/icinga2/icinga2.conf* configuration file contains any errors.
- status | The *status* action checks if Icinga 2 is running.
+ start | The `start` action starts the Icinga 2 daemon.
+ stop | The `stop` action stops the Icinga 2 daemon.
+ restart | The `restart` action is a shortcut for running the `stop` action followed by `start`.
+ reload | The `reload` action sends the HUP signal to Icinga 2 which causes it to restart. Unlike the `restart` action `reload` does not wait until Icinga 2 has restarted.
+ checkconfig | The `checkconfig` action checks if the `/etc/icinga2/icinga2.conf` configuration file contains any errors.
+ status | The `status` action checks if Icinga 2 is running.
### <a id="cmdline"></a> Command-line Options
#### Libraries
-Instead of loading libraries using the [*library* config directive](#library)
-you can also use the *--library* command-line option.
+Instead of loading libraries using the [`library` config directive](#library)
+you can also use the `--library` command-line option.
#### Config Include Path
include <test.conf>
This would cause Icinga 2 to search its include path for the configuration file
-*test.conf*. By default the installation path for the Icinga Template Library
+`test.conf`. By default the installation path for the Icinga Template Library
is the only search directory.
-Using the *--include* command-line option additional search directories can be
+Using the `--include` command-line option additional search directories can be
added.
#### Config Files
-Using the *--config* option you can specify one or more config files. Config
+Using the `--config` option you can specify one or more config files. Config
files are processed in the order they're specified on the command-line.
#### Config Validation
-The *--validate* option can be used to check if your configuration files
+The `--validate` option can be used to check if your configuration files
contain errors. If any errors are found the exit status is 1, otherwise 0
is returned.
### <a id="features"></a> Enabling/Disabling Features
Icinga 2 provides configuration files for some commonly used features. These
-are installed in the */etc/icinga2/features-available* directory and can be
-enabled and disabled using the *i2enfeature* and *i2disfeature* tools,
+are installed in the `/etc/icinga2/features-available` directory and can be
+enabled and disabled using the `i2enfeature` and `i2disfeature` tools,
respectively.
-The *i2enfeature* tool creates symlinks in the */etc/icinga2/features-enabled*
+The `i2enfeature` tool creates symlinks in the `/etc/icinga2/features-enabled`
directory which is included by default in the example configuration file.
You can view a list of available feature configuration files:
Available features: compat
-Using the *i2enfeature* command you can enable features:
+Using the `i2enfeature` command you can enable features:
# i2enfeature compat
Module 'compat' was enabled.
Make sure to restart Icinga 2 for these changes to take effect.
-You can disable features using the *i2disfeature* command:
+You can disable features using the `i2disfeature` command:
# i2disfeature compat
Module 'compat' was disabled.
> **Note**
>
-> The *i2enfeature* and *i2disfeature* commands do not restart Icinga 2.
\ No newline at end of file
+> The `i2enfeature` and `i2disfeature` commands do not restart Icinga 2.
\ No newline at end of file
macros["address"] = "10.0.0.1"
}
-The example host *my-server1* creates two services which belong to this host:
-*ping4* and *http*.
+The example host `my-server1` creates two services which belong to this host:
+`ping4` and `http`.
It also specifies that the host should inherit its availability state from the
-*ping4* service.
+`ping4` service.
> **Note**
>
> from one of its child services. No checks are performed for the host
> itself.
-The *address* macro is used by check commands to determine which network
+The `address` macro is used by check commands to determine which network
address is associated with the host object.
### Host States
Hosts inherit their state from the host check service that is specified using
-the *check* attribute.
+the `check` attribute.
Hosts can be in any of the following states:
### Hard and Soft States
When detecting a problem with a service Icinga re-checks the service a number of
-times (based on the *max_check_attempts* and *retry_interval* settings) before sending
+times (based on the `max_check_attempts` and `retry_interval` settings) before sending
notifications. This ensures that no unnecessary notifications are sent for
-transient failures. During this time the service is in a *SOFT* state.
+transient failures. During this time the service is in a `SOFT` state.
After all re-checks have been executed and the service is still in a non-OK
-state the service switches to a *HARD* state and notifications are sent.
+state the service switches to a `HARD` state and notifications are sent.
Name | Description
------------|--------------
> may have arbitrary names and arguments are no longer specified in the
> check_command setting.
-Macro names must be enclosed in two *$* signs, e.g. *$plugindir$*. When
+Macro names must be enclosed in two `$` signs, e.g. `$plugindir$`. When
executing commands Icinga 2 checks the following objects in this
order to look up macros:
5. Global macros in the IcingaMacros variable
This execution order allows you to define default values for macros in your
-command objects. The *my-ping* command shown above uses this to set default
+command objects. The `my-ping` command shown above uses this to set 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 macros
in the service definition like this:
object Host "my-server1" {
> Macros in capital letters (e.g. HOSTNAME) are reserved for use by Icinga 2
> and should not be overwritten by users.
-By convention every host should have an *address* macro. Hosts
-which have an IPv6 address should also have an *address6* macro.
+By convention every host should have an `address` macro. Hosts
+which have an IPv6 address should also have an `address6` macro.
-The *plugindir* macro should be set to the path of your check plugins. The
-*/etc/icinga2/conf.d/macros.conf* file is usually used to define global macros
+The `plugindir` macro should be set to the path of your check plugins. The
+`/etc/icinga2/conf.d/macros.conf` file is usually used to define global macros
including this one.
### Host Macros
-----------------------|--------------
HOSTNAME | The name of the host object.
HOSTDISPLAYNAME | The value of the display_name attribute.
- HOSTALIAS | This is an alias for the *HOSTDISPLAYNAME* macro.
+ HOSTALIAS | This is an alias for the `HOSTDISPLAYNAME` macro.
HOSTSTATE | The host's current state. Can be one of UNREACHABLE, UP and DOWN.
HOSTSTATEID | The host's current state. Can be one of 0 (up), 1 (down) and 2 (unreachable).
HOSTSTATETYPE | The host's current state type. Can be one of SOFT and HARD.
HOSTOUTPUT | The last check's output.
HOSTPERFDATA | The last check's performance data.
LASTHOSTCHECK | The timestamp when the last check was executed.
- HOSTADDRESS | This is an alias for the *address* macro. If the *address* macro is not defined the host object's name is used instead.
- HOSTADDRESS6 | This is an alias for the *address6* macro. If the *address* macro is not defined the host object's name is used instead.
+ HOSTADDRESS | This is an alias for the `address` macro. If the `address` macro is not defined the host object's name is used instead.
+ HOSTADDRESS6 | This is an alias for the `address6` macro. If the `address` macro is not defined the host object's name is used instead.
### Service Macros
-----------------------|--------------
SERVICEDESC | The short name of the service object.
SERVICEDISPLAYNAME | The value of the display_name attribute.
- SERVICECHECKCOMMAND | This is an alias for the *SERVICEDISPLAYNAME* macro.
+ SERVICECHECKCOMMAND | This is an alias for the `SERVICEDISPLAYNAME` macro.
SERVICESTATE | The service's current state. Can be one of OK, WARNING, CRITICAL, UNCHECKABLE and UNKNOWN.
SERVICESTATEID | The service's current state. Can be one of 0 (ok), 1 (warning), 2 (critical), 3 (unknown) and 4 (uncheckable).
SERVICESTATETYPE | The service's current state type. Can be one of SOFT and HARD.
-----------------------|--------------
USERNAME | The name of the user object.
USERDISPLAYNAME | The value of the display_name attribute.
- USEREMAIL | This is an alias for the *email* macro.
- USERPAGER | This is an alias for the *pager* macro.
+ USEREMAIL | This is an alias for the `email` macro.
+ USERPAGER | This is an alias for the `pager` macro.
### Global Macros
-## Groups
-
-TODO
-
-## Host/Service Dependencies
-
-TODO
-
## Notifications
TODO
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
+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
config:
macros["address"] = "10.0.0.2"
}
-In this example both *my-server1* and *my-server2* each get their own ping
+In this example both `my-server1` and `my-server2` each get their own ping
service check.
Objects as well as templates themselves can inherit from an arbitrary number of
object if necessary.
Templates can also be used in service and notification definitions using the
-*templates* attribute:
+`templates` attribute:
template Service "weekend-service" {
check_interval = 0.5m,
### Object Definition
Icinga 2 features an object-based configuration format. In order to
-define objects the *object* keyword is used:
+define objects the `object` keyword is used:
object Host "host1.example.org" {
display_name = "host1",
>
> Colons (:) are not permitted in object names.
-Each object is uniquely identified by its type (*Host*) and name
-(*host1.example.org*). Objects can contain a comma-separated list of
+Each object is uniquely identified by its type (`Host`) and name
+(`host1.example.org`). Objects can contain a comma-separated list of
property declarations. The following data types are available for
property values:
#### Boolean Literals
-The keywords *true* and *false* are equivalent to 1 and 0 respectively.
+The keywords `true` and `false` are equivalent to 1 and 0 respectively.
#### Null Value
-The *null* keyword can be used to specify an empty value.
+The `null` keyword can be used to specify an empty value.
#### Dictionary
### Operators
-In addition to the *=* operator shown above a number of other operators
+In addition to the `=` operator shown above a number of other operators
to manipulate configuration objects are supported. Here's a list of all
available operators:
a += [ "world" ]
}
-In this example a contains both *"hello"* and *"world"*. This currently
+In this example a contains both `"hello"` and `"world"`. This currently
only works for dictionaries and arrays.
<!--
a -= [ "world" ]
}
-In this example a contains *"hello"*. Trying to remove an item that does
+In this example a contains `"hello"`. Trying to remove an item that does
not exist is not an error. Not implemented yet.
#### Operator \*=
macros["address6"] = "::1"
}
-The *"default-host"* and *"test-host"* objects are marked as templates
-using the *template* keyword. Unlike ordinary objects templates are not
+The `default-host` and `test-host` objects are marked as templates
+using the `template` keyword. Unlike ordinary objects templates are not
instantiated at runtime. Parent objects do not necessarily have to be
templates though in general they are.
> **Note**
>
> The final macros dictionary contains all 3 macros and the macro
-> *color* has the value *"blue"*.
+> `color` has the value `"blue"`.
Parent objects are resolved in the order they're specified using the
-*inherits* keyword.
+`inherits` keyword.
### Variables
-Global variables can be set using the *set* keyword:
+Global variables can be set using the `set` keyword:
set VarName = "some value"
### Includes
-Other configuration files can be included using the *include* directive.
+Other configuration files can be included using the `include` directive.
Paths must be relative to the configuration file that contains the
-*include* directive.
+`include` directive.
Example:
### <a id="library"></a> Library directive
-The *library* directive can be used to manually load additional
+The `library` directive can be used to manually load additional
libraries. Libraries can be used to provide additional object types and
methods.
> **Note**
>
-> The *icinga* library is automatically loaded at startup.
+> The `icinga` library is automatically loaded at startup.
<!--
The Pizza definition provides the following validation rules:
-- Pizza objects must contain an attribute *radius* which has to be a
+- Pizza objects must contain an attribute `radius` which has to be a
number.
-- Pizza objects may contain an attribute *ingredients* which has to be
+- Pizza objects may contain an attribute `ingredients` which has to be
a dictionary.
- Elements in the ingredients dictionary can be either a string or a
dictionary.
-- If they're a dictionary they may contain attributes *quantity* (of
- type number) and *name* (of type string).
+- If they're a dictionary they may contain attributes `quantity` (of
+ type number) and `name` (of type string).
-- The script function *ValidateIngredients* is run to perform further
+- The script function `ValidateIngredients` is run to perform further
validation of the ingredients dictionary.
- Pizza objects may contain attribute matching the pattern
> **Note**
>
> 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*
+> hosts inherit their state from the service that is specified using the `check`
> attribute.
Example:
groups |**Optional.** A list of host groups this host belongs to.
host_dependencies|**Optional.** A list of host names which this host depends on. These dependencies are used to determine whether the host is unreachable.
service_dependencies|**Optional.** A list of services which this host depends on. Each array element must be a dictionary containing the keys "host" and "service". These dependencies are used to determine whether the host is unreachable.
- services |**Optional.** Inline definition of services. Each dictionary item specifies a service.<br /><br />The *templates* attribute can be used to specify an array of templates that should be inherited by the service.<br /><br />The new service's name is "hostname:service" - where "service" is the dictionary key in the services dictionary.<br /><br />The dictionary key is used as the service's short name.
+ services |**Optional.** Inline definition of services. Each dictionary item specifies a service.<br /><br />The `templates` attribute can be used to specify an array of templates that should be inherited by the service.<br /><br />The new service's name is "hostname:service" - where "service" is the dictionary key in the services dictionary.<br /><br />The dictionary key is used as the service's short name.
macros |**Optional.** A dictionary containing macros that are specific to this host.
### HostGroup
> **Best Practice**
>
-> Rather than creating a *Service* object for a specific host it is usually easier
-> to just create a *Service* template and using the *services* attribute in the *Host*
+> Rather than creating a `Service` object for a specific host it is usually easier
+> to just create a `Service` template and using the `services` attribute in the `Host`
> object to associate these templates with a host.
Example:
Name |Description
----------------|----------------
- 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).
display_name |**Optional.** A short description of the service.
macros |**Optional.** A dictionary containing macros that are specific to this host.
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.
check\_period |**Optional.** The name of a time period which determines when this service should be checked. Not set by default.
- check\_interval |**Optional.** The check interval (in seconds). This interval is used for checks when the service is in a *HARD* state. Defaults to 5 minutes.
- retry\_interval |**Optional.** The retry interval (in seconds). This interval is used for checks when the service is in a *SOFT* state. Defaults to 1/5th of the check interval if not specified.
+ check\_interval |**Optional.** The check interval (in seconds). This interval is used for checks when the service is in a `HARD` state. Defaults to 5 minutes.
+ retry\_interval |**Optional.** The retry interval (in seconds). This interval is used for checks when the service is in a `SOFT` state. Defaults to 1/5th of the check interval if not specified.
event\_command |**Optional.** The name of an event command that should be executed every time the service's state changes.
flapping\_threshold|TODO
volatile |TODO
host_dependencies|**Optional.** A list of host names which this host depends on. These dependencies are used to determine whether the host is unreachable.
service_dependencies|**Optional.** A list of services which this host depends on. Each array element must be a dictionary containing the keys "host" and "service". These dependencies are used to determine whether the host is unreachable.
groups |**Optional.** The service groups this service belongs to.
- notifications |**Optional.** Inline definition of notifications. Each dictionary item specifies a notification.<br /><br />The *templates* attribute can be used to specify an array of templates that should be inherited by the notification object.<br /><br />The new notification object's name is "hostname:service:notification" - where "notification" is the dictionary key in the notifications dictionary.
+ notifications |**Optional.** Inline definition of notifications. Each dictionary item specifies a notification.<br /><br />The `templates` attribute can be used to specify an array of templates that should be inherited by the notification object.<br /><br />The new notification object's name is "hostname:service:notification" - where "notification" is the dictionary key in the notifications dictionary.
### ServiceGroup
> **Best Practice**
>
-> Rather than creating a *Notification* object for a specific service it is usually easier
-> to just create a *Notification* template and using the *notifications* attribute in the *Service*
+> Rather than creating a `Notification` object for a specific service it is usually easier
+> to just create a `Notification` template and using the `notifications` attribute in the `Service`
> object to associate these templates with a service.
Example:
----------------|----------------
perfdata\_path |**Optional.** Path to the service performance data file. Defaults to IcingaLocalStateDir + "/cache/icinga2/perfdata/perfdata".
format\_template|**Optional.** Format template for the performance data file. Defaults to a template that's suitable for use with PNP4Nagios.
- rotation\_interval|**Optional.** Rotation interval for the file specified in *perfdata\_path*. Defaults to 30 seconds.
+ rotation\_interval|**Optional.** Rotation interval for the file specified in `perfdata\_path`. Defaults to 30 seconds.
> **Note**
>
> When rotating the performance data file the current UNIX timestamp is appended to the path specified
-> in *perfdata\_path* to generate a unique filename.
+> in `perfdata\_path` to generate a unique filename.
### IdoMySqlConnection
----------------|----------------
socket\_type |**Optional.** Specifies the socket type. Can be either "tcp" or "unix". Defaults to "unix".
bind\_host |**Optional.** Only valid when socket\_type is "tcp". Host address to listen on for connections. Defaults to "127.0.0.1".
- bind\_port |**Optional.** Only valid when *socket\_type* is "tcp". Port to listen on for connections. Defaults to 6558.
- socket\_path |**Optional.** Only valid when *socket\_type* is "unix". Specifies the path to the UNIX socket file. Defaults to IcingaLocalStateDir + "/run/icinga2/livestatus".
+ bind\_port |**Optional.** Only valid when `socket\_type` is "tcp". Port to listen on for connections. Defaults to 6558.
+ socket\_path |**Optional.** Only valid when `socket\_type` is "unix". Specifies the path to the UNIX socket file. Defaults to IcingaLocalStateDir + "/run/icinga2/livestatus".
> **Note**
>
The Icinga Template Library (ITL) implements standard templates and object
definitions for commonly used services.
-You can include the ITL by using the *include* directive in your configuration
+You can include the ITL by using the `include` directive in your configuration
file:
include <itl/itl.conf>
### ping4
-Check command object for the *check_ping* plugin.
+Check command object for the `check_ping` plugin.
Macros:
### ping6
-Check command object for the *check_ping* plugin.
+Check command object for the `check_ping` plugin.
Macros:
### dummy
-Check command object for the *check_dummy* plugin.
+Check command object for the `check_dummy` plugin.
Macros:
### tcp
-Check command object for the *check_tcp* plugin.
+Check command object for the `check_tcp` plugin.
Macros:
### udp
-Check command object for the *check_udp* plugin.
+Check command object for the `check_udp` plugin.
Macros:
### http_vhost
-Check command object for the *check_http* plugin.
+Check command object for the `check_http` plugin.
Macros:
### http_ip
-Check command object for the *check_http* plugin.
+Check command object for the `check_http` plugin.
Macros:
### https_vhost
-Check command object for the *check_http* plugin.
+Check command object for the `check_http` plugin.
Macros:
### https_ip
-Check command object for the *check_http* plugin.
+Check command object for the `check_http` plugin.
Macros:
### smtp
-Check command object for the *check_smtp* plugin.
+Check command object for the `check_smtp` plugin.
Macros:
### ssmtp
-Check command object for the *check_ssmtp* plugin.
+Check command object for the `check_ssmtp` plugin.
Macros:
### ntp_time
-Check command object for the *check_ntp_time* plugin.
+Check command object for the `check_ntp_time` plugin.
Macros:
### ssh
-Check command object for the *check_ssh* plugin.
+Check command object for the `check_ssh` plugin.
Macros:
### disk
-Check command object for the *check_disk* plugin.
+Check command object for the `check_disk` plugin.
Macros:
### users
-Check command object for the *check_disk* plugin.
+Check command object for the `check_disk` plugin.
Macros:
### processes
-Check command object for the *check_processes* plugin.
+Check command object for the `check_processes` plugin.
Macros:
### load
-Check command object for the *check_load* plugin.
+Check command object for the `check_load` plugin.
Macros:
### snmp
-Check command object for the *check_snmp* plugin.
+Check command object for the `check_snmp` plugin.
Macros:
### snmp-uptime
-Check command object for the *check_snmp* plugin.
+Check command object for the `check_snmp` plugin.
Macros:
projects / icinga2 / commitdiff