mirror of https://github.com/Icinga/icinga2.git
Documentation: fix url formatting, dependency example
This commit is contained in:
Michael Friedrich
parent
d2a239f78e
commit
ef2ffd8534
|
|
@ -17,7 +17,7 @@ LICENSE file included in the source package.
|
|||
## <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
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ There are many ways to contribute to Icinga - whether it be sending patches, tes
|
|||
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
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ out these resources:
|
|||
|
||||
* [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
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ Please check the `ChangeLog` file.
|
|||
|
||||
* 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
|
||||
|
|
@ -169,13 +169,10 @@ edit your configuration.
|
|||
|
||||
* 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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -364,7 +364,7 @@ Further details on the monitoring configuration can be found in the
|
|||
|
||||
## <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
|
||||
|
|
@ -485,7 +485,7 @@ The schema file location differs by the distribution used:
|
|||
|
||||
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`
|
||||
|
||||
|
|
@ -566,7 +566,7 @@ The schema file location differs by the distribution used:
|
|||
|
||||
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`
|
||||
|
||||
|
|
@ -643,7 +643,7 @@ Change "www-data" to the user you're using to run queries.
|
|||
|
||||
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
|
||||
|
|
@ -988,7 +988,7 @@ or manually passing the `-C` argument:
|
|||
|
||||
# /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" {
|
||||
|
|
@ -997,7 +997,7 @@ or manually passing the `-C` argument:
|
|||
/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.
|
||||
|
||||
|
||||
|
|
@ -1035,9 +1035,9 @@ For Icinga 2 there are currently two scenarios available:
|
|||
* `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:
|
||||
|
|
@ -1047,5 +1047,4 @@ 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.
|
||||
|
|
|
|||
|
|
@ -477,13 +477,13 @@ notified, but only for one hour (`2h` as `end` key for the `times` dictionary).
|
|||
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"
|
||||
|
|
@ -631,13 +631,6 @@ all available options. Our example defines warning (`-w`) and
|
|||
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
|
||||
|
|
@ -650,6 +643,10 @@ notification itself (`$user.email$`).
|
|||
[-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.
|
||||
|
|
@ -668,17 +665,17 @@ The default custom attributes can be overridden by the custom attributes
|
|||
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
|
||||
}
|
||||
|
|
@ -767,7 +764,7 @@ the `my-host2` host requires a different port on 2222. Both hosts are in the hos
|
|||
|
||||
/* 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
|
||||
|
|
@ -879,7 +876,7 @@ as environment variables and can be used in the notification script:
|
|||
)
|
||||
|
||||
/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
|
||||
|
|
@ -968,13 +965,23 @@ be suppressed. This is achieved by setting the `disable_checks` attribute to `tr
|
|||
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
|
||||
|
|
@ -1173,7 +1180,7 @@ runtime when executing a command. These custom attributes cannot be used elsewhe
|
|||
(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"
|
||||
|
||||
|
|
@ -1252,7 +1259,7 @@ when passing credentials to database checks:
|
|||
command = [
|
||||
PluginDir + "/check_mysql"
|
||||
]
|
||||
|
||||
|
||||
arguments = {
|
||||
"-H" = "$mysql_address$"
|
||||
"-d" = "$mysql_database$"
|
||||
|
|
@ -1789,7 +1796,7 @@ Example for PostgreSQL:
|
|||
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)
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@
|
|||
|
||||
#### <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.
|
||||
|
||||
|
|
@ -31,19 +31,19 @@ By enabling the DB IDO feature you can use the Icinga Reporting package.
|
|||
#### <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
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
## <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
|
||||
|
|
@ -20,14 +20,14 @@ Some specific migration steps will be still required to be done manually,
|
|||
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
|
||||
|
|
@ -989,7 +989,7 @@ With the freely definable custom attributes in Icinga 2 it looks like this:
|
|||
vars.crta = 500
|
||||
vars.cpl = 60
|
||||
}
|
||||
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> For better maintainability you should consider using [command arguments](#command-arguments)
|
||||
|
|
@ -1473,5 +1473,3 @@ and configuration distribution problems Icinga 1.x distributed monitoring curren
|
|||
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.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue