mirror of https://github.com/Icinga/icinga2.git
Documentation: Fix typos.
Fixes #5692 Signed-off-by: Michael Friedrich <michael.friedrich@netways.de>
This commit is contained in:
Wolfgang Nieder
Michael Friedrich
parent
d98b61bba2
commit
5e5c9285c9
|
|
@ -71,7 +71,7 @@ objects supporting new attributes: `disable_checks`, 'disable_notifications`, `s
|
|||
|
||||
#### Changes
|
||||
* Generated object names (host with services array) use an exclamation mark instead of a colon
|
||||
as seperator. State file objects with downtimes, comments, etc are invalid (unknown) for that
|
||||
as separator. State file objects with downtimes, comments, etc are invalid (unknown) for that
|
||||
reason.
|
||||
* Script variables are set using 'var' and 'const' instead of the previous 'set' identifier
|
||||
* ITL constants are now embedded in libicinga
|
||||
|
|
@ -108,7 +108,7 @@ reason.
|
|||
* `IdoMysqlConnection` for Icinga 1.x Reporting, NagVis
|
||||
* `LivestatusListener` for addons using the livestatus interface (history tables tbd)
|
||||
* `PerfDataWriter` for graphing addons such as PNP/inGraph/graphite (can be loaded multiple times!)
|
||||
* `GraphiteWriter` for sending metrics to directly to graphite carbon sockets
|
||||
* `GraphiteWriter` for sending metrics directly to graphite carbon sockets
|
||||
* `CheckResultReader` to collect Icinga 1.x slave checkresults (migrate your distributed setup step-by-step)
|
||||
* `ClusterListener` for real distributed architecture including config and runtime data (checks, comments, downtimes) sync and replay
|
||||
* `SyslogLogger`, `FileLogger` and `ConsoleLogger` for different types of logging
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ operating system and distribution you are running.
|
|||
|
||||
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 favorite distribution.
|
||||
are available for your favourite distribution.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -27,8 +27,10 @@ Depending on which directory your plugins are installed into you may need to
|
|||
update the `plugindir` macro in your Icinga 2 configuration. This macro is used
|
||||
by the service templates contained in the Icinga Template Library to determine
|
||||
where to find the plugin binaries.
|
||||
Alternatively you can create a symbolic link pointing to the installation path
|
||||
of the plugins.
|
||||
|
||||
### <a id="integrate-additional-plugins"></a> Integrate Additonal Plugins
|
||||
### <a id="integrate-additional-plugins"></a> Integrate Additional Plugins
|
||||
|
||||
You may require a custom check plugin not provided by the official Nagios plugins.
|
||||
All existing Nagios or Icinga 1.x plugins found on public community websites
|
||||
|
|
@ -37,10 +39,10 @@ will work with Icinga 2 as well.
|
|||
* [MonitoringExchange](https://www.monitoringexchange.org)
|
||||
* [Icinga Wiki](https://wiki.icinga.org)
|
||||
|
||||
Once you have downloaded the plugin copy them into the directory defined by the global
|
||||
Once you have downloaded the plugin copy it into the directory defined by the global
|
||||
`IcingaMacro` `$plugindir$` and make sure that the user the Icinga daemon is running as
|
||||
can execute the the plugin binary. Plugins should provide the `--help` parameter
|
||||
providing details how they must get called in your command definition later on.
|
||||
can execute the the plugin binary. Plugins should support the `--help` parameter
|
||||
providing details how they have to be called in your command definition later on.
|
||||
|
||||
# cp check_snmp_int.pl /usr/local/icinga/libexec/
|
||||
# chmod +x /usr/local/icinga/libexec/check_snmp_int.pl
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
## <a id="configuring-ido"></a> Configuring IDO
|
||||
|
||||
The IDO (Icinga Data Output) modules for Icinga 2 takes care of exporting all
|
||||
The IDO (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.
|
||||
|
||||
|
|
@ -73,7 +73,7 @@ schema version first:
|
|||
+---------+
|
||||
|
||||
Check the `schema/upgrade` directory for an incremental schema upgrade file, e.g.
|
||||
if your database schema version is `1.10.0` look for `mysql-upgrade-1.12.0.sql`
|
||||
if your database schema version is `1.11.0` look for `mysql-upgrade-1.12.0.sql`
|
||||
and newer. If there isn't an upgrade file available there's nothing to do.
|
||||
|
||||
> **Note**
|
||||
|
|
@ -127,7 +127,7 @@ setting up a PostgreSQL database for Icinga 2:
|
|||
# sudo -u postgres createlang plpgsql icinga
|
||||
|
||||
Locate your pg_hba.conf (Debian: `/etc/postgresql/*/main/pg_hba.conf`,
|
||||
RHEL/SUSE: `/var/lib/pgsql/data/pg_hba.conf`), add the icinga user with md5
|
||||
RHEL/SUSE: `/var/lib/pgsql/data/pg_hba.conf`), add the icinga user with md5
|
||||
authentification method and restart the postgresql server.
|
||||
|
||||
# vim /var/lib/pgsql/data/pg_hba.conf
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## <a id=setting-up-livestatus""></a> Setting up Livestatus
|
||||
## <a id="setting-up-livestatus"></a> Setting up Livestatus
|
||||
|
||||
The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
|
||||
implements a query protocol that lets users query their Icinga instance for
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ Verify that your Icinga 1.x Web works by browsing to your Web installation URL:
|
|||
|
||||
### <a id="setting-up-icingaweb2"></a> Setting up Icinga Web 2
|
||||
|
||||
Icinga Web 2 currently supports `status.dat`, `DB IDO` or `Livestatus` as backends.
|
||||
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.
|
||||
|
||||
|
|
@ -134,5 +134,5 @@ There are many addons in the wild which are using Icinga 1.x backends and
|
|||
are well integrated into user interfaces.
|
||||
|
||||
The most famous ones are PNP or inGraph (graphing performance data), graphite, NagVis
|
||||
(network maps), etc
|
||||
(network maps), etc.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ can be virtually anything which can be checked in some way:
|
|||
* Temperature Sensors
|
||||
* Other local or network-accessible services
|
||||
|
||||
Host objects provide a mechanism to group together services that are running
|
||||
Host objects provide a mechanism to group services that are running
|
||||
on the same physical device.
|
||||
|
||||
Here is an example of a host object which defines two child services:
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ partition defined (`-p`) it will check all local partitions.
|
|||
|
||||
Define the default check command macros `wfree` and `cfree` (freely
|
||||
definable naming schema) and their default threshold values. You can
|
||||
then use these macros in the command line.
|
||||
then use these macros on the command line.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
|
@ -173,8 +173,8 @@ and `$SERVICESTATE$` will be processed by Icinga 2 helping on fine-granular
|
|||
events being triggered.
|
||||
|
||||
Common use case scenarios are a failing HTTP check requiring an immediate
|
||||
restart via event command, or a an application is locked and requires
|
||||
a restart on detection.
|
||||
restart via event command, or if an application is locked and requires
|
||||
a restart upon detection.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ where <name> is the name of the custom variable.
|
|||
|
||||
### <a id="user-runtime-macros"></a> User Runtime Macros
|
||||
|
||||
The following service macros are available in all commands that are executed for
|
||||
The following macros are available in all commands that are executed for
|
||||
users:
|
||||
|
||||
Name | Description
|
||||
|
|
@ -277,3 +277,4 @@ Example:
|
|||
}
|
||||
|
||||
More details in the chapter [Constant Expressions](#constant-expressions).
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ and `$SERVICESTATE$` will be processed by Icinga 2 helping on fine-granular
|
|||
events being triggered.
|
||||
|
||||
Common use case scenarios are a failing HTTP check requiring an immediate
|
||||
restart via event command, or a an application is locked and requires
|
||||
a restart on detection.
|
||||
restart via event command, or if an application is locked and requires
|
||||
a restart upon detection.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ syslog with severity `information`.
|
|||
}
|
||||
|
||||
For debugging purposes you can install a `FileLogger` object
|
||||
and forward the `debug` serverity into an Icinga 2 debug file.
|
||||
and forward the `debug` severity into an Icinga 2 debug file.
|
||||
|
||||
object FileLogger "debug-file" {
|
||||
severity = "debug",
|
||||
|
|
|
|||
|
|
@ -16,5 +16,5 @@ Icinga 1.x Classic UI requires this data set as part of its backend.
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> Semi-colons in the check result output are replaced with colons because
|
||||
> Semicolons in the check result output are replaced with colons because
|
||||
> they are used as attribute separators.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
The Icinga 1.x log format is considered being the `Compat Log`
|
||||
in Icinga 2 provided with the `CompatLogger` object.
|
||||
|
||||
These logs are not only used for informal representation in
|
||||
These logs are not only used for informational representation in
|
||||
external web interfaces parsing the logs, but also to generate
|
||||
sla reports and trends in Icinga 1.x Classic UI. Futhermore the
|
||||
`Livestatus` feature uses these logs for answering queries to
|
||||
|
|
@ -46,5 +46,5 @@ existing log parsers.
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> Semi-colons in the check result output are replaced with colons because
|
||||
> Semicolons in the check result output are replaced with colons because
|
||||
> they are used as attribute separators.
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ nrpe.cfg:
|
|||
#### NSClient++
|
||||
|
||||
[NSClient++](http://nsclient.org) works on both Windows and Linux platforms and is well
|
||||
known for its magnificant Windows support. There are alternatives like the WMI interface,
|
||||
known for its magnificent Windows support. There are alternatives like the WMI interface,
|
||||
but using `NSClient++` will allow you to run local scripts similar to check plugins fetching
|
||||
the required output and performance counters.
|
||||
|
||||
|
|
@ -157,6 +157,10 @@ Example:
|
|||
|
||||
For details on the `NSClient++` configuration please refer to the [official documentation](http://www.nsclient.org/nscp/wiki/doc/configuration/0.4.x).
|
||||
|
||||
> ** Note **
|
||||
>
|
||||
> The format of the `NSClient++` configuration file has changed from 0.3.x to 0.4!
|
||||
|
||||
|
||||
#### Icinga 2 Agent
|
||||
|
||||
|
|
@ -191,4 +195,3 @@ SNMP Traps can be received and filtered by using [SNMPTT](http://snmptt.sourcefo
|
|||
passing the check results to Icinga 2.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Example.
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> Unlike in ordinary strings special characters to not have to be escaped
|
||||
> Unlike in ordinary strings special characters do not have to be escaped
|
||||
> in multi-line string literals.
|
||||
|
||||
#### <a id="boolean-literals"></a> Boolean Literals
|
||||
|
|
@ -265,7 +265,7 @@ templates though in general they are.
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> The final macros dictionary contains all 3 macros and the macro
|
||||
> The final macros dictionary contains all three macros and the macro
|
||||
> `color` has the value `"blue"`.
|
||||
|
||||
Parent objects are resolved in the order they're specified using the
|
||||
|
|
@ -291,7 +291,7 @@ override its value by setting it explicitely to `null`.
|
|||
|
||||
|
||||
The same method applies for disabling services defined in the inline `services`
|
||||
dictionary by exiplicitely overriding their value with `null`.
|
||||
dictionary by explicitly overriding their value with `null`.
|
||||
|
||||
services["ping6"] = null
|
||||
|
||||
|
|
@ -302,7 +302,7 @@ Global constants can be set using the `const` keyword:
|
|||
|
||||
const VarName = "some value"
|
||||
|
||||
The value can be a string, number, array or a dictionary.
|
||||
The value can be a string, number, array, or a dictionary.
|
||||
|
||||
Constants cannot be changed once they are set.
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ by Icinga 2.
|
|||
> **Best Practice**
|
||||
>
|
||||
> Rather than creating a `Service` object for a specific host it is usually easier
|
||||
> to just create a `Service` template and using the `services` attribute in the `Host`
|
||||
> to just create a `Service` template and use the `services` attribute in the `Host`
|
||||
> object to associate these templates with a host.
|
||||
|
||||
Example:
|
||||
|
|
@ -144,7 +144,7 @@ of service state changes and other events.
|
|||
> **Best Practice**
|
||||
>
|
||||
> Rather than creating a `Notification` object for a specific service it is usually easier
|
||||
> to just create a `Notification` template and using the `notifications` attribute in the `Service`
|
||||
> to just create a `Notification` template and use the `notifications` attribute in the `Service`
|
||||
> object to associate these templates with a service.
|
||||
|
||||
Example:
|
||||
|
|
@ -356,7 +356,7 @@ ScheduledDowntime objects can be used to set up recurring downtimes for services
|
|||
> **Best Practice**
|
||||
>
|
||||
> Rather than creating a `ScheduledDowntime` object for a specific service it is usually easier
|
||||
> to just create a `ScheduledDowntime` template and using the `scheduled_downtimes` attribute in the `Service`
|
||||
> to just create a `ScheduledDowntime` template and use the `scheduled_downtimes` attribute in the `Service`
|
||||
> object to associate these templates with a service.
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Well known configuration tools for Icinga 1.x such as [LConf](http://www.netways
|
|||
[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 favorite configuration tool to export Icinga 2 configuration, please get in
|
||||
your favourite configuration tool to export Icinga 2 configuration, please get in
|
||||
touch with their developers.
|
||||
|
||||
If you're looking for puppet manifests, chef cookbooks, ansible recipes, etc - we're happy
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Example:
|
|||
|
||||
include_recursive "conf.d" "*.conf"
|
||||
|
||||
Below `conf.d` you're free to choose. An Example based on host objects with
|
||||
Below `conf.d` you're free to choose. An example based on host objects with
|
||||
inline services in `conf.d/hosts` and their templates below `conf.d/services/`
|
||||
would be:
|
||||
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ Name | Description
|
|||
----------------|--------------
|
||||
plugindir | **Required.** The directory containing this plugin.
|
||||
wgreater | **Optional.** The user count warning threshold. Defaults to 20.
|
||||
cgreater | **Optional.** The user count warning threshold. Defaults to 50.
|
||||
cgreater | **Optional.** The user count critical threshold. Defaults to 50.
|
||||
|
||||
### <a id="itl-processes"></a> processes
|
||||
|
||||
|
|
@ -217,7 +217,7 @@ Name | Description
|
|||
----------------|--------------
|
||||
plugindir | **Required.** The directory containing this plugin.
|
||||
wgreater | **Optional.** The process count warning threshold. Defaults to 250.
|
||||
cgreater | **Optional.** The process count warning threshold. Defaults to 400.
|
||||
cgreater | **Optional.** The process count critical threshold. Defaults to 400.
|
||||
|
||||
### <a id="itl-load"></a> load
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ tools calculating the SLAs based on the state and downtime history.
|
|||
> **Note**
|
||||
>
|
||||
> Downtimes may overlap with their start and end times. If there
|
||||
> are multiple downtimes triggered, the overall downtime depth
|
||||
> are multiple downtimes triggered for one object, the overall downtime depth
|
||||
> will be more than `1`. This is useful when you want to extend
|
||||
> your maintenance window taking longer than expected.
|
||||
|
||||
|
|
@ -33,8 +33,8 @@ schedule a `fixed` downtime starting at 23:00 and ending at 24:00.
|
|||
|
||||
Unlike a `fixed` downtime, a `flexible` downtime end does not necessarily
|
||||
happen at the provided end time. Instead the downtime will be triggered
|
||||
in the time span defined by start and end time, but then last a defined
|
||||
duration in minutes.
|
||||
by the state change in the time span defined by start and end time, but
|
||||
then last a defined duration in minutes.
|
||||
|
||||
Imagine the following scenario: Your service is frequently polled
|
||||
by users trying to grab free deleted domains for immediate registration.
|
||||
|
|
@ -225,7 +225,7 @@ a three node cluster consisting of
|
|||
* node-3
|
||||
|
||||
and `node-3` is only reachable from `node-2`, you have to consider this in your
|
||||
peer configuration
|
||||
peer configuration.
|
||||
|
||||
### <a id="configure-cluster-endpoints"></a> Configure Cluster Endpoints
|
||||
|
||||
|
|
@ -383,7 +383,7 @@ defined or as inline definition as `dependencies` dictionary. The `parent_host`
|
|||
attributes are mandatory, `child_host` and `child_service` attributes are obsolete within
|
||||
inline definitions in an existing service object or service inline definition.
|
||||
|
||||
A service can depend on a host, and vice versa. A service has an implicit dependeny (parent)
|
||||
A service can depend on a host, and vice versa. A service has an implicit dependency (parent)
|
||||
to its host. A host to host dependency acts implicit as host parent relation.
|
||||
|
||||
A common scenario is the Icinga 2 server behind a router. Checking internet
|
||||
|
|
@ -451,7 +451,7 @@ configuration attribute named `flapping_threshold`.
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> Flapping must be explicitely enabled seting the `Service` object attribute
|
||||
> Flapping must be explicitely enabled setting the `Service` object attribute
|
||||
> `enable_flapping = 1`.
|
||||
|
||||
## <a id="volatile-services"></a> Volatile Services
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## <a id="configuration-migration"></a> Configuration Migration
|
||||
|
||||
The Icinga 2 configuration format introduces plenty of behavioral changes. In
|
||||
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.
|
||||
|
||||
|
|
@ -34,4 +34,4 @@ possible.
|
|||
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 chapter](#differences-1x-2) to get an idea about the differences between 1.x and 2.
|
||||
Please read the [next chapter](#differences-1x-2) to get an idea about the differences between 1.x and 2.
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ account by Icinga 1.x Classic UI and Web.
|
|||
### <a id="differences-1x-2-action-url-notes-url-notes"></a> Action Url, Notes Url, Notes
|
||||
|
||||
Icinga 1.x objects support configuration attributes not required as runtime
|
||||
values but for external ressources such as Icinga 1.x Classic UI or Web.
|
||||
values but for external resources such as Icinga 1.x Classic UI or Web.
|
||||
The `notes`, `notes_url`, `action_url`, `icon_image`, `icon_image_alt`
|
||||
attributes for host and service objects, additionally `statusmap_image` and
|
||||
`2d_coords` for the host's representation in status maps.
|
||||
|
|
|
|||
Loading…
Reference in New Issue