From ae1ce6e2c418c9e58ea48430c83fa9e93105aa23 Mon Sep 17 00:00:00 2001 From: Gunnar Beutner Date: Sun, 6 Apr 2014 21:15:25 +0200 Subject: [PATCH] Clean up some of the notes. Refs #5909 --- doc/2.1-setting-up-icinga-2.md | 14 ++-- doc/2.2-setting-up-check-plugins.md | 6 +- doc/2.3-setting-up-ido.md | 60 ++++++--------- doc/2.4-setting-up-livestatus.md | 10 +-- doc/2.5-setting-up-icinga2-uis.md | 40 +++------- doc/2.7-running-icinga-2.md | 15 ++-- doc/3.02-commands.md | 44 ++++------- doc/3.03-custom-attributes-runtime-macros.md | 21 +----- doc/3.04-notifications.md | 66 +++++------------ doc/3.06-groups.md | 27 ++----- doc/3.08-external-commands.md | 14 ++-- doc/3.11-performance-data.md | 8 -- doc/3.12-status-data.md | 5 -- doc/3.13-compat-logging.md | 4 - doc/3.15-monitoring-remote-clients.md | 14 ++-- doc/4.1-configuration-syntax.md | 57 +++++---------- doc/4.3-object-types.md | 77 +++++++------------- doc/6.01-downtimes.md | 14 +--- doc/6.03-acknowledgements.md | 6 +- doc/6.04-cluster.md | 32 +++----- doc/6.08-check-flapping.md | 5 +- doc/6.12-schemas.md | 16 ++-- doc/7-migrating-from-icinga-1x.md | 5 -- doc/8-differences-between-icinga-1x-and-2.md | 49 ++----------- doc/9-vagrant-demo-vm.md | 14 ++-- 25 files changed, 184 insertions(+), 439 deletions(-) diff --git a/doc/2.1-setting-up-icinga-2.md b/doc/2.1-setting-up-icinga-2.md index fe0328a1e..e49bbcfea 100644 --- a/doc/2.1-setting-up-icinga-2.md +++ b/doc/2.1-setting-up-icinga-2.md @@ -16,19 +16,15 @@ 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 favourite distribution. -> **Note** -> -> The packages for RHEL/CentOS 5 depend on other packages which are distributed -> as part of the [EPEL repository](http://fedoraproject.org/wiki/EPEL). Please -> make sure to enable this repository. +The packages for RHEL/CentOS 5 depend on other packages which are distributed +as part of the [EPEL repository](http://fedoraproject.org/wiki/EPEL). Please +make sure to enable this repository. You can install Icinga 2 by using your distribution's package manager to install the `icinga2` package. -> **Note** -> -> On RHEL/CentOS and SLES you will need to use `chkconfig` to enable the -> `icinga2` service. You can manually start Icinga 2 using `/etc/init.d/icinga2 start`. +On RHEL/CentOS and SLES you will need to use `chkconfig` to enable the +`icinga2` service. You can manually start Icinga 2 using `/etc/init.d/icinga2 start`. Some parts of Icinga 2's functionality are available as separate packages: diff --git a/doc/2.2-setting-up-check-plugins.md b/doc/2.2-setting-up-check-plugins.md index 145d869d5..93070cbb7 100644 --- a/doc/2.2-setting-up-check-plugins.md +++ b/doc/2.2-setting-up-check-plugins.md @@ -63,7 +63,5 @@ by trying to run it on the console using whichever user Icinga 2 is running as: # su - icinga -s /bin/bash $ /opt/plugins/check_snmp_int.pl --help -> **Note** -> -> Additional libraries may be required for some plugins. Please consult the plugin -> documentation and/or README for installation instructions. +Additional libraries may be required for some plugins. Please consult the plugin +documentation and/or README for installation instructions. diff --git a/doc/2.3-setting-up-ido.md b/doc/2.3-setting-up-ido.md index 7c9ee43ab..538f18f1e 100644 --- a/doc/2.3-setting-up-ido.md +++ b/doc/2.3-setting-up-ido.md @@ -7,12 +7,10 @@ by a number of projects including Icinga Web. There is a separate module for each database back-end. At present support for both MySQL and PostgreSQL is implemented. -> **Note** -> -> Icinga 2 uses the Icinga 1.x IDOUtils database schema starting with version -> `1.11.0`. Icinga 2 may require additional features not yet released with -> Icinga 1.x and therefore require manual upgrade steps during pre-final -> milestone releases. +Icinga 2 uses the Icinga 1.x IDOUtils database schema starting with version +`1.11.0`. Icinga 2 may require additional features not yet released with +Icinga 1.x and therefore require manual upgrade steps during pre-final +milestone releases. > **Tip** > @@ -48,17 +46,14 @@ following command: # mysql -u root -p icinga < /usr/share/doc/icinga2-ido-mysql-*/schema/mysql.sql -> **Note** -> -> The Icinga 2 RPM packages install the schema files into -> `/usr/share/doc/icinga2-ido-mysql-*/schema` (`*` means package version). -> The Icinga 2 dist tarball ships the schema files in `components/db_ido_mysql/schema/`. -> -> On SuSE-based distributions the schema files are installed in -> `/usr/share/doc/packages/icinga2-ido-mysql/schema`. -> -> The Debian/Ubuntu packages put the schema files into -> `/usr/share/icinga2-ido-mysql/schema`. +The Icinga 2 RPM packages install the schema files into +`/usr/share/doc/icinga2-ido-mysql-*/schema` (`*` means package version). + +On SuSE-based distributions the schema files are installed in +`/usr/share/doc/packages/icinga2-ido-mysql/schema`. + +The Debian/Ubuntu packages put the schema files into +`/usr/share/icinga2-ido-mysql/schema`. #### Upgrading the MySQL database @@ -85,10 +80,8 @@ Apply all database schema upgrade files incrementially. # mysql -u root -p icinga < /usr/share/doc/icinga2-ido-mysql-*/schema/upgrade/mysql-upgrade-1.12.0.sql -> **Note** -> -> The Icinga 2 IDO module will check for the required database schema version -> on startup and generate an error message if not satisfied. +The Icinga 2 IDO module will check for the required database schema version on startup +and generate an error message if not satisfied. #### Installing the IDO MySQL module @@ -153,18 +146,14 @@ using the following command: # export PGPASSWORD=icinga # psql -U icinga -d icinga < /usr/share/doc/icinga2-ido-pgsql-*/schema/pgsql.sql -> **Note** -> -> The Icinga 2 RPM packages install the schema files into -> `/usr/share/doc/icinga2-ido-pgsql-*/schema` (`*` means package version). -> The Icinga 2 dist tarball ships the schema files in `components/db_ido_pgsql/schema/`. -> -> On SuSE-based distributions the schema files are installed in -> `/usr/share/doc/packages/icinga2-ido-pgsql/schema`. -> -> The Debian/Ubuntu packages put the schema files into -> `/usr/share/icinga2-ido-pgsql/schema`. +The Icinga 2 RPM packages install the schema files into +`/usr/share/doc/icinga2-ido-pgsql-*/schema` (`*` means package version). +On SuSE-based distributions the schema files are installed in +`/usr/share/doc/packages/icinga2-ido-pgsql/schema`. + +The Debian/Ubuntu packages put the schema files into +`/usr/share/icinga2-ido-pgsql/schema`. #### Upgrading the PostgreSQL database @@ -191,11 +180,8 @@ Apply all database schema upgrade files incrementially. # export PGPASSWORD=icinga # psql -U icinga -d icinga < /usr/share/doc/icinga2-ido-pgsql-*/schema/upgrade/pgsql-upgrade-1.12.0.sql -> **Note** -> -> The Icinga 2 IDO module will check for the required database schema version -> on startup and generate an error message if not satisfied. - +The Icinga 2 IDO module will check for the required database schema version on startup +and generate an error message if not satisfied. #### Installing the IDO PostgreSQL module diff --git a/doc/2.4-setting-up-livestatus.md b/doc/2.4-setting-up-livestatus.md index 8e1b24e76..0f754d2ee 100644 --- a/doc/2.4-setting-up-livestatus.md +++ b/doc/2.4-setting-up-livestatus.md @@ -33,14 +33,10 @@ In order for queries and commands to work you will need to add your query user # usermod -a -G icingacmd www-data -> **Note** -> -> Debian packages use `nagios` as default user/group. Therefore change `icingacmd` to -> `nagios`. +The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to +`nagios` if you're using Debian. -> **Note** -> -> Change "www-data" to the user you're using to run queries. +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 diff --git a/doc/2.5-setting-up-icinga2-uis.md b/doc/2.5-setting-up-icinga2-uis.md index 40d2e1831..8b29d61cc 100644 --- a/doc/2.5-setting-up-icinga2-uis.md +++ b/doc/2.5-setting-up-icinga2-uis.md @@ -35,15 +35,11 @@ the Classic UI using the following packages: Debian | icinga2-classicui all others | icinga2-classicui-config icinga-gui -> **Note** -> -> Debian packages require additional dependencies satisfied by the [debmon](http://www.debmong.org) -> repository. +The Debian packages require additional packages which are provided by the +[Debian Monitoring Project](http://www.debmon.org) repository. -> **Note** -> -> On all distributions other than Debian you may have to restart both your web -> server as well as Icinga 2 after installing the Classic UI package. +On all distributions other than Debian you may have to restart both your web +server as well as Icinga 2 after installing the Classic UI package. Verify that your Icinga 1.x Classic UI works by browsing to your Classic UI installation URL: @@ -53,13 +49,6 @@ UI installation URL: Debian | [http://localhost/icinga2-classicui](http://localhost/icinga2-classicui) | asked during installation all others | [http://localhost/icinga](http://localhost/icinga) | icingaadmin/icingaadmin -> **Note** -> -> Due to compatibility restrictions, not all features available in Icinga 1.x -> Classic UI will be available with Icinga 2. The different handling of -> [commands](#differences-1x-2-commands) and [custom attributes](#differences-1x-2-macros) -> renders the command expander invalid for example. - ### Setting up Icinga Web Icinga 2 can write to the same schema supplied by `Icinga IDOUtils 1.x` which @@ -78,15 +67,12 @@ the Classic UI using the following packages: Additionally you need to setup the `icinga_web` database. -> **Note** -> -> The Icinga Web RPM packages install the schema files into -> `/usr/share/doc/icinga-web-*/schema` (`*` means package version). -> The Icinga Web dist tarball ships the schema files in `etc/schema`. -> -> On SuSE-based distributions the schema files are installed in -> `/usr/share/doc/packages/icinga-web/schema`. +The Icinga Web RPM packages install the schema files into +`/usr/share/doc/icinga-web-*/schema` (`*` means package version). +The Icinga Web dist tarball ships the schema files in `etc/schema`. +On SuSE-based distributions the schema files are installed in +`/usr/share/doc/packages/icinga-web/schema`. Additionally you need to enable the `ExternalCommandListener` feature. @@ -119,11 +105,9 @@ Icinga Web 2 currently supports `status.dat`, `DB IDO`, or `Livestatus` as backe Please consult the INSTALL documentation shipped with `Icinga Web 2` for further instructions. -> **Note** -> -> Icinga Web 2 is still under heavy development. Rather than installing it -> yourself you should consider testing it using the available Vagrant -> demo boxes. +Icinga Web 2 is still under development. Rather than installing it +yourself you should consider testing it using the available Vagrant +demo VM. ### Additional visualization diff --git a/doc/2.7-running-icinga-2.md b/doc/2.7-running-icinga-2.md index 3b305eee3..5432b1f31 100644 --- a/doc/2.7-running-icinga-2.md +++ b/doc/2.7-running-icinga-2.md @@ -16,11 +16,9 @@ Icinga 2's init script is installed in `/etc/init.d/icinga2` by default: checkconfig | The `checkconfig` action checks if the `/etc/icinga2/icinga2.conf` configuration file contains any errors. status | The `status` action checks if Icinga 2 is running. -> **Note** -> -> By default the Icinga 2 daemon is running as `icinga` user and group -> using the init script. Using Debian packages the user and group are set to `nagios` -> for historical reasons. +By default the Icinga 2 daemon is running as `icinga` user and group +using the init script. Using Debian packages the user and group are set to `nagios` +for historical reasons. ### Command-line Options @@ -111,6 +109,7 @@ You can disable features using the `icinga2-disable-feature` command: Module 'statusdata' was disabled. Make sure to restart Icinga 2 for these changes to take effect. -> **Note** -> -> The `icinga2-enable-feature` and `icinga2-disable-feature` commands do not restart Icinga 2. +The `icinga2-enable-feature` and `icinga2-disable-feature` commands do not +restart Icinga 2. You will need to restart Icinga 2 using the init script +after enabling or disabling features. + diff --git a/doc/3.02-commands.md b/doc/3.02-commands.md index 272b7e23a..3a5c3b932 100644 --- a/doc/3.02-commands.md +++ b/doc/3.02-commands.md @@ -4,14 +4,6 @@ Icinga 2 uses three different command object types to specify how checks should be performed, notifications should be sent and events should be handled. -> **Note** -> -> Define the global `PluginDir` constant (located in -> `/etc/icinga2/constants.conf` by default) and use -> it in all your command object definitions. -> Put your plugins and scripts into the directory defined by the `PluginDir` constant -> and make sure they are executable by the Icinga 2 user. - ### Environment Varialbes for Commands Please check [Runtime Custom Attributes as Environment Variables](#runtime-custom-attribute-env-vars). @@ -20,10 +12,8 @@ Please check [Runtime Custom Attributes as Environment Variables](#runtime-custo `CheckCommand` objects define the command line how a check is called. -> **Note** -> -> `CheckCommand` objects require the ITL template `plugin-check-command` -> to support native plugin based check methods. +`CheckCommand` objects require the ITL template `plugin-check-command` +to support native plugin based check methods. Unless you have done so already, download your check plugin and put it into the `PluginDir` directory. The following example uses the @@ -41,11 +31,9 @@ Define the default check command custom attribute `wfree` and `cfree` freely definable naming schema) and their default threshold values. You can then use these custom attributes as runtime macros on the command line. -> **Note** -> -> The default custom attributes can be overridden by the custom attributes -> defined in the service using the check command `disk`. The custom attributes -> can also be inherited from a parent template using additive inheritance (`+=`). +The default custom attributes can be overridden by the custom attributes +defined in the service using the check command `disk`. The custom attributes +can also be inherited from a parent template using additive inheritance (`+=`). object CheckCommand "disk" { import "plugin-check-command" @@ -87,10 +75,8 @@ free disk space). `NotificationCommand` objects define how notifications are delivered to external interfaces (E-Mail, XMPP, IRC, Twitter, etc). -> **Note** -> -> `NotificationCommand` objects require the ITL template `plugin-notification-command` -> to support native plugin-based notifications. +`NotificationCommand` objects require the ITL template `plugin-notification-command` +to support native plugin-based notifications. Below is an example using runtime macros from Icinga 2 (such as `$SERVICEOUTPUT$` for the current check output) sending an email to the user(s) associated with the @@ -147,12 +133,10 @@ as environment variables and can be used in the notification script: /usr/bin/printf "%b" $template | mail -s "$NOTIFICATIONTYPE - $HOSTDISPLAYNAME - $SERVICEDISPLAYNAME is $SERVICESTATE" $USEREMAIL -> **Best Practice** -> -> While it's possible to specify the entire notification command right -> in the NotificationCommand object it is generally advisable to create a -> shell script in the `/etc/icinga2/scripts` directory and have the -> NotificationCommand object refer to that. +While it's possible to specify the entire notification command right +in the NotificationCommand object it is generally advisable to create a +shell script in the `/etc/icinga2/scripts` directory and have the +NotificationCommand object refer to that. ### Event Commands @@ -167,10 +151,8 @@ Common use case scenarios are a failing HTTP check requiring an immediate restart via event command, or if an application is locked and requires a restart upon detection. -> **Note** -> -> `EventCommand` objects require the ITL template `plugin-event-command` -> to support native plugin based checks. +`EventCommand` objects require the ITL template `plugin-event-command` +to support native plugin based checks. The example below is fictive and not necessarily meant for production use. When the event command is triggered on a service state change, it will diff --git a/doc/3.03-custom-attributes-runtime-macros.md b/doc/3.03-custom-attributes-runtime-macros.md index 90e427fec..2c4df4bdd 100644 --- a/doc/3.03-custom-attributes-runtime-macros.md +++ b/doc/3.03-custom-attributes-runtime-macros.md @@ -14,11 +14,9 @@ which use custom attributes to format their output. > Custom attributes are identified by the 'vars' dictionary attribute as short name. > Accessing the different attribute keys is possible using the '.' accessor. -> **Note** -> -> Custom attributes in command definitions or performance data templates are evaluated at -> runtime when executing a command. These custom attributes cannot be used elsewhere -> (e.g. in other configuration attributes). +Custom attributes in command definitions or performance data templates are evaluated at +runtime when executing a command. These custom attributes cannot be used elsewhere +(e.g. in other configuration attributes). Here is an example of a command definition which uses user-defined custom attributes: @@ -43,15 +41,6 @@ Here is an example of a command definition which uses user-defined custom attrib vars.timeout = 0 } -> **Note** -> -> If you have previously used Icinga 1.x you may already be familiar with -> user and argument macros (e.g., `USER1` or `ARG1`) and custom variables -> (e.g., `_COMMUNITY public`). Unlike in Icinga 1.x macros may have arbitrary -> names and arguments are no longer specified in the `check_command` setting. -> Custom variables are available as custom attributes in the `vars` dictionary -> without the `_` prefix. - Custom attribute names used at runtime must be enclosed in two `$` signs, e.g. `$address$`. When using the `$` sign as single character, you need to escape it with an additional dollar sign (`$$`). @@ -204,10 +193,6 @@ users: The following macros are available in all executed commands: -> **Note** -> -> Global application runtime macros require the `icinga.` prefix. - Name | Description -----------------------|-------------- icinga.timet | Current UNIX timestamp. diff --git a/doc/3.04-notifications.md b/doc/3.04-notifications.md index 9669c91fa..fb5a1e776 100644 --- a/doc/3.04-notifications.md +++ b/doc/3.04-notifications.md @@ -29,23 +29,14 @@ The user `icingaadmin` in the example below will get notified only on `WARNING` } } -> **Note** -> -> If you don't set the `notification_state_filter` and `notification_type_filter` -> configuration attributes for the `User` object, all states and types will be -> notified. -> Recovery notifications require the state filter `StateFilterOK`. +If you don't set the `notification_state_filter` and `notification_type_filter` +configuration attributes for the `User` object, all states and types will be +notified. You should choose which information you (and your notified users) are interested in case of emergency, and also which information does not provide any value to you and your environment. -> **Note** -> -> The chain of attribute inheritance including the (additive) vars dictionary for -> notifications will allow granular custom attributes for every specific use case. - - There are various custom attributes available at runtime execution of the `NotificationCommand`. The example below may or may not fit your needs. @@ -102,9 +93,7 @@ TODO notification_period = "24x7" } -> **Note** -> -> The `TimePeriod` `24x7` is shipped as example configuration with Icinga 2. +The time period `24x7` is shipped as example configuration with Icinga 2. Use the `apply` keyword to create `Notification` objects for your services: @@ -117,11 +106,9 @@ Use the `apply` keyword to create `Notification` objects for your services: assign where service.name == "mysql" } -> **Note** -> -> Instead of assigning users to notifications, you can also add the `user_groups` -> attribute with a list of user groups to the `Notification` object. Icinga 2 will -> resolve all group members and send notifications to all of them. +Instead of assigning users to notifications, you can also add the `user_groups` +attribute with a list of user groups to the `Notification` object. Icinga 2 will +resolve all group members and send notifications to all of them. ### Notification Escalations @@ -138,11 +125,6 @@ Using templates you can share the basic notification attributes such as users or Using the example from above, you can define additional users being escalated for sms notifications between start and end time. -> **Note** -> -> `notification_state_filter` and `notification_type_filter` configuration attributes -> are not set in this example. - object User "icinga-oncall-2nd-level" { display_name = "Icinga 2nd Level" enable_notifications = true @@ -158,12 +140,12 @@ notifications between start and end time. } } -Define an additional `NotificationCommand` for sms notifications. +Define an additional `NotificationCommand` for SMS notifications. > **Note** > -> The example is not complete as there are many different sms providers. -> Please note that sending sms notifications will require an sms provider +> The example is not complete as there are many different SMS providers. +> Please note that sending SMS notifications will require an SMS provider > or local hardware with a sim card active. object NotificationCommand "sms-notification" { @@ -172,7 +154,7 @@ Define an additional `NotificationCommand` for sms notifications. The two new notification escalations are added onto the host `localhost` and its service `ping4` using the `generic-notification` template. -The user `icinga-oncall-2nd-level` will get notified by sms (`sms-notification` +The user `icinga-oncall-2nd-level` will get notified by SMS (`sms-notification` command) after `30m` until `1h`. > **Note** @@ -220,12 +202,10 @@ notified, but only for one hour (`2h` as `end` key for the `times` dictionary). assign where service.name == "ping4" } -> **Note** -> -> Instead of assigning users to notifications, you can also add the `user_groups` -> attribute with a list of user groups to the `Notification` object. Icinga 2 will -> resolve all group members and send notifications and notification escalations to -> all of them. +Instead of assigning users to notifications, you can also add the `user_groups` +attribute with a list of user groups to the `Notification` object. Icinga 2 will +resolve all group members and send notifications and notification escalations to +all of them. ### First Notification Delay @@ -245,19 +225,11 @@ end time for this notification. assign where service.name == "ping4" } -> **Note** -> -> In Icinga 1.x the attribute is called `first_notification_delay`. - ### Notification Filters by State and Type If there are no notification state and type filter attributes defined at the `Notification` or `User` object Icinga 2 assumes that all states and types are being notified. -> **Note** -> -> In order to notify on problem states, you still need the type filter `NotificationFilterProblem`. - Available state and type filters for notifications are: template Notification "generic-notification" { @@ -276,8 +248,6 @@ Available state and type filters for notifications are: NotificationFilterDowntimeRemoved) } -> **Note** -> -> 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. +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. diff --git a/doc/3.06-groups.md b/doc/3.06-groups.md index 149331c21..0d3f7f5f8 100644 --- a/doc/3.06-groups.md +++ b/doc/3.06-groups.md @@ -15,34 +15,21 @@ alert dashboard, first create the hostgroup: Then add your hosts to this hostgroup + template Host "windows-server" { + groups += [ "windows" ] + } + object Host "mssql-srv1" { - groups = [ "windows" ] + import "windows-server" + vars.mssql_port = 1433 } object Host "mssql-srv2" { - groups = [ "windows" ] - vars.mssql_port = 1433 - } - -> **Best Practice** -> -> Add the hostgroup membership into generic templates combined with -> other attributes and let all windows hosts inherit from that template. -> You can also define multiple group memberships. + import "windows-server" - template Host "windows-mssql-template" { - groups = [ "windows" ] vars.mssql_port = 1433 } - - object Host "mssql-srv1" { - import "windows-mssql-template" - } - - object Host "mssql-srv2" { - import "windows-mssql-template" - } This can be done for service and user groups the same way. Additionally the user groups are associated as attributes in `Notification` objects. diff --git a/doc/3.08-external-commands.md b/doc/3.08-external-commands.md index 18ff0bc52..83b88b6d0 100644 --- a/doc/3.08-external-commands.md +++ b/doc/3.08-external-commands.md @@ -23,18 +23,14 @@ a forced service check: Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885 Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping4' -> **Note** -> -> The command pipe file is owned by the group `icingacmd` with read/write -> permissions. Add your webserver's user to the group `icingacmd` to -> enable sending commands to Icinga 2 through your web interface. +By default the command pipe file is owned by the group `icingacmd` with read/write +permissions. Add your webserver's user to the group `icingacmd` to +enable sending commands to Icinga 2 through your web interface: # usermod -G -a icingacmd www-data -> **Note** -> -> Debian packages use `nagios` as default user/group. Therefore change `icingacmd` to -> `nagios`. +Debian packages use `nagios` as the default user and group name. Therefore change `icingacmd` to +`nagios`. ### External Command List diff --git a/doc/3.11-performance-data.md b/doc/3.11-performance-data.md index 5c5364e14..69f08df8d 100644 --- a/doc/3.11-performance-data.md +++ b/doc/3.11-performance-data.md @@ -34,14 +34,6 @@ the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.` and External collectors need to parse the rotated performance data files and then remove the processed files. -> **Note** -> -> If you enable this feature by accident and no collector daemon is processing -> these files, the filesystem's inodes may run out. Make sure to watch the -> `localhost` service check `disks` and define your own inode warning -> and critical thresholds. - - ### Graphite Carbon Cache Writer While there are some Graphite collector scripts and daemons like Graphios available for diff --git a/doc/3.12-status-data.md b/doc/3.12-status-data.md index 3051504ff..ebecc0ff2 100644 --- a/doc/3.12-status-data.md +++ b/doc/3.12-status-data.md @@ -13,8 +13,3 @@ Icinga 1.x Classic UI requires this data set as part of its backend. > > If you are not using any web interface or addon which uses these files > you can safely disable this feature. - -> **Note** -> -> Semicolons in the check result output are replaced with colons because -> they are used as attribute separators. diff --git a/doc/3.13-compat-logging.md b/doc/3.13-compat-logging.md index 0028d09b7..497188d30 100644 --- a/doc/3.13-compat-logging.md +++ b/doc/3.13-compat-logging.md @@ -44,7 +44,3 @@ existing log parsers. [1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test| [1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test -> **Note** -> -> Semicolons in the check result output are replaced with colons because -> they are used as attribute separators. diff --git a/doc/3.15-monitoring-remote-clients.md b/doc/3.15-monitoring-remote-clients.md index 08a6fa1f1..cb150fc09 100644 --- a/doc/3.15-monitoring-remote-clients.md +++ b/doc/3.15-monitoring-remote-clients.md @@ -69,10 +69,8 @@ the required plugins and command definitions. Icinga 2 calls the `check_nrpe` plugin binary in order to query the configured command on the remote client. -> **Note** -> -> The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe` -> can be embedded into the Icinga 2 `CheckCommand` configuration syntax. +The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe` +can be embedded into the Icinga 2 `CheckCommand` configuration syntax. Example: @@ -106,10 +104,8 @@ known for its magnificent Windows support. There are alternatives like the WMI i but using `NSClient++` will allow you to run local scripts similar to check plugins fetching the required output and performance counters. -> **Note** -> -> The NSClient++ agent uses its own proprietary configuration format while `check_nt` -> can be embedded into the Icinga 2 `CheckCommand` configuration syntax. +The NSClient++ agent uses its own configuration format while `check_nt` +can be embedded into the Icinga 2 `CheckCommand` configuration syntax. Example: @@ -150,7 +146,7 @@ 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 ** +> **Note** > > The format of the `NSClient++` configuration file has changed from 0.3.x to 0.4! diff --git a/doc/4.1-configuration-syntax.md b/doc/4.1-configuration-syntax.md index 0cc3231ff..8c5ce5c54 100644 --- a/doc/4.1-configuration-syntax.md +++ b/doc/4.1-configuration-syntax.md @@ -29,15 +29,13 @@ them with a semi-colon: The semi-colon after the last element (i.e. `address6`) may be omitted. -> **Note** -> -> Exclamation marks (!) are not permitted in object names. - Each object is uniquely identified by its type (`Host`) and name (`host1.example.org`). Some types have composite names, e.g. the `Service` type which uses the `host_name` attribute and the name you specified to generate its object name. +Exclamation marks (!) are not permitted in object names. + Objects can contain a comma-separated list of property declarations. Instead of commas semi-colons may also be used. The following data types are available for property values: @@ -107,10 +105,8 @@ Example. a multi-line string.}}} -> **Note** -> -> Unlike in ordinary strings special characters do not have to be escaped -> in multi-line string literals. +Unlike in ordinary strings special characters do not have to be escaped +in multi-line string literals. #### Boolean Literals @@ -135,17 +131,13 @@ Example: port = 443 } -> **Note** -> -> Identifiers may not contain certain characters (e.g. space) or start -> with certain characters (e.g. digits). If you want to use a dictionary -> key that is not a valid identifier you can put the key in double -> quotes. +Identifiers may not contain certain characters (e.g. space) or start +with certain characters (e.g. digits). If you want to use a dictionary +key that is not a valid identifier you can put the key in double +quotes. -> **Note** -> -> Setting a dictionary key to null causes the key and its value to be -> removed from the dictionary. +Setting a dictionary key to null causes the key and its value to be +removed from the dictionary. #### Array @@ -158,10 +150,8 @@ Example: [ "hello", 42 ] -> **Note** -> -> An array may simultaneously contain values of different types, such as -> strings and numbers. +An array may simultaneously contain values of different types, such as +strings and numbers. #### Operators @@ -358,10 +348,8 @@ using the `template` keyword. Unlike ordinary objects templates are not instantiated at run-time. Parent objects do not necessarily have to be templates, however in general they are. -> **Note** -> -> The `vars` dictionary for the `localhost` object contains all three -> custom attributes and the custom attribute `color` has the value `"blue"`. +The `vars` dictionary for the `localhost` object contains all three +custom attributes and the custom attribute `color` has the value `"blue"`. Parent objects are resolved in the order they're specified using the `import` keyword. @@ -408,11 +396,9 @@ Notification | Service | host, service ScheduledDowntime | Host | host ScheduledDowntime | Service | host, service -> **Note** -> -> Any valid config attribute can be accessed using the `host` and `service` -> variables. For example, `host.vars.address` would return the host's -> "address" custom attribute - or null if it doesn't have that custom attribute. +Any valid config attribute can be accessed using the `host` and `service` +variables. For example, `host.vars.address` would return the host's +"address" custom attribute - or null if it doesn't have that custom attribute. ### Boolean Values @@ -457,9 +443,7 @@ Example: include "some/other/file.conf" include "conf.d/*.conf" -> **Note** -> -> Wildcard includes are not recursive. +Wildcard includes are not recursive. Icinga also supports include search paths similar to how they work in a C/C++ compiler: @@ -500,11 +484,6 @@ Example: library "snmphelper" -> **Note** -> -> The `icinga` and `methods` libraries is automatically loaded at startup. -> You don't need to load them manually. -