mirror of
https://github.com/Icinga/icinga2.git
synced 2025-07-24 14:14:45 +02:00
docs: Fix various misspellings
This commit is contained in:
parent
730a51ccb0
commit
3a031a1f55
@ -766,7 +766,7 @@ apply Notification "mail-icingaadmin" to Host {
|
||||
|
||||
A more advanced example is to use [apply rules with for loops on arrays or
|
||||
dictionaries](03-monitoring-basics.md#using-apply-for) provided by
|
||||
[custom atttributes](03-monitoring-basics.md#custom-variables) or groups.
|
||||
[custom attributes](03-monitoring-basics.md#custom-variables) or groups.
|
||||
|
||||
Remember the examples shown for [custom variable values](03-monitoring-basics.md#custom-variables-values):
|
||||
|
||||
@ -3172,16 +3172,16 @@ i.e. to consider the parent unreachable only if no dependency is fulfilled.
|
||||
Think of a host connected to both a network and a storage switch vs. a host connected to redundant routers.
|
||||
|
||||
Sometimes you even want a mixture of both.
|
||||
Think of a service like SSH depeding on both LDAP and DNS to function,
|
||||
Think of a service like SSH depending on both LDAP and DNS to function,
|
||||
while operating redundant LDAP servers as well as redundant DNS resolvers.
|
||||
|
||||
Before v2.12, Icinga regarded all dependecies as cumulative.
|
||||
Before v2.12, Icinga regarded all dependencies as cumulative.
|
||||
In v2.12 and v2.13, Icinga regarded all dependencies redundant.
|
||||
The latter led to unrelated services being inadvertantly regarded to be redundant to each other.
|
||||
The latter led to unrelated services being inadvertently regarded to be redundant to each other.
|
||||
|
||||
v2.14 restored the former behavior and allowed to override it.
|
||||
I.e. all dependecies are regarded as essential for the parent by default.
|
||||
Specifying the `redundancy_group` attribute for two dependecies of a child object with the equal value
|
||||
I.e. all dependencies are regarded as essential for the parent by default.
|
||||
Specifying the `redundancy_group` attribute for two dependencies of a child object with the equal value
|
||||
causes them to be regarded as redundant (only inside that redundancy group).
|
||||
|
||||
<!-- Keep this for compatibility -->
|
||||
|
@ -326,7 +326,7 @@ object CheckCommand "systemd" { // Plugin name without 'check_' prefix
|
||||
Run a config validation to see if that works, `icinga2 daemon -C`
|
||||
|
||||
Next, analyse the plugin parameters. Plugins with a good help output show
|
||||
optional parameters in square brackes. This is the case for all parameters
|
||||
optional parameters in square brackets. This is the case for all parameters
|
||||
for this plugin. If there are required parameters, use the `required` key
|
||||
inside the argument.
|
||||
|
||||
@ -689,7 +689,7 @@ liters (l) | ml, l, hl
|
||||
|
||||
The UoM "c" represents a continuous counter (e.g. interface traffic counters).
|
||||
|
||||
Unknown UoMs are discarted (as if none was given).
|
||||
Unknown UoMs are discarded (as if none was given).
|
||||
A value without any UoM may be an integer or floating point number
|
||||
for any type (processes, users, etc.).
|
||||
|
||||
|
@ -2205,7 +2205,7 @@ object Zone "icinga2-agent2.localdomain" {
|
||||
The two agent nodes do not need to know about each other. The only important thing
|
||||
is that they know about the parent zone (the satellite) and their endpoint members (and optionally the global zone).
|
||||
|
||||
> **Tipp**
|
||||
> **Tip**
|
||||
>
|
||||
> In the example above we've specified the `host` attribute in the agent endpoint configuration. In this mode,
|
||||
> the satellites actively connect to the agents. This costs some resources on the satellite -- if you prefer to
|
||||
|
@ -1134,7 +1134,7 @@ for a more secure configuration is provided by the [Mozilla Wiki](https://wiki.m
|
||||
Ensure to use the same configuration for both attributes on **all** endpoints to avoid communication problems which
|
||||
requires to use `cipher_list` compatible with the endpoint using the oldest version of the OpenSSL library. If using
|
||||
other tools to connect to the API ensure also compatibility with them as this setting affects not only inter-cluster
|
||||
communcation but also the REST API.
|
||||
communication but also the REST API.
|
||||
|
||||
### CheckerComponent <a id="objecttype-checkercomponent"></a>
|
||||
|
||||
|
@ -1317,7 +1317,7 @@ Custom variables passed as [command parameters](03-monitoring-basics.md#command-
|
||||
Name | Description
|
||||
--- | ---
|
||||
rpc_address | **Optional.** The rpc host address. Defaults to "$address$ if the host `address` attribute is set, "$address6$" otherwise.
|
||||
rpc_command | **Required.** The programm name (or number).
|
||||
rpc_command | **Required.** The program name (or number).
|
||||
rpc_port | **Optional.** The port that should be checked.
|
||||
rpc_version | **Optional.** The version you want to check for (one or more).
|
||||
rpc_udp | **Optional.** Use UDP test. Defaults to false.
|
||||
@ -2323,7 +2323,7 @@ snmp_storage_type | **Optional.** Filter by storage type. Valid options ar
|
||||
snmp_perf | **Optional.** Enable perfdata values. Defaults to true.
|
||||
snmp_exclude | **Optional.** Select all storages except the one(s) selected by -m. No action on storage type selection.
|
||||
snmp_timeout | **Optional.** The command timeout in seconds. Defaults to 5 seconds.
|
||||
snmp_storage_olength | **Optional.** Max-size of the SNMP message, usefull in case of Too Long responses.
|
||||
snmp_storage_olength | **Optional.** Max-size of the SNMP message, useful in case of Too Long responses.
|
||||
|
||||
### snmp-interface <a id="plugin-check-command-snmp-interface"></a>
|
||||
|
||||
@ -3170,7 +3170,7 @@ specified patterns in log files.
|
||||
|
||||
Name | Description
|
||||
----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
logfiles_tag | **Optional.** A short unique descriptor for this search. It will appear in the output of the plugin and is used to separare the different services.
|
||||
logfiles_tag | **Optional.** A short unique descriptor for this search. It will appear in the output of the plugin and is used to separate the different services.
|
||||
logfiles_logfile | **Optional.** This is the name of the log file you want to scan.
|
||||
logfiles_rotation | **Optional.** This is the method how log files are rotated. One of the predefined methods or a regular expression, which helps identify the rotated archives. If this key is missing, check_logfiles assumes that the log file will be simply overwritten instead of rotated.
|
||||
logfiles_critical_pattern | **Optional.** A regular expression which will trigger a critical error.
|
||||
@ -3954,7 +3954,7 @@ vmware_isregexp | **Optional.** Treat blacklist and whitelist expr
|
||||
vmware_dc_volume_used | **Optional.** Output used space instead of free. Defaults to "true".
|
||||
vmware_warn | **Optional.** The warning threshold for volumes. Defaults to "80%".
|
||||
vmware_crit | **Optional.** The critical threshold for volumes. Defaults to "90%".
|
||||
vmware_maintenance_mode_state | **Optional.** Set status in case ESX host is in maintenace mode. Possible Values are: ok or OK, CRITICAL or critical or CRIT or crit, WARNING or warning or WARN or warn. Default is UNKNOWN because you do not know the real state. Values are case insensitive.
|
||||
vmware_maintenance_mode_state | **Optional.** Set status in case ESX host is in maintenance mode. Possible Values are: ok or OK, CRITICAL or critical or CRIT or crit, WARNING or warning or WARN or warn. Default is UNKNOWN because you do not know the real state. Values are case insensitive.
|
||||
|
||||
|
||||
**vmware-esx-dc-runtime-info**
|
||||
|
@ -498,7 +498,7 @@ The example below is not valid:
|
||||
-d '{ "type": "Host", "filter": ""linux-servers" in host.groups" }'
|
||||
```
|
||||
|
||||
The double quotes need to be escaped with a preceeding backslash:
|
||||
The double quotes need to be escaped with a preceding backslash:
|
||||
|
||||
```
|
||||
-d '{ "type": "Host", "filter": "\"linux-servers\" in host.groups" }'
|
||||
@ -1073,7 +1073,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/process-check-result`.
|
||||
exit\_status | Number | **Required.** For services: 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN, for hosts: 0=UP, 1=DOWN.
|
||||
plugin\_output | String | **Required.** One or more lines of the plugin main output. Does **not** contain the performance data.
|
||||
performance\_data | Array<code>|</code>String | **Optional.** The performance data as array of strings. The raw performance data string can be used too.
|
||||
check\_command | Array<code>|</code>String | **Optional.** The first entry should be the check commands path, then one entry for each command line option followed by an entry for each of its argument. Alternativly a single string can be used.
|
||||
check\_command | Array<code>|</code>String | **Optional.** The first entry should be the check commands path, then one entry for each command line option followed by an entry for each of its argument. Alternatively a single string can be used.
|
||||
check\_source | String | **Optional.** Usually the name of the `command_endpoint`
|
||||
execution\_start | Timestamp | **Optional.** The timestamp where a script/process started its execution.
|
||||
execution\_end | Timestamp | **Optional.** The timestamp where a script/process ended its execution. This timestamp is used in features to determine e.g. the metric timestamp.
|
||||
@ -2019,7 +2019,7 @@ validate the configuration asynchronously and populate a status log which
|
||||
can be fetched in a separated request. Once the validation succeeds,
|
||||
a reload is triggered by default.
|
||||
|
||||
This functionality was primarly developed for the [Icinga Director](https://icinga.com/docs/director/latest/)
|
||||
This functionality was primarily developed for the [Icinga Director](https://icinga.com/docs/director/latest/)
|
||||
but can be used with your own deployments too. It also solves the problem
|
||||
with certain runtime objects (zones, endpoints) and can be used to
|
||||
deploy global templates in [global cluster zones](06-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync).
|
||||
|
@ -246,7 +246,7 @@ resolved, it will be dropped and not sent to the target host.
|
||||
|
||||
Backslashes are allowed in tag keys, tag values and field keys, however they are also
|
||||
escape characters when followed by a space or comma, but cannot be escaped themselves.
|
||||
As a result all trailling slashes in these fields are replaced with an underscore. This
|
||||
As a result all trailing slashes in these fields are replaced with an underscore. This
|
||||
predominantly affects Windows paths e.g. `C:\` becomes `C:_`.
|
||||
|
||||
The database/bucket is assumed to exist so this object will make no attempt to create it currently.
|
||||
@ -396,7 +396,7 @@ check_result.perfdata.<perfdata-label>.warn
|
||||
check_result.perfdata.<perfdata-label>.crit
|
||||
```
|
||||
|
||||
Additionaly it is possible to configure custom tags that are applied to the metrics via `host_tags_template` or `service_tags_template`.
|
||||
Additionally it is possible to configure custom tags that are applied to the metrics via `host_tags_template` or `service_tags_template`.
|
||||
Depending on whether the write event was triggered on a service or host object, additional tags are added to the ElasticSearch entries.
|
||||
|
||||
A host metrics entry configured with the following `host_tags_template`:
|
||||
@ -574,7 +574,7 @@ with the following tags
|
||||
Functionality exists to modify the built in OpenTSDB metric names that the plugin
|
||||
writes to. By default this is `icinga.host` and `icinga.service.<servicename>`.
|
||||
|
||||
These prefixes can be modified as necessary to any arbitary string. The prefix
|
||||
These prefixes can be modified as necessary to any arbitrary string. The prefix
|
||||
configuration also supports Icinga macros, so if you rather use `<checkcommand>`
|
||||
or any other variable instead of `<servicename>` you may do so.
|
||||
|
||||
|
@ -42,7 +42,7 @@ is also key to identify bottlenecks and issues.
|
||||
>
|
||||
> [Monitor Icinga 2](08-advanced-topics.md#monitoring-icinga) and use the hints for further analysis.
|
||||
|
||||
* Analyze the system's performance and dentify bottlenecks and issues.
|
||||
* Analyze the system's performance and identify bottlenecks and issues.
|
||||
* Collect details about all applications (e.g. Icinga 2, MySQL, Apache, Graphite, Elastic, etc.).
|
||||
* If data is exchanged via network (e.g. central MySQL cluster) ensure to monitor the bandwidth capabilities too.
|
||||
* Add graphs from Grafana or Graphite as screenshots to your issue description
|
||||
|
@ -128,7 +128,7 @@ have been removed from the command and documentation.
|
||||
### Bugfixes for 2.11 <a id="upgrading-to-2-11-bugfixes"></a>
|
||||
|
||||
2.11.1 on agents/satellites fixes a problem where 2.10.x as config master would send out an unwanted config marker file,
|
||||
thus rendering the agent to think it is autoritative for the config, and never accepting any new
|
||||
thus rendering the agent to think it is authoritative for the config, and never accepting any new
|
||||
config files for the zone(s). **If your config master is 2.11.x already, you are not affected by this problem.**
|
||||
|
||||
In order to fix this, upgrade to at least 2.11.1, and purge away the local config sync storage once, then restart.
|
||||
@ -390,7 +390,7 @@ This affects the following features:
|
||||
The reconnect failover has been improved, and the default `failover_timeout`
|
||||
for the DB IDO features has been lowered from 60 to 30 seconds.
|
||||
Object authority updates (required for balancing in the cluster) happen
|
||||
more frequenty (was 30, is 10 seconds).
|
||||
more frequently (was 30, is 10 seconds).
|
||||
Also the cold startup without object authority updates has been reduced
|
||||
from 60 to 30 seconds. This is to allow cluster reconnects (lowered from 60s to 10s in 2.10)
|
||||
before actually considering a failover/split brain scenario.
|
||||
|
@ -666,7 +666,7 @@ setting the `check_command` attribute or custom variables as command parameters.
|
||||
and afterwards the `assign where` and `ignore where` conditions are evaluated.
|
||||
|
||||
It is not necessary to check attributes referenced in the `for loop` expression
|
||||
for their existance using an additional `assign where` condition.
|
||||
for their existence using an additional `assign where` condition.
|
||||
|
||||
More usage examples are documented in the [monitoring basics](03-monitoring-basics.md#using-apply-for)
|
||||
chapter.
|
||||
|
@ -122,7 +122,7 @@ Having this boolean enabled allows icinga2 to connect to all ports. This can be
|
||||
|
||||
**icinga2_run_sudo**
|
||||
|
||||
To allow Icinga 2 executing plugins via sudo you can toogle this boolean. It is disabled by default, resulting in error messages like `execvpe(sudo) failed: Permission denied`.
|
||||
To allow Icinga 2 executing plugins via sudo you can toggle this boolean. It is disabled by default, resulting in error messages like `execvpe(sudo) failed: Permission denied`.
|
||||
|
||||
**httpd_can_write_icinga2_command**
|
||||
|
||||
@ -204,7 +204,7 @@ If you restart the daemon now it will successfully connect to graphite.
|
||||
|
||||
#### Running plugins requiring sudo <a id="selinux-policy-examples-sudo"></a>
|
||||
|
||||
Some plugins require privileged access to the system and are designied to be executed via `sudo` to get these privileges.
|
||||
Some plugins require privileged access to the system and are designed to be executed via `sudo` to get these privileges.
|
||||
|
||||
In this case it is the CheckCommand [running_kernel](10-icinga-template-library.md#plugin-contrib-command-running_kernel) which is set to use `sudo`.
|
||||
|
||||
@ -219,7 +219,7 @@ In this case it is the CheckCommand [running_kernel](10-icinga-template-library.
|
||||
assign where host.name == NodeName
|
||||
}
|
||||
|
||||
Having this Service defined will result in a UNKNOWN state and the error message `execvpe(sudo) failed: Permission denied` because SELinux dening the execution.
|
||||
Having this Service defined will result in a UNKNOWN state and the error message `execvpe(sudo) failed: Permission denied` because SELinux denying the execution.
|
||||
|
||||
Switching the boolean `icinga2_run_sudo` to allow the execution will result in the check executed successfully.
|
||||
|
||||
@ -229,7 +229,7 @@ Switching the boolean `icinga2_run_sudo` to allow the execution will result in t
|
||||
#### Confining a user <a id="selinux-policy-examples-user"></a>
|
||||
|
||||
If you want to have an administrative account capable of only managing icinga2 and not the complete system, you can restrict the privileges by confining
|
||||
this user. This is completly optional!
|
||||
this user. This is completely optional!
|
||||
|
||||
Start by adding the Icinga 2 administrator role `icinga2adm_r` to the administrative SELinux user `staff_u`.
|
||||
|
||||
@ -295,7 +295,7 @@ Failed to issue method call: Access denied
|
||||
|
||||
If you experience any problems while running in enforcing mode try to reproduce it in permissive mode. If the problem persists it is not related to SELinux because in permissive mode SELinux will not deny anything.
|
||||
|
||||
After some feedback Icinga 2 is now running in a enforced domain, but still adds also some rules for other necessary services so no problems should occure at all. But you can help to enhance the policy by testing Icinga 2 running confined by SELinux.
|
||||
After some feedback Icinga 2 is now running in a enforced domain, but still adds also some rules for other necessary services so no problems should occur at all. But you can help to enhance the policy by testing Icinga 2 running confined by SELinux.
|
||||
|
||||
Please add the following information to [bug reports](https://icinga.com/community/):
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user