mirror of https://github.com/Icinga/icinga2.git
Documentation: Fix some typos.
This commit is contained in:
parent
e03ffd780a
commit
051062a80d
|
@ -19,7 +19,7 @@ in case. These users must have all macro attributes defined which will be used i
|
|||
the `NotificationCommand` on execution, for example `email` as macro dictionary key
|
||||
is referenced as `$USEREMAIL$`.
|
||||
|
||||
The user `icingaadmin` in this examples will get notified only on `WARNING` and
|
||||
The user `icingaadmin` in the example below will get notified only on `WARNING` and
|
||||
`CRITICAL` states and `problem` and `recovery` notification types.
|
||||
|
||||
object User "icingaadmin" {
|
||||
|
@ -296,4 +296,4 @@ Available state and type filters for notifications are:
|
|||
>
|
||||
> If you are familiar with Icinga 1.x `notification_options` please note that they have been split
|
||||
> into type and state, and allow more fine granular filtering for example on downtimes and flapping.
|
||||
> You can filter for acknowledgements and custom notifications too.
|
||||
> You can filter for acknowledgements and custom notifications too.
|
||||
|
|
|
@ -49,7 +49,7 @@ remove the processed files.
|
|||
While there are some Graphite collector scripts for Icinga 1.x available it's
|
||||
more reasonable to directly process the check and plugin performance in memory
|
||||
in Icinga 2. Once there are new metrics available, Icinga 2 will directly
|
||||
write these to the defined Graphite Carbon daemon tcp socket.
|
||||
write them to the defined Graphite Carbon daemon tcp socket.
|
||||
|
||||
You can enable the feature using
|
||||
|
||||
|
|
|
@ -54,7 +54,7 @@ configuration.
|
|||
|
||||
Fixed downtimes require a start and end time (a duration will be ignored).
|
||||
Flexible downtimes need a start and end time for the time span, and a duration
|
||||
independant of that.
|
||||
independent from that time span.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
@ -77,7 +77,7 @@ is primarly accessible using web interfaces.
|
|||
|
||||
Adding and deleting comment actions are possible through the external command pipe
|
||||
provided with the `ExternalCommandListener` configuration. The caller must
|
||||
pass the the comment id in case of manipulating an existing comment.
|
||||
pass the comment id in case of manipulating an existing comment.
|
||||
|
||||
## Acknowledgements
|
||||
|
||||
|
@ -101,7 +101,7 @@ dashboard and no-one ever looks at it again since it will suppress
|
|||
notifications too.
|
||||
|
||||
This `fire-and-forget` action is quite common. If you're sure that a
|
||||
current problem should be resolved in the future at a defined time
|
||||
current problem should be resolved in the future at a defined time,
|
||||
you can define an expiration time when acknowledging the problem.
|
||||
|
||||
Icinga 2 will clear the acknowledgement when expired and start to
|
||||
|
@ -225,9 +225,6 @@ defines a host dependency which acts implicit as parent relation too.
|
|||
Furthermore the host may be reachable but ping samples are dropped by the
|
||||
router's firewall.
|
||||
|
||||
By defining a service dependency the `google-dns ping4` re-check will be skipped
|
||||
in case the parent service `dsl-router ping4` is in a `NOT-OK` state.
|
||||
|
||||
object Host "dsl-router" {
|
||||
services["ping4"] = {
|
||||
templates = "generic-service",
|
||||
|
|
Loading…
Reference in New Issue