From 36140fd17e9b67091db4978598043c37165831b1 Mon Sep 17 00:00:00 2001 From: Michael Friedrich Date: Thu, 18 Jul 2019 16:34:36 +0200 Subject: [PATCH] Docs: Update URLs from rename --- doc/02-installation.md | 18 +++---- doc/03-monitoring-basics.md | 24 ++++----- doc/04-configuration.md | 80 +++++++++++++++--------------- doc/05-service-monitoring.md | 2 +- doc/06-distributed-monitoring.md | 22 ++++---- doc/07-agent-based-monitoring.md | 4 +- doc/08-advanced-topics.md | 2 +- doc/09-object-types.md | 2 +- doc/10-icinga-template-library.md | 14 +++--- doc/14-features.md | 4 +- doc/15-troubleshooting.md | 18 +++---- doc/16-upgrading-icinga-2.md | 2 +- doc/17-language-reference.md | 2 +- doc/21-development.md | 2 +- doc/23-migrating-from-icinga-1x.md | 4 +- 15 files changed, 100 insertions(+), 100 deletions(-) diff --git a/doc/02-installation.md b/doc/02-installation.md index 29dd36ae0..3f1464dc9 100644 --- a/doc/02-installation.md +++ b/doc/02-installation.md @@ -1,7 +1,7 @@ # Getting Started -This tutorial is a step-by-step introduction to installing [Icinga 2](02-getting-started.md#setting-up-icinga2) -and [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2). +This tutorial is a step-by-step introduction to installing [Icinga 2](02-installation.md#setting-up-icinga2) +and [Icinga Web 2](02-installation.md#setting-up-icingaweb2). It assumes that you are familiar with the operating system you're using to install Icinga 2. In case you are upgrading an existing setup, please ensure to @@ -306,7 +306,7 @@ Without plugins Icinga 2 does not know how to check external services. The an extensive set of plugins which can be used with Icinga 2 to check whether services are working properly. -These plugins are required to make the [example configuration](04-configuring-icinga-2.md#configuring-icinga2-overview) +These plugins are required to make the [example configuration](04-configuration.md#configuring-icinga2-overview) work out-of-the-box. For your convenience here is a list of package names for some of the more @@ -337,7 +337,7 @@ yum install nagios-plugins-all ``` The packages for RHEL/CentOS depend on other packages which are distributed -as part of the [EPEL repository](02-getting-started.md#package-repositories-rhel-epel). +as part of the [EPEL repository](02-installation.md#package-repositories-rhel-epel). Fedora: @@ -371,7 +371,7 @@ Note: For Alpine you don't need to explicitly add the `monitoring-plugins` packa `icinga2` and is pulled automatically. Depending on which directory your plugins are installed into you may need to -update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuring-icinga-2.md#constants-conf). +update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuration.md#constants-conf). This constant is used by the check command definitions contained in the Icinga Template Library to determine where to find the plugin binaries. @@ -603,8 +603,8 @@ This chapter explains how to set up Icinga Web 2. The DB IDO (Database Icinga Data Output) feature for Icinga 2 take care of exporting all configuration and status information into a database. -Please choose whether to install [MySQL](02-getting-started.md#configuring-db-ido-mysql) or -[PostgreSQL](02-getting-started.md#configuring-db-ido-postgresql). +Please choose whether to install [MySQL](02-installation.md#configuring-db-ido-mysql) or +[PostgreSQL](02-installation.md#configuring-db-ido-postgresql). ### Configuring DB IDO MySQL @@ -744,7 +744,7 @@ Alpine Linux: rc-service icinga2 restart ``` -Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver). +Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver). ### Configuring DB IDO PostgreSQL @@ -910,7 +910,7 @@ Alpine Linux: rc-service icinga2 restart ``` -Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver). +Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver). ### Webserver diff --git a/doc/03-monitoring-basics.md b/doc/03-monitoring-basics.md index e1b0b058c..f8fe8cc06 100644 --- a/doc/03-monitoring-basics.md +++ b/doc/03-monitoring-basics.md @@ -867,8 +867,8 @@ More advanced examples are covered [here](08-advanced-topics.md#use-functions-as ### Apply Services to Hosts -The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) -and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case. +The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf) +and [services.conf](04-configuration.md#services-conf) for this use case. The example for `ssh` applies a service object to all hosts with the `address` attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`. @@ -964,7 +964,7 @@ Detailed examples can be found in the [dependencies](03-monitoring-basics.md#dep ### Apply Recurring Downtimes to Hosts and Services -The sample configuration includes an example in [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf). +The sample configuration includes an example in [downtimes.conf](04-configuration.md#downtimes-conf). Detailed examples can be found in the [recurring downtimes](08-advanced-topics.md#recurring-downtimes) chapter. @@ -975,8 +975,8 @@ Next to the standard way of using [apply rules](03-monitoring-basics.md#using-ap there is the requirement of applying objects based on a set (array or dictionary) using [apply for](17-language-reference.md#apply-for) expressions. -The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) -and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case. +The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf) +and [services.conf](04-configuration.md#services-conf) for this use case. Take the following example: A host provides the snmp oids for different service check types. This could look like the following example: @@ -1046,7 +1046,7 @@ dynamically generated. > **Tip** > -> Define the SNMP community as global constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) file. +> Define the SNMP community as global constant in your [constants.conf](04-configuration.md#constants-conf) file. ``` const IftrafficSnmpCommunity = "public" @@ -1567,7 +1567,7 @@ A common pattern is to store the users and user groups on the host or service objects instead of the notification object itself. -The sample configuration provided in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) and [notifications.conf](notifications-conf) +The sample configuration provided in [hosts.conf](04-configuration.md#hosts-conf) and [notifications.conf](notifications-conf) already provides an example for this question. > **Tip** @@ -1874,7 +1874,7 @@ using the `check_command` attribute. #### Integrate the Plugin with a CheckCommand Definition Unless you have done so already, download your check plugin and put it -into the [PluginDir](04-configuring-icinga-2.md#constants-conf) directory. The following example uses the +into the [PluginDir](04-configuration.md#constants-conf) directory. The following example uses the `check_mysql` plugin contained in the Monitoring Plugins package. The plugin path and all command arguments are made a list of @@ -1913,7 +1913,7 @@ The check command parameters for ITL provided plugin check command definitions a In order to practice passing command parameters you should [integrate your own plugin](03-monitoring-basics.md#command-plugin-integration). -The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-getting-started.md#setting-up-check-plugins). +The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-installation.md#setting-up-check-plugins). Define the default check command custom attributes, for example `mysql_user` and `mysql_password` (freely definable naming schema) and optional their default threshold values. You can @@ -1973,7 +1973,7 @@ The check command definition also sets `mysql_host` to the `$address$` default v this command parameter if for example your MySQL host is not running on the same server's ip address. Make sure pass all required command parameters, such as `mysql_user`, `mysql_password` and `mysql_database`. -`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuring-icinga-2.md#constants-conf) +`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuration.md#constants-conf) in this example. ``` @@ -1996,10 +1996,10 @@ apply Service "mysql-icinga-db-health" { ``` -Take a different example: The example host configuration in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) +Take a different example: The example host configuration in [hosts.conf](04-configuration.md#hosts-conf) also applies an `ssh` service check. Your host's ssh port is not the default `22`, but set to `2022`. You can pass the command parameter as custom attribute `ssh_port` directly inside the service apply rule -inside [services.conf](04-configuring-icinga-2.md#services-conf): +inside [services.conf](04-configuration.md#services-conf): ``` apply Service "ssh" { diff --git a/doc/04-configuration.md b/doc/04-configuration.md index 434b8c9b8..61cce04c1 100644 --- a/doc/04-configuration.md +++ b/doc/04-configuration.md @@ -36,7 +36,7 @@ host and service basis. Then you should look for the object specific configuration setting `host_name` etc. accordingly. You decide on the "best" layout for configuration files and directories. Ensure that -the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file includes them. +the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file includes them. Consider these ideas: @@ -53,7 +53,7 @@ You can later use them for applying assign/ignore rules, or export them into ext * Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules. * Use templates to store generic attributes for your objects and apply rules making your configuration more readable. Details can be found in the [using templates](03-monitoring-basics.md#object-inheritance-using-templates) chapter. -* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuring-icinga-2.md#services-conf) or [notifications.conf](04-configuring-icinga-2.md#notifications-conf)) storing +* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuration.md#services-conf) or [notifications.conf](04-configuration.md#notifications-conf)) storing the configuration instead of defining apply rules deep in your configuration tree. * Every plugin used as check, notification or event command requires a `Command` definition. Further details can be looked up in the [check commands](03-monitoring-basics.md#check-commands) chapter. @@ -176,7 +176,7 @@ the features which have been enabled with `icinga2 feature enable`. See include_recursive "conf.d" ``` -You can put your own configuration files in the [conf.d](04-configuring-icinga-2.md#conf-d) directory. This +You can put your own configuration files in the [conf.d](04-configuration.md#conf-d) directory. This directive makes sure that all of your own configuration files are included. ### constants.conf @@ -185,7 +185,7 @@ The `constants.conf` configuration file can be used to define global constants. By default, you need to make sure to set these constants: -* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-getting-started.md#setting-up-check-plugins) are installed. +* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-installation.md#setting-up-check-plugins) are installed. This constant is used by a number of [built-in check command definitions](10-icinga-template-library.md#icinga-template-library). * The `NodeName` constant defines your local node name. Should be set to FQDN which is the default @@ -224,7 +224,7 @@ This file can be used to specify the required [Zone](09-object-types.md#objectty and [Endpoint](09-object-types.md#objecttype-endpoint) configuration object for [distributed monitoring](06-distributed-monitoring.md#distributed-monitoring). -By default the `NodeName` and `ZoneName` [constants](04-configuring-icinga-2.md#constants-conf) will be used. +By default the `NodeName` and `ZoneName` [constants](04-configuration.md#constants-conf) will be used. It also contains several [global zones](06-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync) for distributed monitoring environments. @@ -237,38 +237,38 @@ for your `Zone` and `Endpoint` object names. This directory contains **example configuration** which should help you get started with monitoring the local host and its services. It is included in the -[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file by default. +[icinga2.conf](04-configuration.md#icinga2-conf) configuration file by default. It can be used as reference example for your own configuration strategy. Just keep in mind to include the main directories in the -[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) file. +[icinga2.conf](04-configuration.md#icinga2-conf) file. > **Note** > -> You can remove the include directive in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) +> You can remove the include directive in [icinga2.conf](04-configuration.md#icinga2-conf) > if you prefer your own way of deploying Icinga 2 configuration. Further details on configuration best practice and how to build your -own strategy is described in [this chapter](04-configuring-icinga-2.md#configuration-best-practice). +own strategy is described in [this chapter](04-configuration.md#configuration-best-practice). Available configuration files which are installed by default: -* [hosts.conf](04-configuring-icinga-2.md#hosts-conf) -* [services.conf](04-configuring-icinga-2.md#services-conf) -* [users.conf](04-configuring-icinga-2.md#users-conf) -* [notifications.conf](04-configuring-icinga-2.md#notifications-conf) -* [commands.conf](04-configuring-icinga-2.md#commands-conf) -* [groups.conf](04-configuring-icinga-2.md#groups-conf) -* [templates.conf](04-configuring-icinga-2.md#templates-conf) -* [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf) -* [timeperiods.conf](04-configuring-icinga-2.md#timeperiods-conf) -* [api-users.conf](04-configuring-icinga-2.md#api-users-conf) -* [app.conf](04-configuring-icinga-2.md#app-conf) +* [hosts.conf](04-configuration.md#hosts-conf) +* [services.conf](04-configuration.md#services-conf) +* [users.conf](04-configuration.md#users-conf) +* [notifications.conf](04-configuration.md#notifications-conf) +* [commands.conf](04-configuration.md#commands-conf) +* [groups.conf](04-configuration.md#groups-conf) +* [templates.conf](04-configuration.md#templates-conf) +* [downtimes.conf](04-configuration.md#downtimes-conf) +* [timeperiods.conf](04-configuration.md#timeperiods-conf) +* [api-users.conf](04-configuration.md#api-users-conf) +* [app.conf](04-configuration.md#app-conf) #### hosts.conf The `hosts.conf` file contains an example host based on your -`NodeName` setting in [constants.conf](04-configuring-icinga-2.md#constants-conf). You +`NodeName` setting in [constants.conf](04-configuration.md#constants-conf). You can use global constants for your object names instead of string values. @@ -281,20 +281,20 @@ for check and notification commands. Most of the [Plugin Check Commands](10-icin in the Icinga Template Library require an `address` attribute. The custom attribute `os` is evaluated by the `linux-servers` group in -[groups.conf](04-configuring-icinga-2.md#groups-conf) making the local host a member. +[groups.conf](04-configuration.md#groups-conf) making the local host a member. The example host will show you how to: * define http vhost attributes for the `http` service apply rule defined -in [services.conf](04-configuring-icinga-2.md#services-conf). +in [services.conf](04-configuration.md#services-conf). * define disks (all, specific `/`) and their attributes for the `disk` -service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf). +service apply rule defined in [services.conf](04-configuration.md#services-conf). * define notification types (`mail`) and set the groups attribute. This -will be used by notification apply rules in [notifications.conf](04-configuring-icinga-2.md#notifications-conf). +will be used by notification apply rules in [notifications.conf](04-configuration.md#notifications-conf). -If you've installed [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2), you can +If you've installed [Icinga Web 2](02-installation.md#setting-up-icingaweb2), you can uncomment the http vhost attributes and reload Icinga 2. The apply -rules in [services.conf](04-configuring-icinga-2.md#services-conf) will automatically +rules in [services.conf](04-configuration.md#services-conf) will automatically generate a new service checking the `/icingaweb2` URI using the `http` check. @@ -353,7 +353,7 @@ object Host NodeName { ``` This is only the host object definition. Now we'll need to make sure that this -host and your additional hosts are getting [services](04-configuring-icinga-2.md#services-conf) applied. +host and your additional hosts are getting [services](04-configuration.md#services-conf) applied. > **Tip** > @@ -409,7 +409,7 @@ attributes. The custom attribute `backup_downtime` is defined to a specific timerange string. This variable value will be used for applying a `ScheduledDowntime` object to -these services in [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf). +these services in [downtimes.conf](04-configuration.md#downtimes-conf). In this example the `assign where` condition is a boolean expression which is evaluated for all objects of type `Host` and a new service with name "load" @@ -442,10 +442,10 @@ rules. While one `apply` rule for `ssh` will only create a service for matching hosts, you can go one step further: Generate apply rules based on array items or dictionary key-value pairs. -The idea is simple: Your host in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) defines the +The idea is simple: Your host in [hosts.conf](04-configuration.md#hosts-conf) defines the `disks` dictionary as custom attribute in `vars`. -Remember the example from [hosts.conf](04-configuring-icinga-2.md#hosts-conf): +Remember the example from [hosts.conf](04-configuration.md#hosts-conf): ``` ... @@ -499,11 +499,11 @@ A similar example is used for the `http` services. That way you can make your host the information provider for all apply rules. Define them once, and only manage your hosts. -Look into [notifications.conf](04-configuring-icinga-2.md#notifications-conf) how this technique is used +Look into [notifications.conf](04-configuration.md#notifications-conf) how this technique is used for applying notifications to hosts and services using their type and user attributes. -Don't forget to install the [check plugins](02-getting-started.md#setting-up-check-plugins) required by +Don't forget to install the [check plugins](02-installation.md#setting-up-check-plugins) required by the hosts and services and their check commands. Further details on the monitoring configuration can be found in the @@ -512,8 +512,8 @@ Further details on the monitoring configuration can be found in the #### users.conf Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in -[hosts.conf](04-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in -[notifications.conf](04-configuring-icinga-2.md#notifications-conf) for notification apply rules. +[hosts.conf](04-configuration.md#hosts-conf) for defining a custom host attribute later used in +[notifications.conf](04-configuration.md#notifications-conf) for notification apply rules. ``` object User "icingaadmin" { @@ -541,13 +541,13 @@ nested dictionary attribute `notification.mail` is set. Please note that the `to` keyword is important in [notification apply rules](03-monitoring-basics.md#using-apply-notifications) defining whether these notifications are applies to hosts or services. -The `import` keyword imports the specific mail templates defined in [templates.conf](04-configuring-icinga-2.md#templates-conf). +The `import` keyword imports the specific mail templates defined in [templates.conf](04-configuration.md#templates-conf). The `interval` attribute is not explicitly set -- it [defaults to 30 minutes](09-object-types.md#objecttype-notification). By setting the `user_groups` to the value provided by the -respective [host.vars.notification.mail](04-configuring-icinga-2.md#hosts-conf) attribute we'll -implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuring-icinga-2.md#users-conf). +respective [host.vars.notification.mail](04-configuration.md#hosts-conf) attribute we'll +implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuration.md#users-conf). ``` apply Notification "mail-icingaadmin" to Host { @@ -575,7 +575,7 @@ filters can be read in [this chapter](03-monitoring-basics.md#alert-notification #### commands.conf This is the place where your own command configuration can be defined. By default -only the notification commands used by the notification templates defined in [templates.conf](04-configuring-icinga-2.md#templates-conf). +only the notification commands used by the notification templates defined in [templates.conf](04-configuration.md#templates-conf). You can freely customize these notification commands, and adapt them for your needs. Read more on that topic [here](03-monitoring-basics.md#notification-commands). @@ -680,7 +680,7 @@ More details on `Notification` object attributes can be found [here](09-object-t #### downtimes.conf -The `load` service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf) defines +The `load` service apply rule defined in [services.conf](04-configuration.md#services-conf) defines the `backup_downtime` custom attribute. The ScheduledDowntime apply rule uses this attribute to define the default value diff --git a/doc/05-service-monitoring.md b/doc/05-service-monitoring.md index 98360dead..b19e284e4 100644 --- a/doc/05-service-monitoring.md +++ b/doc/05-service-monitoring.md @@ -130,7 +130,7 @@ chmod +x /opt/monitoring/plugins/check_snmp_int.pl ``` Next create a new global constant, e.g. `CustomPluginDir` -in your [constants.conf](04-configuring-icinga-2.md#constants-conf) +in your [constants.conf](04-configuration.md#constants-conf) configuration file: ``` diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md index e02e6d632..74a95e11c 100644 --- a/doc/06-distributed-monitoring.md +++ b/doc/06-distributed-monitoring.md @@ -36,7 +36,7 @@ In case you are planning a huge cluster setup with multiple levels and lots of clients, read on -- we'll deal with these cases later on. The installation on each system is the same: You need to install the -[Icinga 2 package](02-getting-started.md#setting-up-icinga2) and the required [plugins](02-getting-started.md#setting-up-check-plugins). +[Icinga 2 package](02-installation.md#setting-up-icinga2) and the required [plugins](02-installation.md#setting-up-check-plugins). The required configuration steps are mostly happening on the command line. You can also [automate the setup](06-distributed-monitoring.md#distributed-monitoring-automation). @@ -227,8 +227,8 @@ This section explains how to install a central single master node using the `node wizard` command. If you prefer to do an automated installation, please refer to the [automated setup](06-distributed-monitoring.md#distributed-monitoring-automation) section. -Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup -the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done +Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup +the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done so already. **Note**: Windows is not supported for a master node setup. @@ -250,9 +250,9 @@ The setup wizard will ensure that the following steps are taken: * Enable the `api` feature. * Generate a new certificate authority (CA) in `/var/lib/icinga2/ca` if it doesn't exist. * Create a certificate for this node signed by the CA key. -* Update the [zones.conf](04-configuring-icinga-2.md#zones-conf) file with the new zone hierarchy. -* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuring-icinga-2.md#constants-conf) configuration. -* Update the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion. +* Update the [zones.conf](04-configuration.md#zones-conf) file with the new zone hierarchy. +* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuration.md#constants-conf) configuration. +* Update the [icinga2.conf](04-configuration.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion. Here is an example of a master setup for the `icinga2-master1.localdomain` node on CentOS 7: @@ -293,7 +293,7 @@ Now restart your Icinga 2 daemon to finish the installation! ``` You can verify that the CA public and private keys are stored in the `/var/lib/icinga2/ca` directory. -Keep this path secure and include it in your [backups](02-getting-started.md#install-backup). +Keep this path secure and include it in your [backups](02-installation.md#install-backup). In case you lose the CA private key you have to generate a new CA for signing new client certificate requests. You then have to also re-create new signed certificates for all @@ -473,8 +473,8 @@ Icinga 2 on the master node must be running and accepting connections on port `5 Please ensure that you've run all the steps mentioned in the [client/satellite section](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client). -Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup -the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done +Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup +the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done so already. The next step is to run the `node wizard` CLI command. @@ -929,7 +929,7 @@ The host/service object configuration is located on the master/satellite and the needs the CheckCommand object definitions being used there. Every endpoint has its own remote check queue. The amount of checks executed simultaneously -can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuring-icinga-2.md#constants-conf). Icinga 2 may discard check requests, +can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuration.md#constants-conf). Icinga 2 may discard check requests, if the remote check queue is full. ![Icinga 2 Distributed Top Down Command Endpoint](images/distributed-monitoring/icinga2_distributed_top_down_command_endpoint.png) @@ -2817,7 +2817,7 @@ to pick the authoritative running one and copy the following content: If you need already deployed config packages from the Director, or synced cluster zones, you can also sync the entire `/var/lib/icinga2/api/packages` directory. This directory should also be -included in your [backup strategy](02-getting-started.md#install-backup). +included in your [backup strategy](02-installation.md#install-backup). Do **not** sync `/var/lib/icinga2/api/zones*` manually - this is an internal directory and handled by the Icinga cluster config sync itself. diff --git a/doc/07-agent-based-monitoring.md b/doc/07-agent-based-monitoring.md index 99e461523..7f75262a4 100644 --- a/doc/07-agent-based-monitoring.md +++ b/doc/07-agent-based-monitoring.md @@ -7,7 +7,7 @@ become handy. ## SNMP The SNMP daemon runs on the remote system and answers SNMP queries by plugin -binaries. The [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins) ships +binaries. The [Monitoring Plugins package](02-installation.md#setting-up-check-plugins) ships the `check_snmp` plugin binary, but there are plenty of [existing plugins](05-service-monitoring.md#service-monitoring-plugins) for specific use cases already around, for example monitoring Cisco routers. @@ -37,7 +37,7 @@ As such, it is recommended to always specify at least one `MIB`. Calling a plugin using the SSH protocol to execute a plugin on the remote server fetching its return code and output. The `by_ssh` command object is part of the built-in templates and -requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins). +requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-installation.md#setting-up-check-plugins). ``` object CheckCommand "by_ssh_swap" { diff --git a/doc/08-advanced-topics.md b/doc/08-advanced-topics.md index d4cb3ab2d..af17e05f4 100644 --- a/doc/08-advanced-topics.md +++ b/doc/08-advanced-topics.md @@ -699,7 +699,7 @@ inside the `icinga2.log` file depending in your log severity in objects and other functions. Keep in mind that these functions are not marked as side-effect-free and as such are not available via the REST API. -Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) +Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file in the very beginning, e.g. after `constants.conf`. You can also manage global functions inside `constants.conf` if you prefer. diff --git a/doc/09-object-types.md b/doc/09-object-types.md index 8de8a8f87..f9a0f624f 100644 --- a/doc/09-object-types.md +++ b/doc/09-object-types.md @@ -1104,7 +1104,7 @@ and API usage specifying the certificate files used for ssl authorization and additional restrictions. This configuration object is available as [api feature](11-cli-commands.md#cli-command-feature). -The `TicketSalt` constant must be defined in [constants.conf](04-configuring-icinga-2.md#constants-conf). +The `TicketSalt` constant must be defined in [constants.conf](04-configuration.md#constants-conf). Example: diff --git a/doc/10-icinga-template-library.md b/doc/10-icinga-template-library.md index b1e6b01d1..fe1d6fdd9 100644 --- a/doc/10-icinga-template-library.md +++ b/doc/10-icinga-template-library.md @@ -23,7 +23,7 @@ You are advised to create your own CheckCommand definitions in ## Generic Templates -By default the generic templates are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file: +By default the generic templates are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file: ``` include @@ -177,7 +177,7 @@ sleep\_time | **Optional.** The duration of the sleep in seconds. Defaults t The Plugin Check Commands provides example configuration for plugin check commands provided by the [Monitoring Plugins](https://www.monitoring-plugins.org) project. -By default the Plugin Check Commands are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration +By default the Plugin Check Commands are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file: include @@ -1731,7 +1731,7 @@ are not recommended with using the legacy HTTP API. `check_nscp_api` is part of the Icinga 2 plugins. This plugin is available for both, Windows and Linux/Unix. -Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file: +Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file: vim /etc/icinga2/icinga2.conf @@ -1774,12 +1774,12 @@ check_cpu CRITICAL: critical(5m: 48%, 1m: 36%), 5s: 0% | 'total 5m'=48%;40;30 't Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks locally on the client. You can enable these check commands by adding the following the include directive in your -[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file: +[icinga2.conf](04-configuration.md#icinga2-conf) configuration file: include You can also optionally specify an alternative installation directory for NSClient++ by adding -the NscpPath constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) configuration +the NscpPath constant in your [constants.conf](04-configuration.md#constants-conf) configuration file: const NscpPath = "C:\\Program Files (x86)\\NSClient++" @@ -1944,7 +1944,7 @@ The SNMP manubulon plugin check commands assume that the global constant named ` is set to the path where the Manubublon SNMP plugins are installed. You can enable these plugin check commands by adding the following the include directive in your -[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file: +[icinga2.conf](04-configuration.md#icinga2-conf) configuration file: include @@ -2194,7 +2194,7 @@ contributed by community members. These check commands assume that the global constant named `PluginContribDir` is set to the path where the user installs custom plugins and can be enabled by -uncommenting the corresponding line in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf): +uncommenting the corresponding line in [icinga2.conf](04-configuration.md#icinga2-conf): ``` vim /etc/icinga2/icinga2.conf diff --git a/doc/14-features.md b/doc/14-features.md index dff90cd9b..b7c93f45c 100644 --- a/doc/14-features.md +++ b/doc/14-features.md @@ -50,7 +50,7 @@ The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all configuration and status information into a database. The IDO database is used by Icinga Web 2 as data backend. -Details on the installation can be found in the [Configuring DB IDO](02-getting-started.md#configuring-db-ido-mysql) +Details on the installation can be found in the [Configuring DB IDO](02-installation.md#configuring-db-ido-mysql) chapter. Details on the configuration can be found in the [IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and [IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection) @@ -736,7 +736,7 @@ Livestatus. > > Only install the Livestatus feature if your web interface or addon requires > you to do so. -> [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) does not need +> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) does not need > Livestatus. Details on the available tables and attributes with Icinga 2 can be found diff --git a/doc/15-troubleshooting.md b/doc/15-troubleshooting.md index 216fbd975..44310ba36 100644 --- a/doc/15-troubleshooting.md +++ b/doc/15-troubleshooting.md @@ -22,8 +22,8 @@ findings and details please. * [Icinga Web 2 modules](https://icinga.com/products/icinga-web-2-modules/) e.g. the Icinga Director (optional) * Configuration insights: * Provide complete configuration snippets explaining your problem in detail - * Your [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) file - * If you run multiple Icinga 2 instances, the [zones.conf](04-configuring-icinga-2.md#zones-conf) file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes. + * Your [icinga2.conf](04-configuration.md#icinga2-conf) file + * If you run multiple Icinga 2 instances, the [zones.conf](04-configuration.md#zones-conf) file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes. * Logs * Relevant output from your main and [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) in `/var/log/icinga2`. Please add step-by-step explanations with timestamps if required. * The newest Icinga 2 crash log if relevant, located in `/var/log/icinga2/crash` @@ -237,7 +237,7 @@ include include ``` -in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered +in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden on upgrade, so please send modifications as proposed patches upstream. The default include path is set to `/usr/share/icinga2/includes` with the constant `IncludeConfDir`. @@ -248,7 +248,7 @@ or similar. * Make sure that the line(s) are not [commented out](17-language-reference.md#comments) (starting with `//` or `#`, or encapsulated by `/* ... */`). -* Is the configuration file included in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)? +* Is the configuration file included in [icinga2.conf](04-configuration.md#icinga2-conf)? Run the [configuration validation](11-cli-commands.md#config-validation) and add `notice` as log severity. Search for the file which should be included i.e. using the `grep` CLI command. @@ -481,7 +481,7 @@ critical thresholds are sometimes to applied and unwanted notification alerts are raised. This happens because the client itself includes a host object with -its `NodeName` and a basic set of checks in the [conf.d](04-configuring-icinga-2.md#conf-d) +its `NodeName` and a basic set of checks in the [conf.d](04-configuration.md#conf-d) directory, i.e. `disk` with the default thresholds. Clients which have the `checker` feature enabled will attempt @@ -494,7 +494,7 @@ master you will receive wrong check results from the client. Solution: * Disable the `checker` feature on clients: `icinga2 feature disable checker`. -* Remove the inclusion of [conf.d](04-configuring-icinga-2.md#conf-d) as suggested in the [client setup docs](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint). +* Remove the inclusion of [conf.d](04-configuration.md#conf-d) as suggested in the [client setup docs](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint). ### Check Fork Errors @@ -712,7 +712,7 @@ $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://local ### Feature is not working * Make sure that the feature configuration is enabled by symlinking from `features-available/` -to `features-enabled` and that the latter is included in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf). +to `features-enabled` and that the latter is included in [icinga2.conf](04-configuration.md#icinga2-conf). * Are the feature attributes set correctly according to the documentation? * Any errors on the logs? @@ -1236,7 +1236,7 @@ certificate's CN, the master will deny all events. > **Tip** > -> [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) provides a dashboard view +> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) provides a dashboard view > for overdue check results. Enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) on the master @@ -1281,7 +1281,7 @@ Icinga 2 requires the `NodeName` [constant](17-language-reference.md#constants) This includes loading the TLS certificates, setting the proper check source, and so on. -Typically the Windows setup wizard and also the CLI commands populate the [constants.conf](04-configuring-icinga-2.md#constants-conf) +Typically the Windows setup wizard and also the CLI commands populate the [constants.conf](04-configuration.md#constants-conf) file with the auto-detected or user-provided FQDN/Common Name. If this constant is not set during startup, Icinga will try to resolve the diff --git a/doc/16-upgrading-icinga-2.md b/doc/16-upgrading-icinga-2.md index 3f5ba1017..756604f8b 100644 --- a/doc/16-upgrading-icinga-2.md +++ b/doc/16-upgrading-icinga-2.md @@ -234,7 +234,7 @@ for `ca list`. The deprecated `concurrent_checks` attribute in the [checker feature](09-object-types.md#objecttype-checkercomponent) has no effect anymore if set. Please use the [MaxConcurrentChecks](17-language-reference.md#icinga-constants-global-config) -constant in [constants.conf](04-configuring-icinga-2.md#constants-conf) instead. +constant in [constants.conf](04-configuration.md#constants-conf) instead. ### REST API diff --git a/doc/17-language-reference.md b/doc/17-language-reference.md index 55c73ec58..541c51aee 100644 --- a/doc/17-language-reference.md +++ b/doc/17-language-reference.md @@ -473,7 +473,7 @@ once they are set. > **Tip** > -> Best practice is to manage constants in the [constants.conf](04-configuring-icinga-2.md#constants-conf) file. +> Best practice is to manage constants in the [constants.conf](04-configuration.md#constants-conf) file. ### Icinga 2 Specific Constants diff --git a/doc/21-development.md b/doc/21-development.md index 382cf5737..16104ac73 100644 --- a/doc/21-development.md +++ b/doc/21-development.md @@ -432,7 +432,7 @@ on GitHub and mention that you're testing the snapshot packages. #### RHEL/CentOS -2.11+ requires the [EPEL repository](02-getting-started.md#package-repositories-rhel-epel) for Boost 1.66+. +2.11+ requires the [EPEL repository](02-installation.md#package-repositories-rhel-epel) for Boost 1.66+. In addition to that, the `icinga-rpm-release` package already provides the `icinga-snapshot-builds` repository but it is disabled by default. diff --git a/doc/23-migrating-from-icinga-1x.md b/doc/23-migrating-from-icinga-1x.md index 8ae0aaa17..f0df9d019 100644 --- a/doc/23-migrating-from-icinga-1x.md +++ b/doc/23-migrating-from-icinga-1x.md @@ -810,7 +810,7 @@ included in `icinga2.conf` by default. > **Note** > > Add your own custom templates in the `conf.d/` directory as well, e.g. inside -> the [templates.conf](04-configuring-icinga-2.md#templates-conf) file. +> the [templates.conf](04-configuration.md#templates-conf) file. ### Main Config File @@ -818,7 +818,7 @@ In Icinga 1.x there are many global configuration settings available in `icinga. Icinga 2 only uses a small set of [global constants](17-language-reference.md#constants) allowing you to specify certain different setting such as the `NodeName` in a cluster scenario. -Aside from that, the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) should take care of including +Aside from that, the [icinga2.conf](04-configuration.md#icinga2-conf) should take care of including global constants, enabled [features](11-cli-commands.md#enable-features) and the object configuration. ### Include Files and Directories