## <a id="what-is-icinga2"></a> What is Icinga 2?
Icinga 2 is an open source monitoring system which checks the availability of your
-network resources, notifies users of outages and generates performance data for reporting.
+network resources, notifies users of outages, and generates performance data for reporting.
-Scalable and extensible, Icinga 2 can monitor complex, large environments across
+Scalable and extensible, Icinga 2 can monitor large, complex environments across
multiple locations.
## <a id="licensing"></a> Licensing
## <a id="contribute"></a> Contribute
-There are many ways to contribute to Icinga - be it by sending patches, testing and
-reporting bugs, reviewing and updating the documentation. Every contribution
+There are many ways to contribute to Icinga - whether it be sending patches, testing,
+reporting bugs, or reviewing and updating the documentation. Every contribution
is appreciated!
Please get in touch with the Icinga team at [https://www.icinga.org/ecosystem/].
* Use [Packages](#getting-started)
Look for available packages on [http://packages.icinga.org] or ask your distribution's maintainer.
-Compiling from source is not recommended, and not the default either.
+Compiling from source is not recommended.
* Real Distributed Architecture
* High Performance
Multithreaded and scalable for small embedded systems as well as large scale environments.
-Running checks every second - not an issue anymore.
+Running checks every second is no longer a problem.
* Modular & flexible [features](#features)
-Enable only the features required for the local installation. Using Icinga Web 2 and requiring
-DB IDO, but no status data? No problem, just enable ido-mysql and disable statusdata.
-Another example: Graphite should be enabled on a dedicated cluster node. Enable it over there
-and point it to the carbon cache socket.
+Enable only the features you require. Want to use Icinga Web 2 with DB IDO but no status data?
+No problem! Just enable ido-mysql and disable statusdata. Another example: Graphite should be enabled
+on a dedicated cluster node. Enable it over there and point it to the carbon cache socket.
* Native support for the [Livestatus protocol](#setting-up-livestatus)
-Next to the Icinga 1.x status and log files and the IDO database backend the commonly used
-Livestatus protocol is available with Icinga 2. Either as unix or tcp socket.
+In Icinga2, the 'Livestatus' protocol is available for use as either a UNIX, or TCP socket.
* Native support for [Graphite](#graphite-carbon-cache-writer)
Icinga 2 still supports writing performance data files for graphing addons, but also adds the
-capability of writing performance data directly onto a Graphite tcp socket simplifying realtime
+capability of writing performance data directly into a Graphite TCP socket simplifying realtime
monitoring graphs.
* Dynamic configuration language
[Environment variables](#command-environment-variables) exported on-demand populated with
runtime evaluated macros.
Three types of commands used for different actions: checks, notifications and events.
-Check timeout for commands instead of a global option. Command custom attributes allowing
-you to specify default values for the command.
+Check timeout for commands instead of a global option. Commands also have custom attributes allowing
+you to specify default values.
* Custom Runtime Macros
and notification commands. No more duplicated contacts for different notification types.
Telling notification filters by state and type, even more fine-grained than Icinga 1.x.
[Escalation notifications](#notification-escalations) and [delayed notifications](#first-notification-delay)
-are just notifications with additional begin and/or end time attribute.
+are just notifications with an additional begin and/or end time attribute.
* Dependencies between Hosts and Services
* [Recurring Downtimes](#recurring-downtimes)
-Forget the external cronjob scheduling downtimes on-demand. Configure them right away as Icinga 2
-configuration objects and set their active time window.
+Forget using cronjobs to set up recurring downtime - you can configure them as Icinga2 configuration
+objects and specify their active time window.
* Embedded Health Checks
* [Vagrant Demo VM](#vagrant)
Used for demo cases and development tests. Get Icinga 2 running within minutes and spread the #monitoringlove
-to your friends and partners.
+to your friends and colleagues.
## <a id="setting-up-icinga2"></a> Setting up Icinga 2
-First of all you will have to install Icinga 2. The preferred way of doing this
+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.
icinga2-ido-mysql | IDO provider module for MySQL
icinga2-ido-pgsql | IDO provider module for PostgreSQL
-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
+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.
## <a id="setting-up-check-plugins"></a> Setting up Check Plugins
-On its own Icinga 2 does not know how to check external services. The
+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.
### <a id="integrate-additional-plugins"></a> Integrate Additional Plugins
-For some services you may need additional check plugins which are not provided
+For some services you may need additional 'check plugins' which are not provided
by the official Monitoring Plugins project.
All existing Nagios or Icinga 1.x plugins should work with Icinga 2. Here's a
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 in `/var/log/icinga2/compat`. A different path can be set using the `compat_log_path`
-configuration attribute.
+are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
+`compat_log_path` configuration attribute.
# icinga2-enable-feature compatlog
## <a id="setting-up-icinga2-user-interfaces"></a> Setting up Icinga 2 User Interfaces
-Icinga 2 is compatible to Icinga 1.x user interfaces by providing additional
+Icinga 2 is compatible with Icinga 1.x user interfaces by providing additional
features required as backends.
Furthermore these interfaces (and somewhere in the future an Icinga 2
Some interface features will only work in a limited manner due to
[compatibility reasons](#differences-1x-2), other features like the
-statusmap parents are available dumping the host dependencies as parents.
+statusmap parents are available by dumping the host dependencies as parents.
Special restrictions are noted specifically in the sections below.
> **Tip**
#### <a id="addons-graphing-pnp"></a> inGraph
-inGraph (https://www.netways.org/projects/ingraph/wiki) requires only the ingraph-collector
-configured pointing to the perfdata files Icinga 2's [PerfdataWriter](#performance-data) will
+inGraph (https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
+to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](#performance-data) will
write to the performance data spool directory.
#### <a id="addons-graphing-pnp"></a> Graphite
-There are Graphite addons available collecting the performance data files as well. But
-natively you just use the [GraphiteWriter](#graphite-carbon-cache-writer) feature.
+There are Graphite addons available for collecting the performance data files as well. But
+natively you can use the [GraphiteWriter](#graphite-carbon-cache-writer) feature.
#### <a id="addons-reporting"></a> Icinga Reporting
#### <a id="addons-visualization-nagvis"></a> NagVis
-Either using Livestatus or DB IDO as backend you can create your own network maps
+By using either Livestatus or DB IDO as a backend you can create your own network maps
based on your monitoring configuration and status data using NagVis (http://www.nagvis.org).
### <a id="addons-web-interfaces"></a> Web Interfaces
-Next to the Icinga supported web interfaces (Classic UI 1.x, Web 1.x, Web 2) there are a
-couple of community provided web interfaces too:
+As well as the Icinga supported web interfaces (Classic UI 1.x, Web 1.x, Web 2) there are a
+number of community provided web interfaces too:
* Thruk (http://www.thruk.org) based on the [Livestatus](#livestatus) feature
## <a id="plugins"></a> Plugins
-Additional plugins next to the [Monitoring Plugins](https://www.monitoring-plugins.org)
-are available at the [Monitoring Exchange](#https://www.monitoringexchange.org) platform.
+You can find plugins (additional to the ones at [Monitoring Plugins](https://www.monitoring-plugins.org)) over at
+[Monitoring Exchange](#https://www.monitoringexchange.org)
More details on the plugins can also be found on the Icinga Wiki at https://wiki.icinga.org
## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
-Run Icinga 2 in foreground with debugging enabled. Specify the console
-log severity as additional parameter argument to `-x`. Default
-is `debug`.
+Run Icinga 2 in the foreground with debugging enabled. Specify the console
+log severity as an additional parameter argument to `-x`.
# /usr/sbin/icinga2 -c /etc/icinga2/icinga2.conf -x notice
## <a id="checks-not-executed"></a> Checks are not executed
-* Check the debug log if the check command gets executed
-* Verify that failed dependencies do not prevent the command execution
+* Check the debug log to see if the check command gets executed
+* Verify that failed depedencies do not prevent command execution
* Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
# sudo -u icinga /usr/lib/nagios/plugins/check_ping -4 -H 127.0.0.1 -c 5000,100% -w 3000,80%
## <a id="notifications-not-sent"></a> Notifications are not sent
-* Check the debug log if a notification is triggered
+* Check the debug log to see if a notification is triggered
* If yes, verify that all conditions are satisfied
-* Any errors on the notification command execution logged?
+* Are any errors on the notification command execution logged?
Verify the following configuration
## <a id="feature-not-working"></a> Feature is not working
-* Make sure that the feature configuration is enabled by symlink from `features-available/`
+* Make sure that the feature configuration is enabled by symlinking from `features-available/`
to `features-enabled` and that the latter is included in [icinga2.conf](#icinga2-conf).
* Are the feature attributes set correctly according to the documentation?
* Any errors on the logs?
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
-Icinga 2 allows you to import templates using the [import](#import) keyword. If these template
-contain additional attributes your objects will automatically inherit them. You can override
+Icinga 2 allows you to import templates using the [import](#import) keyword. If these templates
+contain additional attributes, your objects will automatically inherit them. You can override
or modify these attributes in the current object.
>**Tip**
>
> If you're opening an issue at [https://dev.icinga.org] make sure
-> to attach as much details as possible.
+> to attach as much detail as possible.
### <a id="development-debug-gdb-backtrace-stepping"></a> GDB Backtrace Stepping
-Identifying the problem may require stepping into the backtrace analysing
-the current scope, attributes and possible unmet requirements. `p` prints
+Identifying the problem may require stepping into the backtrace, analysing
+the current scope, attributes, and possible unmet requirements. `p` prints
the value of the selected variable or function call result.
(gdb) up
### <a id="development-debug-gdb-breakpoint"></a> GDB Breakpoints
-Set a breakpoint to a specific function call, or file specific line.
+To set a breakpoint to a specific function call, or file specific line.
(gdb) b checkable.cpp:125
(gdb) b icinga::Checkable::SetEnablePerfdata
## <a id="configuration-migration"></a> Configuration Migration
-The Icinga 2 configuration format introduces plenty of behavioural changes.
+The Icinga 2 configuration format introduces plenty of behavioural changes. In
+order to ease migration from Icinga 1.x, Icinga 2 ships its own config migration
+script.
### <a id="configuration-migration-script"></a> Configuration Migration Script
-In order to migrate existing configuration in Icinga 1.x format the Icinga CLI
-as part of the Icinga Web 2 project will provide a configuration migration module.
+In order to migrate existing configurations in Icinga 1.x format,
+the Icinga CLI, as part of the Icinga Web 2 project will provide
+a conversion module.
-Details can be found in [https://dev.icinga.org/issues/5929].
+Due to the complexity of the Icinga 1.x configuration format, the migration
+script might not currently work for all use cases.
+
+The migration script tries to preserve your existing template structure and
+adds new templates where appropriate. However, the original file structure is
+not preserved.
+
+The migration script also uses templates from the Icinga Template Library where
+possible.
+>>>>>>> Fixes for poor grammar and bad sentence structure.:doc/7-migration.md
### <a id="manual-config-migration"></a> Manual Config Migration
For a long-term migration of your configuration you should consider re-creating
-your configuration based on the Icinga 2 proposed way of doing configuration right.
-
-Please read the [next section](#differences-1x-2) to get an idea about the differences between 1.x and 2.
+your configuration based on the proposed Icinga 2 configuration paradigm.
+Please read the [next chapter](#differences-1x-2) to find out more about the differences
+between 1.x and 2.
## <a id="differences-1x-2"></a> Differences between Icinga 1.x and 2
#### <a id="differences-1x-2-sample-configuration-itl"></a> Sample Configuration and ITL
While Icinga 1.x ships sample configuration and templates spread in various
-object files Icinga 2 moves all templates into the Icinga Template Library (ITL)
-and includes that in the sample configuration.
+object files, Icinga 2 moves all templates into the Icinga Template Library (ITL)
+and includes them in the sample configuration.
Additional plugin check commands are shipped with Icinga 2 as well.
projects / icinga2 / commitdiff