capability of writing performance data directly into a Graphite TCP socket simplifying realtime
monitoring graphs.
-* Native support for writing log events to [GELF](#gelf-writer) receivers (graylog2, Logstash)
+* Native support for writing log events to [GELF](11-object-types.md#objecttype-gelfwriter) receivers (graylog2, Logstash)
Icinga 2 will write all check result, state change and notification event logs into a defined
[GELF](3-monitoring-basics.md#gelfwriter) input receiver. Natively provided by [graylog2](http://www.graylog2.org),
Supported with [duration literals](9-language-reference.md#duration-literals) for interval
attributes, [expression operators](9-language-reference.md#expression-operators), [function calls](9-language-reference.md#function-calls) for
pattern and regex matching and (global) [constants](9-language-reference.md#constants).
-[Check command configuration](#plugin-check-commands) for common plugins is shipped with Icinga 2 as part of the [Icinga Template Library](#itl).
+[Check command configuration](12-icinga-template-library.md#plugin-check-commands) for common plugins is shipped with Icinga 2 as part of the [Icinga Template Library](12-icinga-template-library.md#icinga-template-library).
* Revamped Commands
* Embedded Health Checks
-No more external statistic tool but an [instance](#itl-icinga) and [cluster](#itl-cluster) health
+No more external statistic tool but an [instance](12-icinga-template-library.md#itl-icinga) and [cluster](12-icinga-template-library.md#itl-icinga-cluster) health
check providing direct statistics as performance data for your graphing addon, for example Graphite.
* Compatibility with Icinga 1.x
All known interfaces are optionally available: [status files](3-monitoring-basics.md#status-data), [logs](3-monitoring-basics.md#compat-logging),
-[DB IDO](#configuring-ido) MySQL/PostgreSQL, [performance data](3-monitoring-basics.md#performance-data),
+[DB IDO](2-getting-started.md#configuring-db-ido) MySQL/PostgreSQL, [performance data](3-monitoring-basics.md#performance-data),
[external command pipe](3-monitoring-basics.md#external-commands) and for migration reasons a
[checkresult file reader](3-monitoring-basics.md#check-result-files) too.
All [Monitoring Plugins](2-getting-started.md#setting-up-check-plugins) can be integrated into Icinga 2 with
check_interval = len(MyGroups) * 1m
}
-A list of available functions is available in the [Built-in functions and methods](#builtin-functions) chapter.
+A list of available functions is available in the [Library Reference](10-library-reference.md#library-reference) chapter.
## <a id="dictionary-operators"></a> Assignments
config compiler to search the include search paths for the specified
file. By default $PREFIX/share/icinga2/include is included in the list of search
paths. Additional include search paths can be added using
-[command-line options](#cmdline).
+[command-line options](5-cli-commands.md#config-include-path).
Wildcards are not permitted when using angle brackets.
The example host will show you how to
* define http vhost attributes for the `http` service apply rule defined
-in [services.conf](#services.conf).
+in [services.conf](2-getting-started.md#services-conf).
* define disks (all, specific `/`) and their attributes for the `disk`
-service apply rule defined in [services.conf](#services.conf).
+service apply rule defined in [services.conf](2-getting-started.md#services-conf).
* define notification types (`mail`) and set the groups attribute. This
will be used by notification apply rules in [notifications.conf](notifications-conf).
If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can
uncomment the http vhost attributes and relaod Icinga 2. The apply
-rules in [services.conf](#services.conf) will automatically
+rules in [services.conf](2-getting-started.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
check.
The Debian packages also ship an additional `apt` service check applied to the local host.
The command object `icinga` for the embedded health check is provided by the
-[Icinga Template Library (ITL)](#itl) while `http_ip`, `ssh`, `load`, `processes`,
+[Icinga Template Library (ITL)](12-icinga-template-library.md#icinga-template-library) while `http_ip`, `ssh`, `load`, `processes`,
`users` and `disk` are all provided by the [Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands)
which we enabled earlier by including the `itl` and `plugins` configuration file.
By setting the `user_groups` to the value provided by the
respective [host.vars.notification.mail](2-getting-started.md#hosts-conf) attribute we'll
-implicitely use the`icingaadmins` UserGroup defined in [users.conf](#users.conf).
+implicitely use the`icingaadmins` UserGroup defined in [users.conf](2-getting-started.md#users-conf).
apply Notification "mail-icingaadmin" to Host {
import "mail-host-notification"
RHEL/CentOS 7 and Fedora 20 prefer MariaDB over MySQL:
# yum install mariadb-server mariadb
- # systemctl enable mariadb.service
- # systemctl start mariadb.service
+ # systemctl enable mariadb
+ # systemctl start mariadb
SUSE:
RHEL/CentOS 7 and Fedora 20 use [systemd](2-getting-started.md#systemd-service):
# yum install postgresql-server postgresql
- # systemctl enable postgresql.service
- # systemctl start postgresql.service
+ # systemctl enable postgresql
+ # systemctl start postgresql
SUSE:
RHEL/CentOS 7 and Fedora 20:
- # systemctl restart icinga2.service
+ # systemctl restart icinga2
### <a id="configuring-db-ido-postgresql"></a> Configuring DB IDO PostgreSQL
RHEL/CentOS 7 and Fedora 20:
- # systemctl restart icinga2.service
+ # systemctl restart icinga2
### <a id="setting-up-external-command-pipe"></a> Setting Up External Command Pipe
RHEL/CentOS 7 and Fedora 20:
- # systemctl restart icinga2.service
+ # systemctl restart icinga2
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
> Packages will do that automatically. Verify that by running `id <your-webserver-user>` and skip this
> step.
-## <a id="setting-up-livestatus"></a> Setting up Livestatus
-
-The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
-implements a query protocol that lets users query their Icinga instance for
-status information. It can also be used to send commands.
-
-> **Tip**
->
-> Only install the Livestatus feature if your web interface or addon requires
-> you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
-> [Icinga Classic UI](2-getting-started.md#setting-up-icinga-classic-ui) and [Icinga Web](2-getting-started.md#setting-up-icinga-web)
-> do not use Livestatus as backend.
-
-The Livestatus component that is distributed as part of Icinga 2 is a
-re-implementation of the Livestatus protocol which is compatible with MK
-Livestatus.
-
-Details on the available tables and attributes with Icinga 2 can be found
-in the [Livestatus](3-monitoring-basics.md#livestatus) section.
-
-You can enable Livestatus using icinga2 feature enable:
-
- # icinga2 feature enable livestatus
-
-After that you will have to restart Icinga 2:
-
-Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
-
- # service icinga2 restart
-
-RHEL/CentOS 7 and Fedora 20:
-
- # systemctl restart icinga2.service
-
-By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
-
-In order for queries and commands to work you will need to add your query user
-(e.g. your web server) to the `icingacmd` group:
-
- # usermod -a -G icingacmd www-data
-
-The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
-`nagios` if you're using Debian.
-
-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
-are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
-`compat_log_path` configuration attribute.
-
- # icinga2 feature enable compatlog
-
## <a id="setting-up-icinga2-user-interfaces"></a> Setting up Icinga 2 User Interfaces
Icinga 2 can be used with [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2), using
Icinga 2 can write to the same schema supplied by `Icinga IDOUtils 1.x` which
is an explicit requirement to run `Icinga Web` next to the external command pipe.
-Therefore you need to setup the [DB IDO feature](#configuring-ido) remarked in the previous sections.
+Therefore you need to setup the [DB IDO feature](2-getting-started.md#configuring-db-ido) remarked in the previous sections.
#### <a id="installing-icinga-web"></a> Installing Icinga Web 1.x
You can later use them for applying assign/ignore rules, or export them into external interfaces.
* 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](#using-templates) chapter.
+Details can be found in the [using templates](3-monitoring-basics.md#object-inheritance-using-templates) chapter.
* Apply rules may overlap. Keep a central place (for example, [services.conf](2-getting-started.md#services-conf) or [notifications.conf](2-getting-started.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.
import "cust-xy-notification"
assign where match("*has gold support 24x7*", service.notes) && (host.vars.customer == "customer-xy" || host.vars.always_notify == true
- ignore where match("*internal", host.name) || (service.vars.priority < 2 && host.is_clustered == true)
+ ignore where match("*internal", host.name) || (service.vars.priority < 2 && host.vars.is_clustered == true)
}
vars.hosting["xyz"] = {
http_uri = "/shop"
- customer_name = "Customer xyz"
- customer_id = "7568"
- support_contract = "gold"
+ customer_name = "Customer xyz"
+ customer_id = "7568"
+ support_contract = "gold"
}
vars.hosting["abc"] = {
http_uri = "/shop"
- customer_name = "Customer xyz"
- customer_id = "7568"
- support_contract = "silver"
+ customer_name = "Customer xyz"
+ customer_id = "7568"
+ support_contract = "silver"
}
}
users = [ "noc-xy", "mgmt-xy" ]
assign where match("*has gold support 24x7*", service.notes) && (host.vars.customer == "customer-xy" || host.vars.always_notify == true
- ignore where match("*internal", host.name) || (service.vars.priority < 2 && host.is_clustered == true)
+ ignore where match("*internal", host.name) || (service.vars.priority < 2 && host.vars.is_clustered == true)
}
* The host/service is in a [soft state](3-monitoring-basics.md#hard-soft-states)
* The host/service state changes into a [hard state](3-monitoring-basics.md#hard-soft-states)
-* The host/service state recovers from a [soft or hard state](#hard-soft-states) to [OK](3-monitoring-basics.md#service-states)/[Up](3-monitoring-basics.md#host-states)
+* The host/service state recovers from a [soft or hard state](3-monitoring-basics.md#hard-soft-states) to [OK](3-monitoring-basics.md#service-states)/[Up](3-monitoring-basics.md#host-states)
[EventCommand](11-object-types.md#objecttype-eventcommand) objects are referenced by
[Host](11-object-types.md#objecttype-host) and [Service](11-object-types.md#objecttype-service) objects
There are several ways of using custom attributes with [apply rules](3-monitoring-basics.md#using-apply):
-* As simple attribute literal ([number](#numeric-literal), [string](#string-literal),
-[boolean](#boolean-literal)) for expression conditions (`assign where`, `ignore where`)
+* As simple attribute literal ([number](9-language-reference.md#numeric-literals), [string](9-language-reference.md#string-literals),
+[boolean](9-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`)
* As [array](9-language-reference.md#array) or [dictionary](9-language-reference.md#dictionary) attribute with nested values
(e.g. dictionaries in dictionaries) in [apply for](3-monitoring-basics.md#using-apply-for) rules.
configuration and status information into a database. The IDO database is used
by a number of projects including Icinga Web 1.x and 2.
-Details on the installation can be found in the [Getting Started](#configuring-ido)
+Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido)
chapter. Details on the configuration can be found in the
[IdoMysqlConnection](11-object-types.md#objecttype-idomysqlconnection) and
-[IdoPgsqlConnection](#objecttype-idoPgsqlconnection)
+[IdoPgsqlConnection](11-object-types.md#objecttype-idopgsqlconnection)
object configuration documentation.
The DB IDO feature supports [High Availability](4-monitoring-remote-systems.md#high-availability-db-ido) in
the Icinga 2 cluster.
A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](13-appendix.md#schema-db-ido).
-## <a id="livestatus"></a> Livestatus
-
-The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
-implements a query protocol that lets users query their Icinga instance for
-status information. It can also be used to send commands.
-
-Details on the installation can be found in the [Getting Started](2-getting-started.md#setting-up-livestatus)
-chapter.
-
-### <a id="livestatus-sockets"></a> Livestatus Sockets
-
-Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
-
-* Unix socket (default)
-* TCP socket
-
-Details on the configuration can be found in the [LivestatusListener](11-object-types.md#objecttype-livestatuslistener)
-object configuration.
-
-### <a id="livestatus-get-queries"></a> Livestatus GET Queries
-
-> **Note**
->
-> All Livestatus queries require an additional empty line as query end identifier.
-> The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
-> a unix socket.
-
-There also is a Perl module available in CPAN for accessing the Livestatus socket
-programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
-
-
-Example using the unix socket:
-
- # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
-
-Example using the tcp socket listening on port `6558`:
-
- # echo -e 'GET services\n' | netcat 127.0.0.1 6558
-
- # cat servicegroups <<EOF
- GET servicegroups
-
- EOF
-
- (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
-
-
-### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
-
-A list of available external commands and their parameters can be found [here](13-appendix.md#external-commands-list-detail)
-
- $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
-
-
-### <a id="livestatus-filters"></a> Livestatus Filters
-
-and, or, negate
-
- Operator | Negate | Description
- ----------|------------------------
- = | != | Equality
- ~ | !~ | Regex match
- =~ | !=~ | Equality ignoring case
- ~~ | !~~ | Regex ignoring case
- < | | Less than
- > | | Greater than
- <= | | Less than or equal
- >= | | Greater than or equal
-
-
-### <a id="livestatus-stats"></a> Livestatus Stats
-
-Schema: "Stats: aggregatefunction aggregateattribute"
-
- Aggregate Function | Description
- -------------------|--------------
- sum |
- min |
- max |
- avg | sum / count
- std | standard deviation
- suminv | sum (1 / value)
- avginv | suminv / count
- count | ordinary default for any stats query if not aggregate function defined
-
-Example:
-
- GET hosts
- Filter: has_been_checked = 1
- Filter: check_type = 0
- Stats: sum execution_time
- Stats: sum latency
- Stats: sum percent_state_change
- Stats: min execution_time
- Stats: min latency
- Stats: min percent_state_change
- Stats: max execution_time
- Stats: max latency
- Stats: max percent_state_change
- OutputFormat: json
- ResponseHeader: fixed16
-
-### <a id="livestatus-output"></a> Livestatus Output
-
-* CSV
-
-CSV Output uses two levels of array separators: The members array separator
-is a comma (1st level) while extra info and host|service relation separator
-is a pipe (2nd level).
-
-Separators can be set using ASCII codes like:
-
- Separators: 10 59 44 124
-
-* JSON
-
-Default separators.
-
-### <a id="livestatus-error-codes"></a> Livestatus Error Codes
-
- Code | Description
- ----------|--------------
- 200 | OK
- 404 | Table does not exist
- 452 | Exception on query
-
-### <a id="livestatus-tables"></a> Livestatus Tables
-
- Table | Join |Description
- --------------|-----------|----------------------------
- hosts | | host config and status attributes, services counter
- hostgroups | | hostgroup config, status attributes and host/service counters
- services | hosts | service config and status attributes
- servicegroups | | servicegroup config, status attributes and service counters
- contacts | | contact config and status attributes
- contactgroups | | contact config, members
- commands | | command name and line
- status | | programstatus, config and stats
- comments | services | status attributes
- downtimes | services | status attributes
- timeperiods | | name and is inside flag
- endpoints | | config and status attributes
- log | services, hosts, contacts, commands | parses [compatlog](11-object-types.md#objecttype-compatlogger) and shows log attributes
- statehist | hosts, services | parses [compatlog](11-object-types.md#objecttype-compatlogger) and aggregates state change attributes
-
-The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
-
-A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](13-appendix.md#schema-livestatus).
-
-
## <a id="check-result-files"></a> Check Result Files
Icinga 1.x writes its check result files to a temporary spool directory
If the remote service is available using a network protocol and port,
and a [check plugin](2-getting-started.md#setting-up-check-plugins) is available, you don't
necessarily need a local client installed. Rather choose a plugin and
-configure all parameters and thresholds. The [Icinga 2 Template Library](#itl)
+configure all parameters and thresholds. The [Icinga 2 Template Library](12-icinga-template-library.md#icinga-template-library)
already ships various examples like
* [ping4](12-icinga-template-library.md#plugin-check-command-ping4), [ping6](12-icinga-template-library.md#plugin-check-command-ping6),
-[fping4](#plugin-check-command-fping4), [fping6](12-icinga-template-library.md#plugin-check-command-fping6), [hostalive](12-icinga-template-library.md#plugin-check-command-hostalive)
-* [tcp](#plugin-check-command-tcp), [udp](12-icinga-template-library.md#plugin-check-command-udp), [ssl](12-icinga-template-library.md#plugin-check-command-ssl)
+[fping4](12-icinga-template-library.md#plugin-check-command-fping4), [fping6](12-icinga-template-library.md#plugin-check-command-fping6), [hostalive](12-icinga-template-library.md#plugin-check-command-hostalive)
+* [tcp](12-icinga-template-library.md#plugin-check-command-tcp), [udp](12-icinga-template-library.md#plugin-check-command-udp), [ssl](12-icinga-template-library.md#plugin-check-command-ssl)
* [http](12-icinga-template-library.md#plugin-check-command-http), [ftp](12-icinga-template-library.md#plugin-check-command-ftp)
* [smtp](12-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](12-icinga-template-library.md#plugin-check-command-ssmtp),
[imap](12-icinga-template-library.md#plugin-check-command-imap), [simap](12-icinga-template-library.md#plugin-check-command-simap),
[pop](12-icinga-template-library.md#plugin-check-command-pop), [spop](12-icinga-template-library.md#plugin-check-command-spop)
-* [ntp_time](#plugin-check-command-ntp_time)
+* [ntp_time](12-icinga-template-library.md#plugin-check-command-ntp-time)
* [ssh](12-icinga-template-library.md#plugin-check-command-ssh)
-* [dns](#plugin-check-command-dns), [dig](12-icinga-template-library.md#plugin-check-command-dig), [dhcp](12-icinga-template-library.md#plugin-check-command-dhcp)
+* [dns](12-icinga-template-library.md#plugin-check-command-dns), [dig](12-icinga-template-library.md#plugin-check-command-dig), [dhcp](12-icinga-template-library.md#plugin-check-command-dhcp)
There are numerous check plugins contributed by community members available
on the internet. If you found one for your requirements, [integrate them into Icinga 2](3-monitoring-basics.md#command-plugin-integration).
* Generate a new CSR, sign it with the local CA and copying it into `/etc/icinga2/pki`
* Generate a local zone and endpoint configuration for this master based on FQDN
* Enabling the API feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](#constants.conf)
+* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](2-getting-started.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.
(based on FQDN)
* Disabling the notification feature for this client
* Enabling the API feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` constant in [constants.conf](#constants.conf)
+* Setting the `NodeName` constant in [constants.conf](2-getting-started.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.
# service icinga2 reload
Using systemd:
- # systemctl reload icinga2.service
-
+ # systemctl reload icinga2
#### <a id="icinga2-remote-monitoring-master-discovery-blacklist-whitelist"></a> Blacklist/Whitelist for Clients on the Master
The SNMP daemon runs on the remote system and answers SNMP queries by plugin
binaries. The [Monitoring Plugins package](2-getting-started.md#setting-up-check-plugins) ships
-the `check_snmp` plugin binary, but there are plenty of [existing plugins](#integrate-additional-plugins)
+the `check_snmp` plugin binary, but there are plenty of [existing plugins](6-addons-plugins.md#plugins)
for specific use cases already around, for example monitoring Cisco routers.
The following example uses the [SNMP ITL](12-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just
### <a id="cluster-health-check"></a> Cluster Health Check
-The Icinga 2 [ITL](#itl) ships an internal check command checking all configured
+The Icinga 2 [ITL](12-icinga-template-library.md#icinga-template-library) ships an internal check command checking all configured
`EndPoints` in the cluster setup. The check result will become critical if
one or more configured nodes are not connected.
[Global constants](9-language-reference.md#constants) can be set using the `--define` command-line option.
-#### Config Include Path
+#### <a id="config-include-path"> Config Include Path
When including files you can specify that the include search path should be
checked. You can do this by putting your configuration file name in angle
-### <a id="cli-command-daemon"></a> Cli command: Daemon
+### <a id="cli-command-daemon"></a> CLI command: Daemon
The CLI command `daemon` provides the functionality to start/stop Icinga 2.
Furthermore it provides the [configuration validation](5-cli-commands.md#config-validation).
is returned. More details in the [configuration validation](5-cli-commands.md#config-validation) chapter.
-### <a id="cli-command-feature"></a> Cli command: Feature
+### <a id="cli-command-feature"></a> CLI command: Feature
The CLI commands for `enable` and `disable` feature support bash auto-completion
and will only suggest features for the corresponding context. Like disabling a
api command debuglog graphite icingastatus ido-pgsql --library --log-level statusdata --version
--color compatlog --define --help ido-mysql --include livestatus perfdata syslog
-### <a id="cli-command-node"></a> Cli command: Node
+### <a id="cli-command-node"></a> CLI command: Node
Provides the functionality to install and manage master and client
nodes in a [remote monitoring ](4-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
Icinga home page: <https://www.icinga.org/>
-### <a id="cli-command-object"></a> Cli command: Object
+### <a id="cli-command-object"></a> CLI command: Object
The `object` CLI command can be used to list all configuration objects and their
attributes. The command also shows where each of the attributes was modified.
-### <a id="cli-command-pki"></a> Cli command: Pki
+### <a id="cli-command-pki"></a> CLI command: Pki
Provides the CLI commands to
Icinga home page: <https://www.icinga.org/>
-### <a id="cli-command-repository"></a> Cli command: Repository
+### <a id="cli-command-repository"></a> CLI command: Repository
Provides the functionality to manage the Icinga 2 configuration repository in
`/etc/icinga2/repository.d`. All changes are logged and must be committed or
-### <a id="cli-command-variable"></a> Cli command: Variable
+### <a id="cli-command-variable"></a> CLI command: Variable
Lists all configured variables (constants) in a similar fasion like [object list](5-cli-commands.md#cli-command-object).
--- /dev/null
+## <a id="setting-up-livestatus"></a> Setting up Livestatus
+
+The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
+implements a query protocol that lets users query their Icinga instance for
+status information. It can also be used to send commands.
+
+> **Tip**
+>
+> Only install the Livestatus feature if your web interface or addon requires
+> you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
+> [Icinga Classic UI](2-getting-started.md#setting-up-icinga-classic-ui) and [Icinga Web](2-getting-started.md#setting-up-icinga-web)
+> do not use Livestatus as backend.
+
+The Livestatus component that is distributed as part of Icinga 2 is a
+re-implementation of the Livestatus protocol which is compatible with MK
+Livestatus.
+
+Details on the available tables and attributes with Icinga 2 can be found
+in the [Livestatus](3-monitoring-basics.md#livestatus) section.
+
+You can enable Livestatus using icinga2 feature enable:
+
+ # icinga2 feature enable livestatus
+
+After that you will have to restart Icinga 2:
+
+Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
+
+ # service icinga2 restart
+
+RHEL/CentOS 7 and Fedora 20:
+
+ # systemctl restart icinga2
+
+By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
+
+In order for queries and commands to work you will need to add your query user
+(e.g. your web server) to the `icingacmd` group:
+
+ # usermod -a -G icingacmd www-data
+
+The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
+`nagios` if you're using Debian.
+
+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
+are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
+`compat_log_path` configuration attribute.
+
+ # icinga2 feature enable compatlog
+
+
+### <a id="livestatus-sockets"></a> Livestatus Sockets
+
+Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
+
+* Unix socket (default)
+* TCP socket
+
+Details on the configuration can be found in the [LivestatusListener](11-object-types.md#objecttype-livestatuslistener)
+object configuration.
+
+### <a id="livestatus-get-queries"></a> Livestatus GET Queries
+
+> **Note**
+>
+> All Livestatus queries require an additional empty line as query end identifier.
+> The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
+> a unix socket.
+
+There also is a Perl module available in CPAN for accessing the Livestatus socket
+programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
+
+
+Example using the unix socket:
+
+ # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
+
+Example using the tcp socket listening on port `6558`:
+
+ # echo -e 'GET services\n' | netcat 127.0.0.1 6558
+
+ # cat servicegroups <<EOF
+ GET servicegroups
+
+ EOF
+
+ (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
+
+
+### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
+
+A list of available external commands and their parameters can be found [here](13-appendix.md#external-commands-list-detail)
+
+ $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
+
+
+### <a id="livestatus-filters"></a> Livestatus Filters
+
+and, or, negate
+
+ Operator | Negate | Description
+ ----------|------------------------
+ = | != | Equality
+ ~ | !~ | Regex match
+ =~ | !=~ | Equality ignoring case
+ ~~ | !~~ | Regex ignoring case
+ < | | Less than
+ > | | Greater than
+ <= | | Less than or equal
+ >= | | Greater than or equal
+
+
+### <a id="livestatus-stats"></a> Livestatus Stats
+
+Schema: "Stats: aggregatefunction aggregateattribute"
+
+ Aggregate Function | Description
+ -------------------|--------------
+ sum |
+ min |
+ max |
+ avg | sum / count
+ std | standard deviation
+ suminv | sum (1 / value)
+ avginv | suminv / count
+ count | ordinary default for any stats query if not aggregate function defined
+
+Example:
+
+ GET hosts
+ Filter: has_been_checked = 1
+ Filter: check_type = 0
+ Stats: sum execution_time
+ Stats: sum latency
+ Stats: sum percent_state_change
+ Stats: min execution_time
+ Stats: min latency
+ Stats: min percent_state_change
+ Stats: max execution_time
+ Stats: max latency
+ Stats: max percent_state_change
+ OutputFormat: json
+ ResponseHeader: fixed16
+
+### <a id="livestatus-output"></a> Livestatus Output
+
+* CSV
+
+CSV output uses two levels of array separators: The members array separator
+is a comma (1st level) while extra info and host|service relation separator
+is a pipe (2nd level).
+
+Separators can be set using ASCII codes like:
+
+ Separators: 10 59 44 124
+
+* JSON
+
+Default separators.
+
+### <a id="livestatus-error-codes"></a> Livestatus Error Codes
+
+ Code | Description
+ ----------|--------------
+ 200 | OK
+ 404 | Table does not exist
+ 452 | Exception on query
+
+### <a id="livestatus-tables"></a> Livestatus Tables
+
+ Table | Join |Description
+ --------------|-----------|----------------------------
+ hosts | | host config and status attributes, services counter
+ hostgroups | | hostgroup config, status attributes and host/service counters
+ services | hosts | service config and status attributes
+ servicegroups | | servicegroup config, status attributes and service counters
+ contacts | | contact config and status attributes
+ contactgroups | | contact config, members
+ commands | | command name and line
+ status | | programstatus, config and stats
+ comments | services | status attributes
+ downtimes | services | status attributes
+ timeperiods | | name and is inside flag
+ endpoints | | config and status attributes
+ log | services, hosts, contacts, commands | parses [compatlog](11-object-types.md#objecttype-compatlogger) and shows log attributes
+ statehist | hosts, services | parses [compatlog](11-object-types.md#objecttype-compatlogger) and aggregates state change attributes
+
+The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
+
+A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](13-appendix.md#schema-livestatus).
+
# icinga2 feature enable debuglog
# service icinga2 restart
- # tail -f /var/log/icinga2/debug.log
+
+You can find the debug log file in `/var/log/icinga2/debug.log`.
## <a id="list-configuration-objects"></a> List Configuration Objects
[2014-10-15 14:27:19 +0200] information/cli: Parsed 175 objects.
-## <a id="check-command-definitions"></a> Where are the check command definitions
+## <a id="check-command-definitions"></a> Where are the check command definitions?
Icinga 2 ships additional [plugin check command definitions](12-icinga-template-library.md#plugin-check-commands) which are
included using
## <a id="configuration-ignored"></a> Configuration is ignored
-* Make sure that the line(s) are not [commented](9-language-reference.md#comments) (starting with `//` or `#`, or
+* Make sure that the line(s) are not [commented out](9-language-reference.md#comments) (starting with `//` or `#`, or
encapsulated by `/* ... */`).
* Is the configuration file included in [icinga2.conf](2-getting-started.md#icinga2-conf)?
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
-Icinga 2 allows you to import templates using the [import](#import) keyword. If these templates
+Icinga 2 allows you to import templates using the [import](9-language-reference.md#template-imports) keyword. If these templates
contain additional attributes, your objects will automatically inherit them. You can override
or modify these attributes in the current object.
--- /dev/null
+$(document).ready(function() {
+
+ $('a[href^="#"]').on('click',function (e) {
+ e.preventDefault();
+
+ var target = this.hash;
+ var $target = $(target);
+
+ $('html, body').stop().animate({
+ 'scrollTop': $target.offset().top
+ }, 900, 'swing', function () {
+ window.location.hash = target;
+ });
+ });
+
+});
if len(sys.argv) < 2:
print "Syntax: %s <md-files>"
print ""
- print "Updates intra-chapter links in the specified Markdown files."
+ print "Updates inter-chapter links in the specified Markdown files."
sys.exit(1)
anchors = {}
--- /dev/null
+site_name: Icinga 2
+docs_dir: doc
+dev_addr: 0.0.0.0:8000
+pages:
+- [1-about.md, About Icinga 2]
+- [2-getting-started.md, Getting Started]
+- [3-monitoring-basics.md, Monitoring Basics]
+- [4-monitoring-remote-systems.md, Monitoring Remote Systems]
+- [5-cli-commands.md, CLI Commands]
+- [6-addons-plugins.md, Addons and Plugins]
+- [7-livestatus.md, Livestatus]
+- [8-troubleshooting.md, Troubleshooting]
+- [9-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
+- [10-language-reference.md, Language Reference]
+- [11-library-reference.md, Library Reference]
+- [12-object-types.md, Object Types]
+- [13-icinga-template-library.md, Icinga Template Library]
+- [14-appendix.md, Appendix]
+theme: readthedocs
+markdown_extensions: [smarty]
+extra_javascript: [scroll.js]
projects / icinga2 / commitdiff