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](02-getting-started.md#setting-up-icingaweb2)).
-> Icinga Classic UI 1.x and Icinga Web 1.x 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.
+> **Tip**
+>
+> 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
+> Livestatus.
+
Details on the available tables and attributes with Icinga 2 can be found
in the [Livestatus Schema](24-appendix.md#schema-livestatus) section.
After that you will have to restart Icinga 2:
-RHEL/CentOS 7/Fedora, SLES 12, Debian Jessie/Stretch, Ubuntu Xenial:
-
# systemctl restart icinga2
-Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
-
- # service icinga2 restart
-
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
# icinga2 feature enable statusdata
-Icinga 1.x Classic UI requires this data set as part of its backend.
-
-> **Note**
->
-> If you are not using any web interface or addon which uses these files,
-> you can safely disable this feature.
+If you are not using any web interface or addon which uses these files,
+you can safely disable this feature.
## Compat Log Files <a id="compat-logging"></a>
The Icinga 1.x log format is considered being the `Compat Log`
in Icinga 2 provided with the `CompatLogger` object.
-These logs are not only used for informational representation in
+These logs are used for informational representation in
external web interfaces parsing the logs, but also to generate
-SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
-[Livestatus](14-features.md#setting-up-livestatus) feature uses these logs for answering queries to
-historical tables.
+SLA reports and trends.
+The [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs
+for answering queries to historical tables.
The `CompatLogger` object can be enabled with
in `/var/log/icinga2/compat`. Rotated log files are moved into
`var/log/icinga2/compat/archives`.
-The format cannot be changed without breaking compatibility to
-existing log parsers.
-
- # tail -f /var/log/icinga2/compat/icinga.log
-
- [1382115688] LOG ROTATION: HOURLY
- [1382115688] LOG VERSION: 2.0
- [1382115688] HOST STATE: CURRENT;localhost;UP;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;disk;WARNING;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;http;OK;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;load;OK;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;ping4;OK;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;ping6;OK;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;processes;WARNING;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;ssh;OK;HARD;1;
- [1382115688] SERVICE STATE: CURRENT;localhost;users;OK;HARD;1;
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;disk;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;http;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;load;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping6;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;processes;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ssh;1382115705
- [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;users;1382115705
- [1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test|
- [1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test
-
-
## Check Result Files <a id="check-result-files"></a>
Icinga 1.x writes its check result files to a temporary spool directory
> **Note**
>
-> The Classic UI feature named `Command Expander` does not work with Icinga 2.
+> The Icinga 1.x feature named `Command Expander` does not work with Icinga 2.
#### Environment Macros <a id="differences-1x-2-environment-macros"></a>
* Service A should notify contact X via SMS
* Service B should notify contact X via Mail
* Service C should notify contact Y via Mail and SMS
-* Contact X and Y should also be used for authorization (e.g. in Classic UI)
+* Contact X and Y should also be used for authorization
The only way achieving a semi-clean solution is to
### Logging <a id="differences-1x-2-logging"></a>
Icinga 1.x supports syslog facilities and writes its own `icinga.log` log file
-and archives. These logs are used in Icinga 1.x Classic UI to generate
+and archives. These logs are used in Icinga 1.x to generate
historical reports.
Icinga 2 compat library provides the CompatLogger object which writes the icinga.log and archive
-in Icinga 1.x format in order to stay compatible with Classic UI and other addons.
+in Icinga 1.x format in order to stay compatible with addons.
The native Icinga 2 logging facilities are split into three configuration objects: SyslogLogger,
FileLogger, StreamLogger. Each of them has their own severity and target configuration.
Object | Prefix
------------------------|------------------------
-CheckCommand | check_
-EventCommand | event_
-NotificationCommand | notification_
-
-### Status Files <a id="schema-status-files"></a>
-
-Status files used by Icinga 1.x Classic UI: `status.dat`, `objects.cache`.
-
-Icinga 2 specific extensions:
-
-* host and service objects support 'check_source' (added in Classic UI 1.10.0)
-* command objects support custom variables (added in Classic UI 1.11.2)
-* host and service objects support 'is_reachable' (added in Classic UI 1.11.3)
-* 2.2 adds custom attributes with arrays and dictionaries. They are dumped as JSON encoded string and `_is_json`
-is set as additional custom variable in `objects.cache`.
+CheckCommand | check\_
+EventCommand | event\_
+NotificationCommand | notification\_
### DB IDO Schema <a id="schema-db-ido"></a>