available Icinga web interfaces. It assumes that you are familiar with
the system you're installing Icinga 2 on.
-Details on troubleshooting problems can be found [here](#troubleshooting).
+Details on troubleshooting problems can be found [here](8-troubleshooting.md#troubleshooting).
## <a id="setting-up-icinga2"></a> Setting up Icinga 2
First off you will have to install Icinga 2. The preferred way of doing this
-is to use the official Debian or RPM package repositories depending on which
-operating system and distribution you are running.
+is to use the official package repositories depending on which operating system
+and distribution you are running.
- Distribution | Repository URL
+ Distribution | Repository
------------------------|---------------------------
- Debian | http://packages.icinga.org/debian/
- Ubuntu | http://packages.icinga.org/ubuntu/
- RHEL/CentOS | http://packages.icinga.org/epel/
- OpenSUSE | http://packages.icinga.org/openSUSE/
- SLES | http://packages.icinga.org/SUSE/
+ Debian | [Upstream](https://packages.debian.org/sid/icinga2), [debmon](http://debmon.org/packages/debmon-wheezy/icinga2), [Icinga Repository](http://packages.icinga.org/debian/)
+ Ubuntu | [Upstream](https://launchpad.net/ubuntu/+source/icinga2), [Icinga PPA](https://launchpad.net/~formorer/+archive/ubuntu/icinga), [Icinga Repository](http://packages.icinga.org/ubuntu/)
+ RHEL/CentOS | [Icinga Repository](http://packages.icinga.org/epel/)
+ openSUSE | [Icinga Repository](http://packages.icinga.org/openSUSE/), [Server Monitoring Repository](https://build.opensuse.org/package/show/server:monitoring/icinga2)
+ SLES | [Icinga Repository](http://packages.icinga.org/SUSE/)
+ Gentoo | [Upstream](http://packages.gentoo.org/package/net-analyzer/icinga2)
+ FreeBSD | [Upstream](http://www.freshports.org/net-mgmt/icinga2)
+ ArchLinux | [Upstream](https://aur.archlinux.org/packages/icinga2)
Packages for distributions other than the ones listed above may also be
-available. Please check http://packages.icinga.org/ to see if packages
-are available for your favourite distribution.
+available. Please contact your distribution packagers.
-The packages for RHEL/CentOS 5 depend on other packages which are distributed
+### <a id="installing-requirements"></a> Installing Requirements for Icinga 2
+
+You need to add the Icinga repository to your package management configuration.
+Below is a list with examples for the various distributions.
+
+Debian (debmon):
+
+ # wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
+ # echo 'deb http://debmon.org/debmon debmon-wheezy main' >/etc/apt/sources.list.d/debmon.list
+ # apt-get update
+
+Ubuntu (PPA):
+
+ # add-apt-repository ppa:formorer/icinga
+ # apt-get update
+
+RHEL/CentOS:
+
+ # rpm --import http://packages.icinga.org/icinga.key
+ # wget http://packages.icinga.org/epel/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo
+ # yum makecache
+
+Fedora:
+
+ # wget http://packages.icinga.org/fedora/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo
+ # yum makecache
+
+SLES:
+
+ # zypper ar http://packages.icinga.org/SUSE/ICINGA-release.repo
+ # zypper ref
+
+openSUSE:
+
+ # zypper ar http://packages.icinga.org/openSUSE/ICINGA-release.repo
+ # zypper ref
+
+The packages for RHEL/CentOS depend on other packages which are distributed
as part of the [EPEL repository](http://fedoraproject.org/wiki/EPEL). Please
-make sure to enable this repository.
+make sure to enable this repository by following
+[these instructions](http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F).
+
+### <a id="installing-icinga2"></a> Installing Icinga 2
You can install Icinga 2 by using your distribution's package manager
to install the `icinga2` package.
-On RHEL/CentOS and SLES you will need to use `chkconfig` to enable the
-`icinga2` service. You can manually start Icinga 2 using `/etc/init.d/icinga2 start`.
+Debian/Ubuntu:
+
+ # apt-get install icinga2
+
+RHEL/CentOS/Fedora:
+
+ # yum install icinga2
+
+SLES/openSUSE:
+
+ # zypper install icinga2
+
+On RHEL/CentOS and SLES you will need to use `chkconfig` and `service` to enable and start
+the `icinga2` service:
+
+ # chkconfig icinga2 on
+ # service icinga2 start
+
+RHEL/CentOS 7 and Fedora use [systemd](2-getting-started.md#systemd-service):
+
+ # systemctl enable icinga2
+ # systemctl start icinga2
Some parts of Icinga 2's functionality are available as separate packages:
Name | Description
------------------------|--------------------------------
- icinga2-ido-mysql | DB IDO provider module for MySQL
- icinga2-ido-pgsql | DB IDO provider module for PostgreSQL
-
-If you're running a distribution for which Icinga 2 packages are
-not yet available you will need 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.
+ icinga2-ido-mysql | [DB IDO](2-getting-started.md#configuring-db-ido) provider module for MySQL
+ icinga2-ido-pgsql | [DB IDO](2-getting-started.md#configuring-db-ido) provider module for PostgreSQL
### <a id="installation-enabled-features"></a> Enabled Features during Installation
* `checker` for executing checks
* `notification` for sending notifications
-* `mainlog` for writing the `icinga2.log ` file
-
-Verify that by calling `icinga2-enable-feature` without any additional parameters
-and enable the missing features, if any.
+* `mainlog` for writing the `icinga2.log` file
- # icinga2-enable-feature
- Syntax: icinga2-enable-feature <features separated with whitespaces>
- Example: icinga2-enable-feature checker notification mainlog
- Enables the specified feature(s).
+You can verify that by calling `icinga2 feature list` [CLI command](5-cli-commands.md#cli-command-feature)
+to see which features are enabled and disabled.
- Available features: api checker command compatlog debuglog graphite icingastatus ido-mysql ido-pgsql livestatus mainlog notification perfdata statusdata syslog
+ # icinga2 feature list
+ Disabled features: api command compatlog debuglog graphite icingastatus ido-mysql ido-pgsql livestatus notification perfdata statusdata syslog
Enabled features: checker mainlog notification
+
### <a id="installation-paths"></a> Installation Paths
By default Icinga 2 uses the following files and directories:
------------------------------------|------------------------------------
/etc/icinga2 | Contains Icinga 2 configuration files.
/etc/init.d/icinga2 | The Icinga 2 init script.
- /usr/bin/icinga2-* | Migration and certificate build scripts.
- /usr/sbin/icinga2* | The Icinga 2 binary and feature enable/disable scripts.
+ /usr/sbin/icinga2* | The Icinga 2 binary.
/usr/share/doc/icinga2 | Documentation files that come with Icinga 2.
/usr/share/icinga2/include | The Icinga Template Library and plugin command configuration.
/var/run/icinga2 | PID file.
/var/run/icinga2/cmd | Command pipe and Livestatus socket.
- /var/cache/icinga2 | status.dat/objects.cache.
+ /var/cache/icinga2 | status.dat/objects.cache, icinga2.debug files
/var/spool/icinga2 | Used for performance data spool files.
- /var/lib/icinga2 | Icinga 2 state file, cluster feature replay log and configuration files.
+ /var/lib/icinga2 | Icinga 2 state file, cluster log, local CA and configuration files.
/var/log/icinga2 | Log file location and compat/ directory for the CompatLogger feature.
+## <a id="setting-up-check-plugins"></a> Setting up Check Plugins
+
+Without plugins Icinga 2 does not know how to check external services. The
+[Monitoring Plugins Project](https://www.monitoring-plugins.org/) provides
+an extensive set of plugins which can be used with Icinga 2 to check whether
+services are working properly.
+
+The recommended way of installing these standard plugins is to use your
+distribution's package manager.
+
+> **Note**
+>
+> The `Nagios Plugins` project was renamed to `Monitoring Plugins`
+> in January 2014. At the time of this writing some packages are still
+> using the old name while some distributions have adopted the new package
+> name `monitoring-plugins` already.
+
+For your convenience here is a list of package names for some of the more
+popular operating systems/distributions:
+
+OS/Distribution | Package Name | Installation Path
+-----------------------|--------------------|---------------------------
+RHEL/CentOS (EPEL) | nagios-plugins-all | /usr/lib/nagios/plugins or /usr/lib64/nagios/plugins
+Debian | nagios-plugins | /usr/lib/nagios/plugins
+FreeBSD | nagios-plugins | /usr/local/libexec/nagios
+OS X (MacPorts) | nagios-plugins | /opt/local/libexec
+
+Depending on which directory your plugins are installed into you may need to
+update the global `PluginDir` constant in your Icinga 2 configuration. This macro is used
+by the check command definitions contained in the Icinga Template Library to determine
+where to find the plugin binaries.
+
+Please refer to the [plugins](6-addons-plugins.md#plugins) chapter for details about how to integrate
+additional check plugins into your Icinga 2 setup.
+
+## <a id="configuring-icinga2-first-steps"></a> Configuring Icinga 2: First Steps
+
### <a id="icinga2-conf"></a> icinga2.conf
An example configuration file is installed for you in `/etc/icinga2/icinga2.conf`.
* to the documentation that is distributed as part of Icinga 2.
*/
-Icinga 2 supports [C/C++-style comments](#comments).
+Icinga 2 supports [C/C++-style comments](10-language-reference.md#comments).
/**
* The constants.conf defines global constants.
/**
* The features-available directory contains a number of configuration
* files for features which can be enabled and disabled using the
- * icinga2-enable-feature / icinga2-disable-feature tools. These two tools work by creating
- * and removing symbolic links in the features-enabled directory.
+ * icinga2 feature enable / icinga2 feature disable CLI commands.
+ * These commands work by creating and removing symbolic links in
+ * the features-enabled directory.
*/
include "features-enabled/*.conf"
This `include` directive takes care of including the configuration files for all
-the features which have been enabled with `icinga2-enable-feature`. See
-[Enabling/Disabling Features](#features) for more details.
+the features which have been enabled with `icinga2 feature enable`. See
+[Enabling/Disabling Features](5-cli-commands.md#features) for more details.
+
+ /**
+ * The repository.d directory contains all configuration objects
+ * managed by the 'icinga2 repository' CLI commands.
+ */
+ include_recursive "repository.d"
+
+This `include_recursive` directive is used for discovery of services on remote clients
+and their generated configuration described in
+[this chapter](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
+
/**
* Although in theory you could define all your objects in this file
*/
include_recursive "conf.d"
-You can put your own configuration files in the `conf.d` directory. This
+You can put your own configuration files in the [conf.d](2-getting-started.md#conf-d) directory. This
directive makes sure that all of your own configuration files are included.
+> **Tip**
+>
+> The example configuration is shipped in this directory too. You can either
+> remove it entirely, or adapt the existing configuration structure with your
+> own object configuration.
+
### <a id="constants-conf"></a> constants.conf
-The `constants.conf` configuration file can be used to define global constants:
+The `constants.conf` configuration file can be used to define global constants.
- /**
- * This file defines global constants which can be used in
- * the other configuration files.
- */
+By default, you need to make sure to set these constants:
+
+* The `PluginDir` constant must be pointed to your [check plugins](2-getting-started.md#setting-up-check-plugins) path.
+This constant is required by the shipped
+[plugin check command configuration](13-icinga-template-library.md#plugin-check-commands).
+* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
+if not set. This constant is required for local host configuration, monitoring remote clients and
+cluster setup.
+
+Example:
/* The directory which contains the plugins from the Monitoring Plugins project. */
- const PluginDir = "/usr/lib/nagios/plugins"
+ const PluginDir = "/usr/lib64/nagios/plugins"
+
- /* Our local instance name. This should be the common name from the API certificate */
- const NodeName = "localhost"
+ /* The directory which contains the Manubulon plugins.
+ * Check the documentation, chapter "SNMP Manubulon Plugin Check Commands", for details.
+ */
+ const ManubulonPluginDir = "/usr/lib64/nagios/plugins"
+
+ /* Our local instance name. By default this is the server's hostname as returned by `hostname --fqdn`.
+ * This should be the common name from the API certificate.
+ */
+ //const NodeName = "localhost"
/* Our local zone name. */
const ZoneName = NodeName
-### <a id="zones-conf"></a> zones.conf
+ /* Secret key for remote node tickets */
+ const TicketSalt = ""
-The `zones.conf` configuration file can be used to configure `Endpoint` and `Zone` objects
-required for a [distributed zone setup](#distributed-monitoring-high-availability). By default
-a local dummy zone is defined based on the `NodeName` constant defined in
-[constants.conf](#constants-conf).
+The `ZoneName` and `TicketSalt` constants are required for remote client
+and distributed setups only.
-> **Note**
->
-> Not required for single instance installations.
+### <a id="conf-d"></a> The conf.d Directory
+This directory contains example configuration which should help you get started
+with monitoring the local host and its services. It is included in the
+[icinga2.conf](2-getting-started.md#icinga2-conf) configuration file by default.
-### <a id="localhost-conf"></a> localhost.conf
+It can be used as reference example for your own configuration strategy.
+Just keep in mind to include the main directories in the
+[icinga2.conf](2-getting-started.md#icinga2-conf) file.
-The `conf.d/localhost.conf` file contains our first host definition:
+You are certainly not bound to it. Remove it, if you prefer your own
+way of deploying Icinga 2 configuration.
- /**
- * A host definition. You can create your own configuration files
- * in the conf.d directory (e.g. one per host). By default all *.conf
- * files in this directory are included.
+Further details on configuration best practice and how to build your
+own strategy is described in [this chapter](3-monitoring-basics.md#configuration-best-practice).
+
+Available configuration files shipped by default:
+
+* [hosts.conf](2-getting-started.md#hosts-conf)
+* [services.conf](2-getting-started.md#services-conf)
+* [users.conf](2-getting-started.md#users-conf)
+* [notifications.conf](2-getting-started.md#notifications-conf)
+* [commands.conf](2-getting-started.md#commands-conf)
+* [groups.conf](2-getting-started.md#groups-conf)
+* [templates.conf](2-getting-started.md#templates-conf)
+* [downtimes.conf](2-getting-started.md#downtimes-conf)
+* [timeperiods.conf](2-getting-started.md#timeperiods-conf)
+* [satellite.conf](2-getting-started.md#satellite-conf)
+
+#### <a id="hosts-conf"></a> hosts.conf
+
+The `hosts.conf` file contains an example host based on your
+`NodeName` setting in [constants.conf](2-getting-started.md#constants-conf). You
+can use global constants for your object names instead of string
+values.
+
+The `import` keyword is used to import the `generic-host` template which
+takes care of setting up the host check command to `hostalive`. If you
+require a different check command, you can override it in the object definition.
+
+The `vars` attribute can be used to define custom attributes which are available
+for check and notification commands. Most of the [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands)
+in the Icinga Template Library require an `address` attribute.
+
+The custom attribute `os` is evaluated by the `linux-servers` group in
+[groups.conf](2-getting-started.md#groups-conf) making the local host a member.
+
+The example host will show you how to
+
+* define http vhost attributes for the `http` service apply rule defined
+in [services.conf](2-getting-started.md#services-conf).
+* define disks (all, specific `/`) and their attributes for the `disk`
+service apply rule defined in [services.conf](2-getting-started.md#services-conf).
+* define notification types (`mail`) and set the groups attribute. This
+will be used by notification apply rules in [notifications.conf](notifications-conf).
+
+If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can
+uncomment the http vhost attributes and relaod Icinga 2. The apply
+rules in [services.conf](2-getting-started.md#services-conf) will automatically
+generate a new service checking the `/icingaweb2` URI using the `http`
+check.
+
+ /*
+ * Host definitions with object attributes
+ * used for apply rules for Service, Notification,
+ * Dependency and ScheduledDowntime objects.
+ *
+ * Tip: Use `icinga2 object list --type Host` to
+ * list all host objects after running
+ * configuration validation (`icinga2 daemon -C`).
+ */
+
+ /*
+ * This is an example host based on your
+ * local host's FQDN. Specify the NodeName
+ * constant in `constants.conf` or use your
+ * own description, e.g. "db-host-1".
*/
- object Host "localhost" {
+ object Host NodeName {
+ /* Import the default host template defined in `templates.conf`. */
import "generic-host"
+ /* Specify the address attributes for checks e.g. `ssh` or `http`. */
address = "127.0.0.1"
address6 = "::1"
+ /* Set custom attribute `os` for hostgroup assignment in `groups.conf`. */
vars.os = "Linux"
- vars.sla = "24x7"
+
+ /* Define http vhost attributes for service apply rules in `services.conf`. */
+ vars.http_vhosts["http"] = {
+ http_uri = "/"
+ }
+ /* Uncomment if you've sucessfully installed Icinga Web 2. */
+ //vars.http_vhosts["Icinga Web 2"] = {
+ // http_uri = "/icingaweb2"
+ //}
+
+ /* Define disks and attributes for service apply rules in `services.conf`. */
+ vars.disks["disk"] = {
+ /* No parameters. */
+ }
+ vars.disks["disk /"] = {
+ disk_partitions = "/"
+ }
+
+ /* Define notification mail attributes for notification apply rules in `notifications.conf`. */
+ vars.notification["mail"] = {
+ /* The UserGroup `icingaadmins` is defined in `users.conf`. */
+ groups = [ "icingaadmins" ]
+ }
}
-This defines the host `localhost`. The `import` keyword is used to import
-the `generic-host` template which takes care of setting up the host check
-command to `hostalive`. If you require a different check command, you can
-override it in the object definition.
+This is only the host object definition. Now we'll need to make sure that this
+host and your additional hosts are getting [services](2-getting-started.md#services-conf) applied.
-The `vars` attribute can be used to define custom attributes which are available
-for check and notification commands. Most of the templates in the Icinga
-Template Library require an `address` attribute.
+> **Tip**
+>
+> If you don't understand all the attributes and how to use [apply rules](10-language-reference.md#apply)
+> don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain
+> that in detail.
-The custom attribute `os` is evaluated by the `linux-servers` group in
-`groups.conf `making the host `localhost` a member.
+#### <a id="services-conf"></a> services.conf
- object HostGroup "linux-servers" {
- display_name = "Linux Servers"
+These service [apply rules](10-language-reference.md#apply) will show you how to monitor
+the local host, but also allow you to re-use or modify them for
+your own requirements.
- assign where host.vars.os == "Linux"
+You should define all your service apply rules in `services.conf`
+or any other central location keeping them organized.
+
+By default, the local host will be monitored by the following services
+
+Service(s) | Applied on host(s)
+--------------------------------------------|------------------------
+`load`, `procs`, `swap`, `users`, `icinga` | The `NodeName` host only
+`ping4`, `ping6` | All hosts with `address` resp. `address6` attribute
+`ssh` | All hosts with `address` and `vars.os` set to `Linux`
+`http`, optional: `Icinga Web 2` | All hosts with custom attribute `http_vhosts` defined as dictionary
+`disk`, `disk /` | All hosts with custom attribute `disks` defined as dictionary
+
+The Debian packages also ship an additional `apt` service check applied to the local host.
+
+The command object `icinga` for the embedded health check is provided by the
+[Icinga Template Library (ITL)](13-icinga-template-library.md#icinga-template-library) while `http_ip`, `ssh`, `load`, `processes`,
+`users` and `disk` are all provided by the [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands)
+which we enabled earlier by including the `itl` and `plugins` configuration file.
+
+
+Example `load` service apply rule:
+
+ apply Service "load" {
+ import "generic-service"
+
+ check_command = "load"
+
+ /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
+ vars.backup_downtime = "02:00-03:00"
+
+ assign where host.name == NodeName
}
-A host notification apply rule in `notifications.conf` checks for the custom
-attribute `sla` being set to `24x7` automatically applying a host notification.
+The `apply` keyword can be used to create new objects which are associated with
+another group of objects. You can `import` existing templates, define (custom)
+attributes.
- /**
- * The example notification apply rules.
- *
- * Only applied if host/service objects have
- * the custom attribute `sla` set to `24x7`.
- */
+The custom attribe `backup_downtime` is defined to a specific timerange string.
+This variable value will be used for applying a `ScheduledDowntime` object to
+these services in [downtimes.conf](2-getting-started.md#downtimes-conf).
- apply Notification "mail-icingaadmin" to Host {
- import "mail-host-notification"
+In this example the `assign where` condition is a boolean expression which is
+evaluated for all objects of type `Host` and a new service with name "load"
+is created for each matching host. [Expression operators](10-language-reference.md#expression-operators)
+may be used in `assign where` conditions.
- user_groups = [ "icingaadmins" ]
+Multiple `assign where` condition can be combined with `AND` using the `&&` operator
+as shown in the `ssh` example:
- assign where host.vars.sla == "24x7"
+ apply Service "ssh" {
+ import "generic-service"
+
+ check_command = "ssh"
+
+ assign where host.address && host.vars.os == "Linux"
}
-Now it's time to define services for the host object. Because these checks
-are only available for the `localhost` host, they are organized below
-`hosts/localhost/`.
+In this example, the service `ssh` is applied to all hosts having the `address`
+attribute defined `AND` having the custom attribute `os` set to the string
+`Linux`.
+You can modify this condition to match multiple expressions by combinding `AND`
+and `OR` using `&&` and `||` [operators](10-language-reference.md#expression-operators), for example
+`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
-> **Tip**
->
-> The directory tree and file organisation is just an example. You are
-> free to define your own strategy. Just keep in mind to include the
-> main directories in the [icinga2.conf](#icinga2-conf) file.
- object Service "disk" {
+A more advanced example is shown by the `http` and `disk` service apply
+rules. While one `apply` rule for `ssh` will only create a service for matching
+hosts, you can go one step further: Generate apply rules based on array items
+or dictionary key-value pairs.
+
+The idea is simple: Your host in [hosts.conf](2-getting-started.md#hosts-conf) defines the
+`disks` dictionary as custom attribute in `vars`.
+
+Remember the example from [hosts.conf](2-getting-started.md#hosts-conf):
+
+ ...
+
+ /* Define disks and attributes for service apply rules in `services.conf`. */
+ vars.disks["disk"] = {
+ /* No parameters. */
+ }
+ vars.disks["disk /"] = {
+ disk_partition = "/"
+ }
+ ...
+
+
+This dictionary contains multiple service names we want to monitor. `disk`
+should just check all available disks, while `disk /` will pass an additional
+parameter `disk_partition` to the check command.
+
+You'll recognize that the naming is important - that's the very same name
+as it is passed from a service to a check command argument. Read about services
+and passing check commands in [this chapter](3-monitoring-basics.md#command-passing-parameters).
+
+Using `apply Service for` omits the service name, it will take the key stored in
+the `disk` variable in `key => config` as new service object name.
+
+The `for` keyword expects a loop definition, for example `key => value in dictionary`
+as known from Perl and other scripting languages.
+
+Once defined like this, the `apply` rule defined below will do the following:
+
+* only match hosts with `host.vars.disks` defined through the `assign where` condition
+* loop through all entries in the `host.vars.disks` dictionary. That's `disk` and `disk /` as keys.
+* call `apply` on each, and set the service object name from the provided key
+* inside apply, the `generic-service` template is imported
+* defining the [disk](13-icinga-template-library.md#plugin-check-command-disk) check command requiring command arguments like `disk_partition`
+* adding the `config` dictionary items to `vars`. Simply said, there's now `vars.disk_partition` defined for the
+generated service
+
+Configuration example:
+
+ apply Service for (disk => config in host.vars.disks) {
import "generic-service"
- host_name = "localhost"
check_command = "disk"
- vars.sla = "24x7"
+
+ vars += config
+
+ assign where host.vars.disks
}
- object Service "http" {
- import "generic-service"
+A similar example is used for the `http` services. That way you can make your
+host the information provider for all apply rules. Define them once, and only
+manage your hosts.
+
+Look into [notifications.conf](2-getting-started.md#notifications-conf) how this technique is used
+for applying notifications to hosts and services using their type and user
+attributes.
+
+Don't forget to install the [check plugins](2-getting-started.md#setting-up-check-plugins) required by
+the hosts and services and their check commands.
+
+Further details on the monitoring configuration can be found in the
+[monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter.
+
+#### <a id="users-conf"></a> users.conf
- host_name = "localhost"
- check_command = "http"
- vars.sla = "24x7"
+Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
+[hosts.conf](2-getting-started.md#hosts-conf) for defining a custom host attribute later used in
+[notifications.conf](2-getting-started.md#notifications-conf) for notification apply rules.
+
+ object User "icingaadmin" {
+ import "generic-user"
+
+ display_name = "Icinga 2 Admin"
+ groups = [ "icingaadmins" ]
+
+ email = "icinga@localhost"
}
- object Service "load" {
- import "generic-service"
+ object UserGroup "icingaadmins" {
+ display_name = "Icinga 2 Admin Group"
+ }
- host_name = "localhost"
- check_command = "load"
- vars.sla = "24x7"
+
+#### <a id="notifications-conf"></a> notifications.conf
+
+Notifications for check alerts are an integral part or your
+Icinga 2 monitoring stack.
+
+The shipped example defines two notification apply rules for hosts and services.
+Both `apply` rules match on the same condition: They are only applied if the
+nested dictionary attribute `notification.mail` is set.
+
+Please note that the `to` keyword is important in [notification apply rules](3-monitoring-basics.md#using-apply-notifications)
+defining whether these notifications are applies to hosts or services.
+The `import` keyword imports the specific mail templates defined in [templates.conf](2-getting-started.md#templates-conf).
+
+The `interval` attribute is not explicitly set - it [defaults to 30 minutes](12-object-types.md#objecttype-notification).
+
+By setting the `user_groups` to the value provided by the
+respective [host.vars.notification.mail](2-getting-started.md#hosts-conf) attribute we'll
+implicitely use the`icingaadmins` UserGroup defined in [users.conf](2-getting-started.md#users-conf).
+
+ apply Notification "mail-icingaadmin" to Host {
+ import "mail-host-notification"
+
+ user_groups = host.vars.notification.mail.groups
+
+ assign where host.vars.notification.mail
}
- object Service "procs" {
- import "generic-service"
+ apply Notification "mail-icingaadmin" to Service {
+ import "mail-service-notification"
+
+ user_groups = host.vars.notification.mail.groups
- host_name = "localhost"
- check_command = "procs"
- vars.sla = "24x7"
+ assign where host.vars.notification.mail
}
- object Service "ssh" {
- import "generic-service"
+More details on defining notifications and their additional attributes such as
+filters can be read in [this chapter](3-monitoring-basics.md#notifications).
- host_name = "localhost"
- check_command = "ssh"
- vars.sla = "24x7"
+#### <a id="commands-conf"></a> commands.conf
+
+This is the place where your own command configuration can be defined. By default
+only the notification commands used by the notification templates defined in [templates.conf](2-getting-started.md#templates-conf).
+
+> **Tip**
+>
+> Icinga 2 ships the most common command definitions already in the
+> [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands) definitions. More details on
+> that topic in the [troubleshooting section](8-troubleshooting.md#check-command-definitions).
+
+You can freely customize these notification commands, and adapt them for your needs.
+Read more on that topic [here](3-monitoring-basics.md#notification-commands).
+
+#### <a id="groups-conf"></a> groups.conf
+
+The example host defined in [hosts.conf](hosts-conf) already has the
+custom attribute `os` set to `Linux` and is therefore automatically
+a member of the host group `linux-servers`.
+
+This is done by using the [group assign](10-language-reference.md#group-assign) expressions similar
+to previously seen [apply rules](3-monitoring-basics.md#using-apply).
+
+ object HostGroup "linux-servers" {
+ display_name = "Linux Servers"
+
+ assign where host.vars.os == "Linux"
}
- object Service "swap" {
- import "generic-service"
+ object HostGroup "windows-servers" {
+ display_name = "Windows Servers"
- host_name = "localhost"
- check_command = "swap"
- vars.sla = "24x7"
+ assign where host.vars.os == "Windows"
}
- object Service "users" {
- import "generic-service"
+Service groups can be grouped together by similar pattern matches.
+The [match() function](10-language-reference.md#function-calls) expects a wildcard match string
+and the attribute string to match with.
+
+ object ServiceGroup "ping" {
+ display_name = "Ping Checks"
- host_name = "localhost"
- check_command = "users"
- vars.sla = "24x7"
+ assign where match("ping*", service.name)
}
- object Service "icinga" {
- import "generic-service"
+ object ServiceGroup "http" {
+ display_name = "HTTP Checks"
- host_name = "localhost"
- check_command = "icinga"
- vars.sla = "24x7"
+ assign where match("http*", service.check_command)
}
-The command object `icinga` for the embedded health check is provided by the
-[Icinga Template Library (ITL)](#itl) while `http_ip`, `ssh`, `load`, `processes`,
-`users` and `disk` are all provided by the plugin check commands which we enabled
-earlier by including the `itl` and `plugins` configuration file.
+ object ServiceGroup "disk" {
+ display_name = "Disk Checks"
-The Debian packages also ship an additional `apt` service check.
+ assign where match("disk*", service.check_command)
+ }
-> **Best Practice**
->
-> Instead of defining each service object and assigning it to a host object
-> using the `host_name` attribute rather use the [apply rules](#apply)
-> simplifying your configuration.
-There are two generic services applied to all hosts in the host group `linux-servers`
-and `windows-servers` by default: `ping4` and `ping6`. Host objects without
-a valid `address` resp. `address6` attribute will be excluded.
+#### <a id="templates-conf"></a> templates.conf
+
+All shipped example configuration objects use generic global templates by
+default. Be it setting a default `check_command` attribute in the `generic-host`
+templates for your hosts defined in [hosts.conf](2-getting-started.md#hosts-conf), or defining
+the default `states` and `types` filters for notification apply rules defined in
+[notifications.conf](2-getting-started.md#notifications-conf).
- apply Service "ping4" {
- import "generic-service"
- check_command = "ping4"
- vars.sla = "24x7"
+ template Host "generic-host" {
+ max_check_attempts = 5
+ check_interval = 1m
+ retry_interval = 30s
- assign where "linux-servers" in host.groups
- assign where "windows-servers" in host.groups
- ignore where host.address == ""
+ check_command = "hostalive"
}
- apply Service "ping6" {
- import "generic-service"
+ template Service "generic-service" {
+ max_check_attempts = 3
+ check_interval = 1m
+ retry_interval = 30s
+ }
+
+The `hostalive` check command is shipped with Icinga 2 in the
+[Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands).
+
+
+ template Notification "mail-host-notification" {
+ command = "mail-host-notification"
- check_command = "ping6"
- vars.sla = "24x7"
+ states = [ Up, Down ]
+ types = [ Problem, Acknowledgement, Recovery, Custom,
+ FlappingStart, FlappingEnd,
+ DowntimeStart, DowntimeEnd, DowntimeRemoved ]
- assign where "linux-servers" in host.groups
- assign where "windows-servers" in host.groups
- ignore where host.address6 == ""
+ period = "24x7"
}
-Each of these services has the custom attribute `sla` set to `24x7`. The
-notification apply rule in `notifications.conf` will automatically apply
-a service notification matchting this attribute pattern.
+ template Notification "mail-service-notification" {
+ command = "mail-service-notification"
- apply Notification "mail-icingaadmin" to Service {
- import "mail-service-notification"
+ states = [ OK, Warning, Critical, Unknown ]
+ types = [ Problem, Acknowledgement, Recovery, Custom,
+ FlappingStart, FlappingEnd,
+ DowntimeStart, DowntimeEnd, DowntimeRemoved ]
+
+ period = "24x7"
+ }
+
+More details on `Notification` object attributes can be found [here](12-object-types.md#objecttype-notification).
+
+
+#### <a id="downtimes-conf"></a> downtimes.conf
+
+The `load` service apply rule defined in [services.conf](2-getting-started.md#services-conf) defines
+the `backup_downtime` custom attribute.
+
+The [ScheduledDowntime](12-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute
+to define the default value for the time ranges required for recurring downtime slots.
- user_groups = [ "icingaadmins" ]
+ apply ScheduledDowntime "backup-downtime" to Service {
+ author = "icingaadmin"
+ comment = "Scheduled downtime for backup"
- assign where service.vars.sla == "24x7"
+ ranges = {
+ monday = service.vars.backup_downtime
+ tuesday = service.vars.backup_downtime
+ wednesday = service.vars.backup_downtime
+ thursday = service.vars.backup_downtime
+ friday = service.vars.backup_downtime
+ saturday = service.vars.backup_downtime
+ sunday = service.vars.backup_downtime
+ }
+
+ assign where service.vars.backup_downtime != ""
}
-Don't forget to install the [check plugins](#setting-up-check-plugins) required by the services and
-their check commands.
+
+#### <a id="timeperiods-conf"></a> timeperiods.conf
+
+This file ships the default timeperiod definitions for `24x7`, `9to5`
+and `never`. Timeperiod objects are referenced by `*period`
+objects such as hosts, services or notifications.
+
+
+#### <a id="satellite-conf"></a> satellite.conf
+
+Ships default templates and dependencies for [monitoring remote clients](4-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
+using service discovery and [config generation](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
+on the master. Can be ignored/removed on setups not using this features.
+
Further details on the monitoring configuration can be found in the
-[monitoring basics](#monitoring-basics) chapter.
+[monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter.
-## <a id="setting-up-check-plugins"></a> Setting up Check Plugins
+## <a id="configuring-db-ido"></a> Configuring DB IDO
-Without plugins
-Icinga 2 does not know how to check external services. The
-[Monitoring Plugins Project](https://www.monitoring-plugins.org/) provides
-an extensive set of plugins which can be used with Icinga 2 to check whether
-services are working properly.
+The DB IDO (Database Icinga Data Output) modules for Icinga 2 take care of exporting
+all configuration and status information into a database. The IDO database is used
+by a number of projects including [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2),
+Icinga Reporting or Icinga Web 1.x.
-The recommended way of installing these standard plugins is to use your
-distribution's package manager.
+You only need to set up the IDO modules if you're using an external project which uses
+the IDO database.
+
+There is a separate module for each database backend. At present support for
+both MySQL and PostgreSQL is implemented.
+
+Icinga 2 uses the Icinga 1.x IDOUtils database schema. Icinga 2 requires additional
+features not yet released with older Icinga 1.x versions.
> **Note**
>
-> The `Nagios Plugins` project was renamed to `Monitoring Plugins`
-> in January 2014. At the time of this writing the packages are still
-> using the old name.
+> Please check the [what's new](1-about.md#whats-new) section for the required schema version.
-For your convenience here is a list of package names for some of the more
-popular operating systems/distributions:
+### <a id="installing-database"></a> Installing the Database Server
-OS/Distribution | Package Name | Installation Path
------------------------|--------------------|---------------------------
-RHEL/CentOS (EPEL) | nagios-plugins-all | /usr/lib/nagios/plugins or /usr/lib64/nagios/plugins
-Debian | nagios-plugins | /usr/lib/nagios/plugins
-FreeBSD | nagios-plugins | /usr/local/libexec/nagios
-OS X (MacPorts) | nagios-plugins | /opt/local/libexec
+In order to use DB IDO you need to setup either [MySQL](2-getting-started.md#installing-database-mysql-server)
+or [PostgreSQL](2-getting-started.md#installing-database-postgresql-server) as supported database server.
-Depending on which directory your plugins are installed into you may need to
-update the global `PluginDir` constant 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.
+#### <a id="installing-database-mysql-server"></a> Installing MySQL database server
-### <a id="integrate-additional-plugins"></a> Integrate Additional Plugins
+Debian/Ubuntu:
-For some services you may need additional 'check plugins' which are not provided
-by the official Monitoring Plugins project.
+ # apt-get install mysql-server mysql-client
-All existing Nagios or Icinga 1.x plugins should work with Icinga 2. Here's a
-list of popular community sites which host check plugins:
+RHEL/CentOS 5/6:
-* [MonitoringExchange](https://www.monitoringexchange.org)
-* [Icinga Wiki](https://wiki.icinga.org)
+ # yum install mysql-server mysql
+ # chkconfig mysqld on
+ # service mysqld start
-The recommended way of setting up these plugins is to copy them to a common directory
-and create an extra global constant, e.g. `CustomPluginDir` in your `constants.conf`
-configuration file:
+RHEL/CentOS 7 and Fedora 20 prefer MariaDB over MySQL:
- # cp check_snmp_int.pl /opt/plugins
- # chmod +x /opt/plugins/check_snmp_int.pl
+ # yum install mariadb-server mariadb
+ # systemctl enable mariadb
+ # systemctl start mariadb
- # cat /etc/icinga2/constants.conf
- /**
- * This file defines global constants which can be used in
- * the other configuration files. At a minimum the
- * PluginDir constant should be defined.
- */
+SUSE:
- const PluginDir = "/usr/lib/nagios/plugins"
- const CustomPluginDir = "/opt/monitoring"
+ # zypper install mysql mysql-client
+ # chkconfig mysqld on
+ # service mysqld start
-Prior to using the check plugin with Icinga 2 you should ensure that it is working properly
-by trying to run it on the console using whichever user Icinga 2 is running as:
+RHEL based distributions do not automatically set a secure root password. Do that **now**:
- # su - icinga -s /bin/bash
- $ /opt/plugins/check_snmp_int.pl --help
+ # /usr/bin/mysql_secure_installation
-Additional libraries may be required for some plugins. Please consult the plugin
-documentation and/or README for installation instructions.
+#### <a id="installing-database-postgresql-server"></a> Installing PostgreSQL database server
-Each plugin requires a [CheckCommand](#objecttype-checkcommand) object in your
-configuration which can be used in the [Service](#objecttype-service) or
-[Host](#objecttype-host) object definition. Examples for `CheckCommand`
-objects can be found in the [Plugin Check Commands](#plugin-check-commands) shipped
-with Icinga 2.
-For further information on your monitoring configuration read the
-[monitoring basics](#monitoring-basics).
+Debian/Ubuntu:
+ # apt-get install postgresql
-## <a id="configuring-db-ido"></a> Configuring DB IDO
+RHEL/CentOS 5/6:
-The DB IDO (Database Icinga Data Output) modules for Icinga 2 take care of exporting
-all configuration and status information into a database. The IDO database is used
-by a number of projects including Icinga Web 1.x, Reporting or Icinga Web 2.
+ # yum install postgresql-server postgresql
+ # chkconfig postgresql on
+ # service postgresql start
-There is a separate module for each database back-end. At present support for
-both MySQL and PostgreSQL is implemented.
+RHEL/CentOS 7 and Fedora 20 use [systemd](2-getting-started.md#systemd-service):
-Icinga 2 uses the Icinga 1.x IDOUtils database schema starting with version
-`1.11.3`. Icinga 2 requires additional features not yet released with older
-Icinga 1.x versions.
+ # yum install postgresql-server postgresql
+ # systemctl enable postgresql
+ # systemctl start postgresql
-> **Tip**
->
-> Only install the IDO feature if your web interface or reporting tool requires
-> you to do so (for example, [Icinga Web](#setting-up-icinga-web) or [Icinga Web 2](#setting-up-icingaweb2)).
-> [Icinga Classic UI](#setting-up-icinga-classic-ui) does not use IDO as backend.
+SUSE:
-### <a id="configuring-db-ido-mysql"></a> Configuring DB IDO MySQL
+ # zypper install postgresql postgresql-server
+ # chkconfig postgresql on
+ # service postgresql start
-#### <a id="setting-up-mysql-db"></a> Setting up the MySQL database
+### <a id="configuring-db-ido-mysql"></a> Configuring DB IDO MySQL
First of all you have to install the `icinga2-ido-mysql` package using your
-distribution's package manager. Once you have done that you can proceed with
-setting up a MySQL database for Icinga 2:
+distribution's package manager.
- # mysql -u root -p
+Debian/Ubuntu:
- mysql> CREATE DATABASE icinga;
+ # apt-get install icinga2-ido-mysql
+
+RHEL/CentOS:
+
+ # yum install icinga2-ido-mysql
+
+SUSE:
+
+ # zypper install icinga2-ido-mysql
+
+
+
+> **Note**
+>
+> Upstream Debian packages provide a database configuration wizard by default.
+> You can skip the automated setup and install/upgrade the database manually
+> if you prefer that.
- mysql> GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga.* TO 'icinga'@'localhost' IDENTIFIED BY 'icinga';
+#### <a id="setting-up-mysql-db"></a> Setting up the MySQL database
- mysql> quit
+Set up a MySQL database for Icinga 2:
+ # mysql -u root -p
+
+ mysql> CREATE DATABASE icinga;
+ GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga.* TO 'icinga'@'localhost' IDENTIFIED BY 'icinga';
+ quit
After creating the database you can import the Icinga 2 IDO schema using the
following command:
- # mysql -u root -p icinga < /usr/share/doc/icinga2-ido-mysql-*/schema/mysql.sql
-
-The schema file location differs by the distribution used:
+ # mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/mysql.sql
- Distribution | Schema Files
- --------------|---------------------
- RHEL | `/usr/share/doc/icinga2-ido-mysql-*/schema` (* means package version).
- SUSE | `/usr/share/doc/packages/icinga2-ido-mysql/schema`
- Debian/Ubuntu | `/usr/share/icinga2-ido-mysql/schema`
#### <a id="upgrading-mysql-db"></a> Upgrading the MySQL database
-Check the `schema/upgrade` directory for an incremental schema upgrade file.
-If there isn't an upgrade file available there's nothing to do.
+If you're upgrading an existing Icinga 2 instance you should check the
+`/usr/share/icinga2-ido-mysql/schema/upgrade` directory for an incremental schema upgrade file.
+
+> **Note**
+>
+> If there isn't an upgrade file for your current version available there's nothing to do.
Apply all database schema upgrade files incrementially.
- # mysql -u root -p icinga < /usr/share/doc/icinga2-ido-mysql-*/schema/upgrade/<version>.sql
+ # mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/<version>.sql
The Icinga 2 DB IDO module will check for the required database schema version on startup
and generate an error message if not satisfied.
+
+**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.2.0`. Look into
+the *upgrade* directory:
+
+ $ ls /usr/share/icinga2-ido-mysql/schema/upgrade/
+ 2.0.2.sql 2.1.0.sql 2.2.0.sql
+
+There are two new upgrade files called `2.1.0.sql` and `2.2.0.sql`
+which must be applied incrementially to your IDO database.
+
+
#### <a id="installing-ido-mysql"></a> Installing the IDO MySQL module
The package provides a new configuration file that is installed in
`/etc/icinga2/features-available/ido-mysql.conf`. You will need to update the
database credentials in this file.
+All available attributes are listed in the
+[IdoMysqlConnection object](12-object-types.md#objecttype-idomysqlconnection) configuration details.
-You can enable the `ido-mysql` feature configuration file using `icinga2-enable-feature`:
+You can enable the `ido-mysql` feature configuration file using `icinga2 feature enable`:
- # icinga2-enable-feature ido-mysql
+ # icinga2 feature enable ido-mysql
Module 'ido-mysql' was enabled.
Make sure to restart Icinga 2 for these changes to take effect.
After enabling the ido-mysql feature you have to restart Icinga 2:
- # /etc/init.d/icinga2 restart
+Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
+
+ # service icinga2 restart
+
+RHEL/CentOS 7 and Fedora 20:
+ # systemctl restart icinga2
### <a id="configuring-db-ido-postgresql"></a> Configuring DB IDO PostgreSQL
+First of all you have to install the `icinga2-ido-pgsql` package using your
+distribution's package manager.
+
+Debian/Ubuntu:
+
+ # apt-get install icinga2-ido-pgsql
+
+RHEL/CentOS:
+
+ # yum install icinga2-ido-pgsql
+
+SUSE:
+
+ # zypper install icinga2-ido-pgsql
+
+> **Note**
+>
+> Upstream Debian packages provide a database configuration wizard by default.
+> You can skip the automated setup and install/upgrade the database manually
+> if you prefer that.
+
#### Setting up the PostgreSQL database
-First of all you have to install the `icinga2-ido-pgsql` package using your
-distribution's package manager. Once you have done that you can proceed with
-setting up a PostgreSQL database for Icinga 2:
+Set up a PostgreSQL database for Icinga 2:
# cd /tmp
# sudo -u postgres psql -c "CREATE ROLE icinga WITH LOGIN PASSWORD 'icinga'";
using the following command:
# export PGPASSWORD=icinga
- # psql -U icinga -d icinga < /usr/share/doc/icinga2-ido-pgsql-*/schema/pgsql.sql
-
-The schema file location differs by the distribution used:
-
- Distribution | Schema Files
- --------------|---------------------
- RHEL | `/usr/share/doc/icinga2-ido-pgsql-*/schema` (* means package version).
- SUSE | `/usr/share/doc/packages/icinga2-ido-pgsql/schema`
- Debian/Ubuntu | `/usr/share/icinga2-ido-pgsql/schema`
-
+ # psql -U icinga -d icinga < /usr/share/icinga2-ido-pgsql/schema/pgsql.sql
#### <a id="upgrading-postgresql-db"></a> Upgrading the PostgreSQL database
-Check the `schema/upgrade` directory for an incremental schema upgrade file.
-If there isn't an upgrade file available there's nothing to do.
+If you're updating an existing Icinga 2 instance you should check the
+`/usr/share/icinga2-ido-pgsql/schema/upgrade` directory for an incremental schema upgrade file.
+
+> **Note**
+>
+> If there isn't an upgrade file for your current version available there's nothing to do.
Apply all database schema upgrade files incrementially.
# export PGPASSWORD=icinga
- # psql -U icinga -d icinga < /usr/share/doc/icinga2-ido-pgsql-*/schema/upgrade/<version>.sql
+ # psql -U icinga -d icinga < /usr/share/icinga2-ido-pgsql/schema/upgrade/<version>.sql
The Icinga 2 DB IDO module will check for the required database schema version on startup
and generate an error message if not satisfied.
+**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.1.0`. Look into
+the *upgrade* directory:
+
+ $ ls /usr/share/icinga2-ido-pgsql/schema/upgrade/
+ 2.0.2.sql 2.1.0.sql 2.2.0.sql
+
+There are two new upgrade files called `2.1.0.sql` and `2.2.0.sql`
+which must be applied incrementially to your IDO database.
+
+
#### <a id="installing-ido-postgresql"></a> Installing the IDO PostgreSQL module
The package provides a new configuration file that is installed in
`/etc/icinga2/features-available/ido-pgsql.conf`. You will need to update the
database credentials in this file.
+All available attributes are listed in the
+[IdoPgsqlConnection object](12-object-types.md#objecttype-idopgsqlconnection) configuration details.
-You can enable the `ido-pgsql` feature configuration file using `icinga2-enable-feature`:
+You can enable the `ido-pgsql` feature configuration file using `icinga2 feature enable`:
- # icinga2-enable-feature ido-pgsql
+ # icinga2 feature enable ido-pgsql
Module 'ido-pgsql' was enabled.
Make sure to restart Icinga 2 for these changes to take effect.
After enabling the ido-pgsql feature you have to restart Icinga 2:
- # /etc/init.d/icinga2 restart
+Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
+ # service icinga2 restart
-## <a id="setting-up-livestatus"></a> Setting up Livestatus
+RHEL/CentOS 7 and Fedora 20:
-The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
-implements a query protocol that lets users query their Icinga instance for
-status information. It can also be used to send commands.
+ # systemctl restart icinga2
-> **Tip**
->
-> Only install the Livestatus feature if your web interface or addon requires
-> you to do so (for example, [Icinga Web 2](#setting-up-icingaweb2)).
-> [Icinga Classic UI](#setting-up-icinga-classic-ui) and [Icinga Web](#setting-up-icinga-web)
-> do not use Livestatus as backend.
-The Livestatus component that is distributed as part of Icinga 2 is a
-re-implementation of the Livestatus protocol which is compatible with MK
-Livestatus.
+### <a id="setting-up-external-command-pipe"></a> Setting Up External Command Pipe
-Details on the available tables and attributes with Icinga 2 can be found
-in the [Livestatus Schema](#schema-livestatus) section.
+Web interfaces and other Icinga addons are able to send commands to
+Icinga 2 through the external command pipe.
-You can enable Livestatus using icinga2-enable-feature:
+You can enable the External Command Pipe using the CLI:
- # icinga2-enable-feature livestatus
+ # icinga2 feature enable command
After that you will have to restart Icinga 2:
- # /etc/init.d/icinga2 restart
+Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
-By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
+ # service icinga2 restart
-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:
+RHEL/CentOS 7 and Fedora 20:
- # usermod -a -G icingacmd www-data
+ # systemctl restart icinga2
-The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
-`nagios` if you're using Debian.
+By default the command pipe file is owned by the group `icingacmd` with read/write
+permissions. Add your webserver's user to the group `icingacmd` to
+enable sending commands to Icinga 2 through your web interface:
-Change "www-data" to the user you're using to run queries.
+ # usermod -a -G icingacmd www-data
-In order to use the historical tables provided by the livestatus feature (for example, the
-`log` table) you need to have the `CompatLogger` feature enabled. By default these logs
-are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
-`compat_log_path` configuration attribute.
+Debian packages use `nagios` as the default user and group name. Therefore change `icingacmd` to
+`nagios`.
+The webserver's user is different between distributions so you might have to change `www-data` to
+`wwwrun`, `www`, or `apache`.
- # icinga2-enable-feature compatlog
+Change "www-data" to the user you're using to run queries.
+> **Note**
+>
+> Packages will do that automatically. Verify that by running `id <your-webserver-user>` and skip this
+> step.
## <a id="setting-up-icinga2-user-interfaces"></a> Setting up Icinga 2 User Interfaces
-Icinga 2 is compatible with Icinga 1.x user interfaces by providing additional
-features required as backends.
+Icinga 2 can be used with [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2), using
+DB IDO or Livestatus as preferred backend provider, next to the command pipe.
-Furthermore these interfaces (and somewhere in the future an Icinga 2
-exclusive interface) can be used for the newly created `Icinga Web 2`
-user interface.
+Icinga 2 also is compatible with Icinga 1.x user interfaces
+[Classic UI 1.x](2-getting-started.md#installing-icinga-classic-ui) and [Icinga Web 1.x](2-getting-started.md#setting-up-icinga-web)
+by providing additional features required as backends.
-Some interface features will only work in a limited manner due to
-[compatibility reasons](#differences-1x-2), other features like the
+Some Icinga 1.x interface features will only work in a limited manner due to
+[compatibility reasons](9-migrating-from-icinga-1x.md#differences-1x-2), other features like the
statusmap parents are available by dumping the host dependencies as parents.
Special restrictions are noted specifically in the sections below.
+You can also use other user interface addons, if you prefer. Keep in mind
+that Icinga 2 core features might not be fully supported in these addons.
+
> **Tip**
>
-> Choose your preferred interface. There's no need to install [Classic UI](#setting-up-icinga-classic-ui)
-> if you prefer [Icinga Web](#setting-up-icinga-web) or [Icinga Web 2](#setting-up-icingaweb2) for example.
+> Choose your preferred interface. There's no need to install [Classic UI 1.x](2-getting-started.md#setting-up-icinga-classic-ui)
+> if you prefer [Icinga Web 1.x](2-getting-started.md#setting-up-icinga-web) or [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) for example.
+
+### <a id="icinga2-user-interface-requirements"></a> Requirements
+
+* Web server (Apache2/Httpd, Nginx, Lighttp, etc)
+* User credentials
+* Firewall ports (tcp/80)
+
+The Debian, RHEL and SUSE packages for Icinga [Classic UI](2-getting-started.md#setting-up-icinga-classic-ui),
+[Web](2-getting-started.md#setting-up-icinga-web) and [Icingaweb 2](2-getting-started.md#setting-up-icingaweb2) depend on Apache2
+as web server.
+
+#### <a id="icinga2-user-interface-webserver"></a> Webserver
+
+Debian/Ubuntu packages will automatically fetch and install the required packages.
+
+RHEL/CentOS/Fedora:
+
+ # yum install httpd
+ # chkconfig httpd on && service httpd start
+ ## RHEL7
+ # systemctl enable httpd && systemctl start httpd
+
+SUSE:
+
+ # zypper install apache2
+ # chkconfig on && service apache2 start
+
+#### <a id="icinga2-user-interface-firewall-rules"></a> Firewall Rules
+
+Example:
+
+ # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
+ # service iptables save
+
+RHEL/CentOS 7 specific:
+
+ # firewall-cmd --add-service=http
+ # firewall-cmd --permanent --add-service=http
+
+### <a id="setting-up-icingaweb2"></a> Setting up Icinga Web 2
-### <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI
+Icinga Web 2 supports `DB IDO` or `Livestatus` as backends.
+
+Using DB IDO as backend, you need to install and configure the
+[DB IDO backend](2-getting-started.md#configuring-db-ido).
+Once finished, you can enable the feature for DB IDO MySQL:
+
+ # icinga2 feature enable ido-mysql
+
+Furthermore [external commands](3-monitoring-basics.md#external-commands) are supported through the external
+command pipe.
+
+ # icinga2 feature enable command
+
+In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
+
+[Icinga Web 2](https://github.com/Icinga/icingaweb2) ships its own
+web-based setup wizard which will guide you through the entire setup process.
+
+Generate the Webserver configuration and a setup token using its local cli
+and proceed with the web setup when accessing `/icingaweb2` after reloading
+your webserver configuration.
+
+Please consult the [installation documentation](https://github.com/Icinga/icingaweb2/blob/master/doc/installation.md)
+shipped with `Icinga Web 2` for further instructions on how to install
+`Icinga Web 2` and to configure backends, resources and instances manually.
+
+Check the [Icinga website](https://www.icinga.org) for release announcements
+and packages.
+
+
+### <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI 1.x
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
+is supported by the Icinga 1.x Classic UI. [External commands](3-monitoring-basics.md#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.
-#### <a id="installing-icinga-classic-ui"></a> Installing Icinga Classic UI
+#### <a id="installing-icinga-classic-ui"></a> Installing Icinga Classic UI 1.x
The Icinga package repository has both Debian and RPM packages. You can install
the Classic UI using the following packages:
Distribution | Packages
--------------|---------------------
Debian | icinga2-classicui
- all others | icinga2-classicui-config icinga-gui
+ RHEL/SUSE | icinga2-classicui-config icinga-gui
The Debian packages require additional packages which are provided by the
-[Debian Monitoring Project](http://www.debmon.org) (`DebMon`) repository.
+[Debian Monitoring Project](http://www.debmon.org) (`debmon`) repository.
`libjs-jquery-ui` requires at least version `1.10.*` which is not available
-in Debian Wheezy and Ubuntu 12.04 LTS (Precise). Add the following repositories
+in Debian 7 (Wheezy) and Ubuntu 12.04 LTS (Precise). Add the following repositories
to satisfy this dependency:
Distribution | Package Repositories
------------------------------|------------------------------
- Debian Wheezy | [wheezy-backports](http://backports.debian.org/Instructions/) or [DebMon](http://www.debmon.org)
+ Debian Wheezy | [wheezy-backports](http://backports.debian.org/Instructions/) or [debmon](http://www.debmon.org)
Ubuntu 12.04 LTS (Precise) | [Icinga PPA](https://launchpad.net/~formorer/+archive/icinga)
On all distributions other than Debian you may have to restart both your web
server as well as Icinga 2 after installing the Classic UI package.
+Icinga Classic UI requires the [StatusDataWriter](3-monitoring-basics.md#status-data), [CompatLogger](3-monitoring-basics.md#compat-logging)
+and [ExternalCommandListener](3-monitoring-basics.md#external-commands) features.
+Enable these features and restart Icinga 2.
+
+ # icinga2 feature enable statusdata compatlog command
+
+In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
+
+#### <a id="setting-up-icinga-classic-ui-summary"></a> Setting Up Icinga Classic UI 1.x Summary
+
Verify that your Icinga 1.x Classic UI works by browsing to your Classic
UI installation URL:
Debian | [http://localhost/icinga2-classicui](http://localhost/icinga2-classicui) | asked during installation
all others | [http://localhost/icinga](http://localhost/icinga) | icingaadmin/icingaadmin
-### <a id="setting-up-icinga-web"></a> Setting up Icinga Web
+For further information on configuration, troubleshooting and interface documentation
+please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
+
+### <a id="setting-up-icinga-web"></a> Setting up Icinga Web 1.x
Icinga 2 can write to the same schema supplied by `Icinga IDOUtils 1.x` which
is an explicit requirement to run `Icinga Web` next to the external command pipe.
-Therefore you need to setup the [DB IDO feature](#configuring-ido) remarked in the previous sections.
+Therefore you need to setup the [DB IDO feature](2-getting-started.md#configuring-db-ido) remarked in the previous sections.
-#### <a id="installing-icinga-web"></a> Installing Icinga Web
+#### <a id="installing-icinga-web"></a> Installing Icinga Web 1.x
The Icinga package repository has both Debian and RPM packages. You can install
-the Classic UI using the following packages:
+Icinga Web using the following packages (RPMs ship an additional configuration package):
Distribution | Packages
- --------------|-------------------------------------
+ --------------|-------------------------------------------------------
RHEL/SUSE | icinga-web icinga-web-{mysql,pgsql}
- Debian | icinga-web
+ Debian | icinga-web icinga-web-config-icinga2-ido-{mysql,pgsql}
+
+#### <a id="icinga-web-rpm-notes"></a> Icinga Web 1.x on RPM based systems
-Additionally you need to setup the `icinga_web` database.
+Additionally you need to setup the `icinga_web` database and import the database schema.
+Details can be found in the package `README` files, for example [README.RHEL](https://github.com/Icinga/icinga-web/blob/master/doc/README.RHEL)
The Icinga Web RPM packages install the schema files into
`/usr/share/doc/icinga-web-*/schema` (`*` means package version).
On SuSE-based distributions the schema files are installed in
`/usr/share/doc/packages/icinga-web/schema`.
+Example for RHEL and MySQL:
+
+ # mysql -u root -p
+
+ mysql> CREATE DATABASE icinga_web;
+ GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga_web.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'icinga_web';
+ quit
+
+ # mysql -u root -p icinga_web < /usr/share/doc/icinga-web-<version>/schema/mysql.sql
+
Icinga Web requires the IDO feature as database backend using MySQL or PostgreSQL.
Enable that feature, e.g. for MySQL.
- # icinga2-enable-feature ido-mysql
+ # icinga2 feature enable ido-mysql
If you've changed your default credentials you may either create a read-only user
or use the credentials defined in the IDO feature for Icinga Web backend configuration.
# icinga-web-clearcache
-Additionally you need to enable the `command` feature:
+Additionally you need to enable the `command` feature for sending [external commands](3-monitoring-basics.md#external-commands):
+
+ # icinga2 feature enable command
- # icinga2-enable-feature command
+In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
Then edit the Icinga Web configuration for sending commands in `/etc/icinga-web/conf.d/access.xml`
(RHEL) or `/etc/icinga-web/access.xml` (SUSE) setting the command pipe path
<write>
<files>
- <resource name="icinga_pipe">/var/run/icinga2/cmd/icinga.cmd</resource>
+ <resource name="icinga_pipe">/var/run/icinga2/cmd/icinga2.cmd</resource>
</files>
</write>
> The path to the Icinga Web `clearcache` script may differ. Please check the
> [Icinga Web documentation](https://docs.icinga.org) for details.
+#### <a id="icinga-web-debian-notes"></a> Icinga Web on Debian systems
+
+Since Icinga Web `1.11.1-2` the IDO auto-configuration has been moved into
+additional packages on Debian and Ubuntu.
+
+The package `icinga-web` no longer configures the IDO connection. You must now
+use one of the config packages:
+
+ - `icinga-web-config-icinga2-ido-mysql`
+ - `icinga-web-config-icinga2-ido-pgsql`
+
+These packages take care of setting up the [DB IDO](2-getting-started.md#configuring-db-ido) configuration,
+enabling the external command pipe for Icinga Web and depend on
+the corresponding packages of Icinga 2.
+
+Please read the `README.Debian` files for details and advanced configuration:
+
+ - `/usr/share/doc/icinga-web/README.Debian`
+ - `/usr/share/doc/icinga-web-config-icinga2-ido-mysql/README.Debian`
+ - `/usr/share/doc/icinga-web-config-icinga2-ido-pgsql/README.Debian`
+
+When changing Icinga Web configuration files make sure to clear the config cache:
+
+ # /usr/lib/icinga-web/bin/clearcache.sh
+
+> **Note**
+>
+> If you are using an older version of Icinga Web, install it like this and adapt
+> the configuration manually as shown in [the RPM notes](2-getting-started.md#icinga-web-rpm-notes):
+>
+> `apt-get install --no-install-recommends icinga-web`
+
+#### <a id="setting-up-icinga-web-summary"></a> Setting Up Icinga Web 1.x Summary
+
Verify that your Icinga 1.x Web works by browsing to your Web installation URL:
Distribution | URL | Default Login
Debian | [http://localhost/icinga-web](http://localhost/icinga-web) | asked during installation
all others | [http://localhost/icinga-web](http://localhost/icinga-web) | root/password
-
-### <a id="setting-up-icingaweb2"></a> Setting up Icinga Web 2
-
-Icinga Web 2 currently supports `status.dat`, `DB IDO`, or `Livestatus` as backends.
-Please consult the INSTALL documentation shipped with `Icinga Web 2` for
-further instructions.
-
-Icinga Web 2 is still under development. Rather than installing it
-yourself you should consider testing it using the available Vagrant
-demo VM.
+For further information on configuration, troubleshooting and interface documentation
+please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
### <a id="additional-visualization"></a> Additional visualization
There are many visualization addons which can be used with Icinga 2.
-Some of the more popular ones are PNP, inGraph (graphing performance data),
-Graphite, and NagVis (network maps).
+Some of the more popular ones are [PNP](6-addons-plugins.md#addons-graphing-pnp), [inGraph](6-addons-plugins.md#addons-graphing-pnp)
+(graphing performance data), [Graphite](6-addons-plugins.md#addons-graphing-pnp), and
+[NagVis](6-addons-plugins.md#addons-visualization-nagvis) (network maps).
## <a id="configuration-tools"></a> Configuration Tools
-Well known configuration tools for Icinga 1.x such as [LConf](http://www.netways.de/en/de/produkte/icinga/addons/lconf/),
-[NConf](http://www.nconf.org/) or [NagiosQL](http://www.nagiosql.org/)
-store their configuration in a custom format in their backends (LDAP or RDBMS).
-Currently only LConf 1.4.x supports Icinga 2 configuration export. If you require
-your favourite configuration tool to export Icinga 2 configuration, please get in
-touch with their developers.
+If you require your favourite configuration tool to export Icinga 2 configuration, please get in
+touch with their developers. The Icinga project does not provide a configuration web interface
+or similar.
+
+> **Tip**
+>
+> Get to know the new configuration format and the advanced [apply](3-monitoring-basics.md#using-apply) rules and
+> use [syntax highlighting](2-getting-started.md#configuration-syntax-highlighting) in vim/nano.
If you're looking for puppet manifests, chef cookbooks, ansible recipes, etc - we're happy
to integrate them upstream, so please get in touch at [https://support.icinga.org](https://support.icinga.org).
+These tools are in development and require feedback and tests:
+
+* [Ansible Roles](https://github.com/Icinga/icinga2-ansible)
+* [Puppet Module](https://github.com/Icinga/puppet-icinga2)
+
## <a id="configuration-syntax-highlighting"></a> Configuration Syntax Highlighting
-Icinga 2 ships configuration examples for syntax highlighting using the `vim` and `nano`editors.
+Icinga 2 ships configuration examples for syntax highlighting using the `vim` and `nano` editors.
The RHEL, SUSE and Debian package `icinga2-common` install these files into
`/usr/share/*/icinga2-common/syntax`. Sources provide these files in `tools/syntax`.
using the init script. Using Debian packages the user and group are set to `nagios`
for historical reasons.
-### <a id="cmdline"></a> Command-line Options
-
- $ icinga2 --help
- icinga2 - The Icinga 2 network monitoring daemon.
-
- Supported options:
- --help show this help message
- -V [ --version ] show version information
- -l [ --library ] arg load a library
- -I [ --include ] arg add include search directory
- -D [ --define] args define a constant
- -c [ --config ] arg parse a configuration file
- -C [ --validate ] exit after validating the configuration
- -x [ --debug ] arg enable debugging with severity level specified
- -d [ --daemonize ] detach from the controlling terminal
- -e [ --errorlog ] arg log fatal errors to the specified log file (only works
- in combination with --daemonize)
- -u [ --user ] arg user to run Icinga as
- -g [ --group ] arg group to run Icinga as
-
- Report bugs at <https://dev.icinga.org/>
- Icinga home page: <http://www.icinga.org/>
-
-#### Libraries
-
-Instead of loading libraries using the [`library` config directive](#library)
-you can also use the `--library` command-line option.
-
-#### Constants
+### <a id="systemd-service"></a> systemd Service
-[Global constants](#global-constants) can be set using the `--define` command-line option.
+Some distributions (e.g. Fedora, openSUSE and RHEL/CentOS 7) use systemd. The Icinga 2
+packages automatically install the necessary systemd unit files.
-#### Config Include Path
+The Icinga 2 systemd service can be (re)started, reloaded, stopped and also queried for its current status.
-When including files you can specify that the include search path should be
-checked. You can do this by putting your configuration file name in angle
-brackets like this:
+ # systemctl status icinga2
+ icinga2.service - Icinga host/service/network monitoring system
+ Loaded: loaded (/usr/lib/systemd/system/icinga2.service; disabled)
+ Active: active (running) since Mi 2014-07-23 13:39:38 CEST; 15s ago
+ Process: 21692 ExecStart=/usr/sbin/icinga2 -c ${ICINGA2_CONFIG_FILE} -d -e ${ICINGA2_ERROR_LOG} -u ${ICINGA2_USER} -g ${ICINGA2_GROUP} (code=exited, status=0/SUCCESS)
+ Process: 21674 ExecStartPre=/usr/sbin/icinga2-prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
+ Main PID: 21727 (icinga2)
+ CGroup: /system.slice/icinga2.service
+ └─21727 /usr/sbin/icinga2 -c /etc/icinga2/icinga2.conf -d -e /var/log/icinga2/error.log -u icinga -g icinga --no-stack-rlimit
- include <test.conf>
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 309 Service(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 1 User(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 15 Notification(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 4 ScheduledDowntime(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 1 UserGroup(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 1 IcingaApplication(s).
+ Jul 23 13:39:38 nbmif icinga2[21692]: [2014-07-23 13:39:38 +0200] information/ConfigItem: Checked 8 Dependency(s).
+ Jul 23 13:39:38 nbmif systemd[1]: Started Icinga host/service/network monitoring system.
-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
-is the only search directory.
+The `systemctl` command supports the following actions:
-Using the `--include` command-line option additional search directories can be
-added.
-
-#### Config Files
-
-Using the `--config` option you can specify one or more configuration 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
-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 `icinga2-enable-feature` and `icinga2-disable-feature` tools,
-respectively.
-
-The `icinga2-enable-feature` 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:
-
- # icinga2-enable-feature
- Syntax: icinga2-enable-feature <feature>
- Enables the specified feature.
-
- Available features: statusdata
-
-Using the `icinga2-enable-feature` command you can enable features:
-
- # icinga2-enable-feature statusdata
- Module 'statusdata' was enabled.
- Make sure to restart Icinga 2 for these changes to take effect.
-
-You can disable features using the `icinga2-disable-feature` command:
-
- # icinga2-disable-feature statusdata
- Module 'statusdata' was disabled.
- Make sure to restart Icinga 2 for these changes to take effect.
-
-The `icinga2-enable-feature` and `icinga2-disable-feature` commands do not
-restart Icinga 2. You will need to restart Icinga 2 using the init script
-after enabling or disabling features.
-
-### <a id="config-validation"></a> Configuration Validation
-
-Once you've edited the configuration files make sure to tell Icinga 2 to validate
-the configuration changes. Icinga 2 will log any configuration error including
-a hint on the file, the line number and the affected configuration line itself.
-
-The following example creates an apply rule without any `assign` condition.
-
- apply Service "5872-ping4" {
- import "test-generic-service"
- check_command = "ping4"
- //assign where match("5872-*", host.name)
- }
-
-Validate the configuration with the init script option `checkconfig`
-
- # /etc/init.d/icinga2 checkconfig
-
-or manually passing the `-C` argument:
-
- # /usr/sbin/icinga2 -c /etc/icinga2/icinga2.conf -C
-
- [2014-05-22 17:07:25 +0200] critical/ConfigItem: Location:
- /etc/icinga2/conf.d/tests/5872.conf(5): }
- /etc/icinga2/conf.d/tests/5872.conf(6):
- /etc/icinga2/conf.d/tests/5872.conf(7): apply Service "5872-ping4" {
- ^^^^^^^^^^^^^
- /etc/icinga2/conf.d/tests/5872.conf(8): import "test-generic-service"
- /etc/icinga2/conf.d/tests/5872.conf(9): check_command = "ping4"
-
- Config error: 'apply' is missing 'assign'
- [2014-05-22 17:07:25 +0200] critical/ConfigItem: 1 errors, 0 warnings.
- Icinga 2 detected configuration errors.
-
-
-### <a id="config-change-reload"></a> Reload on Configuration Changes
-
-Everytime you have changed your configuration you should first tell Icinga 2
-to [validate](#config-validation). If there are no validation errors you can
-safely reload the Icinga 2 daemon.
-
- # /etc/init.d/icinga2 reload
-
-> **Note**
->
-> The `reload` action will send the `SIGHUP` signal to the Icinga 2 daemon
-> which will validate the configuration in a separate process and not stop
-> the other events like check execution, notifications, etc.
->
-> Details can be found [here](#differences-1x-2-real-reload).
-
-
-## <a id="vagrant"></a> Vagrant Demo VM
-
-The Icinga Vagrant Git repository contains support for [Vagrant](http://docs.vagrantup.com/v2/)
-with VirtualBox. Please note that Vagrant version `1.0.x` is not supported. At least
-version `1.2.x` is required.
-
-In order to build the Vagrant VM first you will have to check out
-the Git repository:
-
- $ git clone git://git.icinga.org/icinga-vagrant.git
-
-For Icinga 2 there are currently two scenarios available:
-
-* `icinga2x` bringing up a standalone box with Icinga 2
-* `icinga2x-cluster` setting up two virtual machines in a master/slave cluster
+ 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.
+ status | The `status` action checks if Icinga 2 is running.
+ enable | The `enable` action enables the service being started at system boot time (similar to `chkconfig`)
-> **Note**
->
-> Please consult the `README` file for each project for further installation
-> details at [https://github.com/Icinga/icinga-vagrant]
+If you're stuck with configuration errors, you can manually invoke the [configuration validation](5-cli-commands.md#config-validation).
-Once you have checked out the Git repository navigate to your required
-vagrant box and build the VM using the following command:
+ # systemctl enable icinga2
- $ vagrant up
+ # systemctl restart icinga2
+ Job for icinga2.service failed. See 'systemctl status icinga2.service' and 'journalctl -xn' for details.
-The Vagrant VMs are based on CentOS 6.x and are using the official
-Icinga 2 RPM snapshot packages from `packages.icinga.org`. The check
-plugins are installed from EPEL providing RPMs with sources from the
-Monitoring Plugins project.
projects / icinga2 / blobdiff