## <a id="support"></a> Support
Support for Icinga 2 is available in a number of ways. Please have a look at
-the support overview page at [https://support.icinga.org].
+the support overview page at https://support.icinga.org.
## <a id="contribute"></a> Contribute
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/community/].
+Please get in touch with the Icinga team at https://www.icinga.org/community/.
## <a id="development"></a> Icinga 2 Development
* [Development Bug Tracker](https://dev.icinga.org/projects/i2): [How to report a bug?](http://www.icinga.org/faq/how-to-report-a-bug/)
* Git Repositories: [main mirror on icinga.org](https://git.icinga.org/?p=icinga2.git;a=summary) [release mirror at github.com](https://github.com/Icinga/icinga2)
-* (Git Checkins Mailinglist](https://lists.icinga.org/mailman/listinfo/icinga-checkins)
+* [Git Checkins Mailinglist](https://lists.icinga.org/mailman/listinfo/icinga-checkins)
* [Development](https://lists.icinga.org/mailman/listinfo/icinga-devel) and [Users](https://lists.icinga.org/mailman/listinfo/icinga-users) Mailinglists
* [#icinga-devel on irc.freenode.net](http://webchat.freenode.net/?channels=icinga-devel) including a Git Commit Bot
* Use [Packages](#getting-started)
-Look for available packages on [http://packages.icinga.org] or ask your distribution's maintainer.
+Look for available packages on http://packages.icinga.org or ask your distribution's maintainer.
Compiling from source is not recommended.
* Real Distributed Architecture
* Puppet modules, Chef Cookbooks, Ansible Playbooks, Salt Formulas, etc
-This is a constant work-in-progress. For details checkout [https://dev.icinga.org/projects/icinga-tools].
-If you want to contribute to these projects, do not hesitate to contact us at [https://support.icinga.org].
+This is a constant work-in-progress. For details checkout https://dev.icinga.org/projects/icinga-tools
+If you want to contribute to these projects, do not hesitate to contact us at https://support.icinga.org
* [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 colleagues.
-
-
-
## <a id="setting-up-check-plugins"></a> Setting up Check Plugins
-Without 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
Distribution | Schema Files
--------------|---------------------
- RHEL | `/usr/share/doc/icinga2-ido-mysql-*/schema` (`*` means package version).
+ 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`
Distribution | Schema Files
--------------|---------------------
- RHEL | `/usr/share/doc/icinga2-ido-pgsql-*/schema` (`*` means package version).
+ 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`
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
+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
# /usr/sbin/icinga2 -c /etc/icinga2/icinga2.conf -C
- [2014-05-22 17:07:25 +0200] <Main Thread> critical/config: Location:
+ [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(9): check_command = "ping4"
Config error: 'apply' is missing 'assign'
- [2014-05-22 17:07:25 +0200] <Main Thread> critical/config: 1 errors, 0 warnings.
+ [2014-05-22 17:07:25 +0200] critical/ConfigItem: 1 errors, 0 warnings.
Icinga 2 detected configuration errors.
* `icinga2x-cluster` setting up two virtual machines in a master/slave cluster
> **Note**
->
+>
> Please consult the `README` file for each project for further installation
-> details at [https://github.com/Icinga/icinga-vagrant]
+> details at [https://github.com/Icinga/icinga-vagrant]
Once you have checked out the Git repository navigate to your required
vagrant box and build the VM using the following command:
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.
-
+Monitoring Plugins project.
assign where service.name == "ping4"
}
-### <a id="first-notification-delay"></a> First Notification Delay
+### <a id="notification-delay"></a> Notification Delay
Sometimes the problem in question should not be notified when the notification is due
-(the object reaching the `HARD` state) but a defined time duration afterwards. In Icinga 2 you can use the `times`
-dictionary and set `begin = 15m` as key and value if you want to postpone the first notification
-for 15 minutes. Leave out the `end` key - if not set, Icinga 2 will not check against any
-end time for this notification.
+(the object reaching the `HARD` state) but a defined time duration afterwards. In Icinga 2
+you can use the `times` dictionary and set `begin = 15m` as key and value if you want to
+postpone the first notification for 15 minutes. Leave out the `end` key - if not set,
+Icinga 2 will not check against any end time for this notification.
apply Notification "mail" to Service {
import "generic-notification"
critical (`-c`) thresholds for the disk usage. Without any
partition defined (`-p`) it will check all local partitions.
-> **Note**
->
-> Don't execute plugins as `root` and always use the absolute path to the plugin! Trust us.
-
-Below is an example using runtime macros from Icinga 2 (such as `$service.output$` for
-the current check output) sending an email to the user(s) associated with the
-notification itself (`$user.email$`).
icinga@icinga2 $ /usr/lib/nagios/plugins/check_disk --help
...
This plugin checks the amount of used disk space on a mounted file system
[-t timeout] [-u unit] [-v] [-X type] [-N type]
...
+> **Note**
+>
+> Don't execute plugins as `root` and always use the absolute path to the plugin! Trust us.
+
Next step is to understand how command parameters are being passed from
a host or service object, and add a `CheckCommand` definition based on these
required parameters and/or default values.
defined in the service using the check command `my-disk`. The custom attributes
can also be inherited from a parent template using additive inheritance (`+=`).
-
+
object CheckCommand "my-disk" {
import "plugin-check-command"
-
+
command = PluginDir + "/check_disk"
-
+
arguments = {
"-w" = "$disk_wfree$%"
"-c" = "$disk_cfree$%"
}
-
+
vars.disk_wfree = 20
vars.disk_cfree = 10
}
/* this one listens on a different ssh port */
object Host "my-host2" {
- import "generic-host"
+ import "generic-host"
address = "129.168.2.50"
vars.os = "Linux"
vars.custom_ssh_port = 2222
)
/usr/bin/printf "%b" $template | mail -s "$NOTIFICATIONTYPE - $HOSTDISPLAYNAME - $SERVICEDISPLAYNAME is $SERVICESTATE" $USEREMAIL
-
+
> **Note**
>
> This example is for `exim` only. Requires changes for `sendmail` and
assign where host.address
}
+ apply Dependency "internet" to Host {
+ parent_host_name = "dsl-router"
+ disable_checks = true
+ disable_notifications = true
+
+ assign where host.name != "dsl-router"
+ }
+
apply Dependency "internet" to Service {
parent_host_name = "dsl-router"
+ parent_service_name = "ping4"
disable_checks = true
assign where host.name != "dsl-router"
}
+
### <a id="dependencies-agent-checks"></a> Dependencies for Agent Checks
Another classic example are agent based checks. You would define a health check
(e.g. in other configuration attributes).
Here is an example of a command definition which uses user-defined custom attributes:
-
+
object CheckCommand "my-ping" {
import "plugin-check-command"
command = [
PluginDir + "/check_mysql"
]
-
+
arguments = {
"-H" = "$mysql_address$"
"-d" = "$mysql_database$"
WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
AND i.instance_name='default'";
- status_update_time
+ status_update_time
------------------------
2014-05-29 15:11:38+02
(1 Zeile)
#### <a id="addons-graphing-pnp"></a> PNP
-PNP (http://www.pnp4nagios.org) must be configured using the "bulk mode with npcd and npcdmod"
+[PNP](http://www.pnp4nagios.org) must be configured using the "bulk mode with npcd and npcdmod"
hence Icinga 2's [PerfdataWriter](#performance-data) acts as npcdmod. NPCD will collect
the rotated performance data files.
#### <a id="addons-graphing-pnp"></a> inGraph
-inGraph (https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
+[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-visualization-nagvis"></a> NagVis
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).
+based on your monitoring configuration and status data using [NagVis](http://www.nagvis.org).
### <a id="addons-web-interfaces"></a> Web Interfaces
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
+* [Thruk](http://www.thruk.org) based on the [Livestatus](#livestatus) feature
## <a id="plugins"></a> Plugins
-You can find plugins (additional to the ones at [Monitoring Plugins](https://www.monitoring-plugins.org)) over at
+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="configuration-migration"></a> Configuration Migration
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
+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
A standalone configuration migration script is available at
-[https://github.com/Icinga/icinga2-migration]. All further
+https://github.com/Icinga/icinga2-migration. All further
details on the command line parameters are documented there too.
This script will be merged back upstream into the Icinga Web 2 CLI once there
especially if you want to preserve your existing file layout, or any other
object specific policies.
-If you encounter a bug, please open an issue at [https://dev.icinga.org].
+If you encounter a bug, please open an issue at https://dev.icinga.org
### <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 proposed Icinga 2 configuration paradigm.
-Please read the [next chapter](#differences-1x-2) to find out more about the differences
+Please read the [next chapter](#differences-1x-2) to find out more about the differences
between 1.x and 2.
### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
vars.crta = 500
vars.cpl = 60
}
-
+
> **Note**
>
> For better maintainability you should consider using [command arguments](#command-arguments)
Icinga 2 implements a new built-in [distributed monitoring architecture](#distributed-monitoring-high-availability),
including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
High Availability and load balancing are also part of the Icinga 2 Cluster setup.
-
-
projects / icinga2 / commitdiff