1 # <a id="migration"></a> Migration from Icinga 1.x
3 ## <a id="configuration-migration"></a> Configuration Migration
5 The Icinga 2 configuration format introduces plenty of behavioural changes. In
6 order to ease migration from Icinga 1.x, this section provides hints and tips
7 on your migration requirements.
9 ### <a id="configuration-migration-script"></a> Configuration Migration Script
11 A standalone configuration migration script is available at
12 https://github.com/Icinga/icinga2-migration. All further
13 details on the command line parameters are documented there too.
15 Please note that not each configuration detail, trick or attribute does work.
16 Some specific migration steps will be still required to be done manually,
17 especially if you want to preserve your existing file layout, or any other
18 object specific policies.
22 > It is highly recommended to review your existing installation, do an inventory
23 > of checked objects, thresholds and then design your new configuration layout.
24 > Keep in mind that the more dynamic approach using the [apply rules](3-monitoring-basics.md#using-apply)
25 > allows you to start over in many scenarios.
27 ### <a id="manual-config-migration"></a> Manual Config Migration
29 For a long-term migration of your configuration you should consider re-creating
30 your configuration based on the proposed Icinga 2 configuration paradigm.
32 Please read the [next chapter](21-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
35 ### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
37 These hints should provide you with enough details for manually migrating your configuration,
38 or to adapt your configuration export tool to dump Icinga 2 configuration instead of
39 Icinga 1.x configuration.
41 The examples are taken from Icinga 1.x test and production environments and converted
42 straight into a possible Icinga 2 format. If you found a different strategy, please
45 If you require in-depth explanations, please check the [next chapter](21-migrating-from-icinga-1x.md#differences-1x-2).
47 #### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
49 By default all intervals without any duration literal are interpreted as seconds. Therefore
50 all existing Icinga 1.x `*_interval` attributes require an additional `m` duration literal.
55 service_description service1
57 check_command test_customvar
65 object Service "service1" {
66 import "generic-service"
67 host_name = "localhost1"
68 check_command = "test_customvar"
73 #### <a id="manual-config-migration-hints-services"></a> Manual Config Migration Hints for Services
75 If you have used the `host_name` attribute in Icinga 1.x with one or more host names this service
76 belongs to, you can migrate this to the [apply rules](3-monitoring-basics.md#using-apply) syntax.
81 service_description service1
82 host_name localhost1,localhost2
83 check_command test_check
89 apply Service "service1" {
90 import "generic-service"
91 check_command = "test_check"
93 assign where host.name in [ "localhost1", "localhost2" ]
96 In Icinga 1.x you would have organized your services with hostgroups using the `hostgroup_name` attribute
97 like the following example:
100 service_description servicewithhostgroups
101 hostgroup_name hostgroup1,hostgroup3
102 check_command test_check
106 Using Icinga 2 you can migrate this to the [apply rules](3-monitoring-basics.md#using-apply) syntax:
108 apply Service "servicewithhostgroups" {
109 import "generic-service"
110 check_command = "test_check"
112 assign where "hostgroup1" in host.groups
113 assign where "hostgroup3" in host.groups
116 #### <a id="manual-config-migration-hints-group-members"></a> Manual Config Migration Hints for Group Members
118 The Icinga 1.x hostgroup `hg1` has two members `host1` and `host2`. The hostgroup `hg2` has `host3` as
119 a member and includes all members of the `hg1` hostgroup.
129 hostgroup_members hg1
132 This can be migrated to Icinga 2 and [using group assign](18-language-reference.md#group-assign). The additional nested hostgroup
133 `hg1` is included into `hg2` with the `groups` attribute.
136 object HostGroup "hg1" {
137 assign where host.name in [ "host1", "host2" ]
140 object HostGroup "hg2" {
142 assign where host.name == "host3"
145 These assign rules can be applied for all groups: `HostGroup`, `ServiceGroup` and `UserGroup`
146 (requires renaming from `contactgroup`).
150 > Define custom attributes and assign/ignore members based on these attribute pattern matches.
154 #### <a id="manual-config-migration-hints-check-command-arguments"></a> Manual Config Migration Hints for Check Command Arguments
156 Host and service check command arguments are separated by a `!` in Icinga 1.x. Their order is important and they
157 are referenced as `$ARGn$` where `n` is the argument counter.
161 command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
167 service_description my-ping
168 check_command my-ping-check!100.0,20%!500.0,60%
171 While you could manually migrate this like (please note the new generic command arguments and default argument values!):
173 object CheckCommand "my-ping-check" {
174 import "plugin-check-command"
177 PluginDir + "/check_ping", "-4"
181 "-H" = "$ping_address$"
182 "-w" = "$ping_wrta$,$ping_wpl$%"
183 "-c" = "$ping_crta$,$ping_cpl$%"
184 "-p" = "$ping_packets$"
185 "-t" = "$ping_timeout$"
188 vars.ping_address = "$address$"
195 object Service "my-ping" {
196 import "generic-service"
197 host_name = "my-server"
198 check_command = "my-ping-check"
206 #### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
208 Runtime macros have been renamed. A detailed comparison table can be found [here](21-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
210 For example, accessing the service check output looks like the following in Icinga 1.x:
214 In Icinga 2 you will need to write:
218 Another example referencing the host's address attribute in Icinga 1.x:
222 In Icinga 2 you'd just use the following macro to access all `address` attributes (even overridden from the service objects):
227 #### <a id="manual-config-migration-hints-runtime-custom-attributes"></a> Manual Config Migration Hints for Runtime Custom Attributes
229 Custom variables from Icinga 1.x are available as Icinga 2 custom attributes.
232 command_name test_customvar
233 command_line echo "Host CV: $_HOSTCVTEST$ Service CV: $_SERVICECVTEST$\n"
238 check_command test_customvar
240 _CVTEST host cv value
244 service_description service1
246 check_command test_customvar
248 _CVTEST service cv value
251 Can be written as the following in Icinga 2:
253 object CheckCommand "test_customvar" {
254 import "plugin-check-command"
255 command = "echo "Host CV: $host.vars.CVTEST$ Service CV: $service.vars.CVTEST$\n""
258 object Host "localhost1" {
259 import "generic-host"
260 check_command = "test_customvar"
261 vars.CVTEST = "host cv value"
264 object Service "service1" {
265 host_name = "localhost1"
266 check_command = "test_customvar"
267 vars.CVTEST = "service cv value"
270 If you are just defining `$CVTEST$` in your command definition its value depends on the
271 execution scope - the host check command will fetch the host attribute value of `vars.CVTEST`
272 while the service check command resolves its value to the service attribute attribute `vars.CVTEST`.
276 > Custom attributes in Icinga 2 are case-sensitive. `vars.CVTEST` is not the same as `vars.CvTest`.
278 #### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
280 Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
281 This migration part is explained in the [next chapter](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
284 contact_name testconfig-user
286 alias Icinga Test User
287 service_notification_options c,f,s,u
288 email icinga@localhost
291 The `service_notification_options` can be [mapped](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
292 into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
293 renamed to `display_name`.
295 object User "testconfig-user" {
296 import "generic-user"
297 display_name = "Icinga Test User"
298 email = "icinga@localhost"
301 This user can be put into usergroups (former contactgroups) or referenced in newly migration notification
304 #### <a id="manual-config-migration-hints-notifications"></a> Manual Config Migration Hints for Notifications
306 If you are migrating a host or service notification, you'll need to extract the following information from
307 your existing Icinga 1.x configuration objects
309 * host/service attribute `contacts` and `contact_groups`
310 * host/service attribute `notification_options`
311 * host/service attribute `notification_period`
312 * host/service attribute `notification_interval`
314 The clean approach is to refactor your current contacts and their notification command methods into a
317 * host or service has a notification type (for example mail)
318 * which contacts (users) are notified by mail?
319 * do the notification filters, periods, intervals still apply for them? (do a cleanup during migration)
320 * assign users and groups to these notifications
321 * Redesign the notifications into generic [apply rules](3-monitoring-basics.md#using-apply-notifications)
324 The ugly workaround solution could look like this:
326 Extract all contacts from the remaining groups, and create a unique list. This is required for determining
327 the host and service notification commands involved.
329 * contact attributes `host_notification_commands` and `service_notification_commands` (can be a comma separated list)
330 * get the command line for each notification command and store them for later
331 * create a new notification name and command name
333 Generate a new notification object based on these values. Import the generic template based on the type (`host` or `service`).
334 Assign it to the host or service and set the newly generated notification command name as `command` attribute.
336 object Notification "<notificationname>" {
337 import "mail-host-notification"
338 host_name = "<thishostname>"
339 command = "<notificationcommandname>"
342 Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
343 [here](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
345 states = [ OK, Warning, Critical ]
346 types = [ Recovery, Problem, Custom ]
349 The current contact acts as `users` attribute.
351 users = [ "<contactwithnotificationcommand>" ]
354 Do this in a loop for all notification commands (depending if host or service contact). Once done, dump the
355 collected notification commands.
357 The result of this migration are lots of unnecessary notification objects and commands but it will unroll
358 the Icinga 1.x logic into the revamped Icinga 2 notification object schema. If you are looking for code
359 examples, try [LConf](https://www.netways.org).
363 #### <a id="manual-config-migration-hints-notification-filters"></a> Manual Config Migration Hints for Notification Filters
365 Icinga 1.x defines all notification filters in an attribute called `notification_options`. Using Icinga 2 you will
366 have to split these values into the `states` and `types` attributes.
370 > `Recovery` type requires the `Ok` state.
371 > `Custom` and `Problem` should always be set as `type` filter.
373 Icinga 1.x option | Icinga 2 state | Icinga 2 type
374 ----------------------|-----------------------|-------------------
375 o | OK (Up for hosts) |
376 w | Warning | Problem
377 c | Critical | Problem
378 u | Unknown | Problem
380 s | . | DowntimeStart / DowntimeEnd / DowntimeRemoved
382 f | . | FlappingStart / FlappingEnd
383 n | 0 (none) | 0 (none)
388 #### <a id="manual-config-migration-hints-escalations"></a> Manual Config Migration Hints for Escalations
390 Escalations in Icinga 1.x are a bit tricky. By default service escalations can be applied to hosts and
391 hostgroups and require a defined service object.
393 The following example applies a service escalation to the service `dep_svc01` and all hosts in the `hg_svcdep2`
394 hostgroup. The default `notification_interval` is set to `10` minutes notifying the `cg_admin` contact.
395 After 20 minutes (`10*2`, notification_interval * first_notification) the notification is escalated to the
396 `cg_ops` contactgroup until 60 minutes (`10*6`) have passed.
399 service_description dep_svc01
400 host_name dep_hostsvc01,dep_hostsvc03
403 notification_interval 10
404 contact_groups cg_admin
408 hostgroup_name hg_svcdep2
409 members dep_hostsvc03
412 # with hostgroup_name and service_description
413 define serviceescalation {
414 hostgroup_name hg_svcdep2
415 service_description dep_svc01
418 contact_groups cg_ops
421 In Icinga 2 the service and hostgroup definition will look quite the same. Save the `notification_interval`
422 and `contact_groups` attribute for an additional notification.
424 apply Service "dep_svc01" {
425 import "generic-service"
427 check_command = "test2"
429 assign where host.name == "dep_hostsvc01"
430 assign where host.name == "dep_hostsvc03"
433 object HostGroup "hg_svcdep2" {
434 assign where host.name == "dep_hostsvc03"
437 apply Notification "email" to Service {
438 import "service-mail-notification"
441 user_groups = [ "cg_admin" ]
443 assign where service.name == "dep_svc01" && (host.name == "dep_hostsvc01" || host.name == "dep_hostsvc03")
446 Calculate the begin and end time for the newly created escalation notification:
448 * begin = first_notification * notification_interval = 2 * 10m = 20m
449 * end = last_notification * notification_interval = 6 * 10m = 60m = 1h
451 Assign the notification escalation to the service `dep_svc01` on all hosts in the hostgroup `hg_svcdep2`.
453 apply Notification "email-escalation" to Service {
454 import "service-mail-notification"
457 user_groups = [ "cg_ops" ]
464 assign where service.name == "dep_svc01" && "hg_svcdep2" in host.groups
467 The assign rule could be made more generic and the notification be applied to more than
468 just this service belonging to hosts in the matched hostgroup.
473 > When the notification is escalated, Icinga 1.x suppresses notifications to the default contacts.
474 > In Icinga 2 an escalation is an additional notification with a defined begin and end time. The
475 > `email` notification will continue as normal.
479 #### <a id="manual-config-migration-hints-dependencies"></a> Manual Config Migration Hints for Dependencies
481 There are some dependency examples already in the [basics chapter](3-monitoring-basics.md#dependencies). Dependencies in
482 Icinga 1.x can be confusing in terms of which host/service is the parent and which host/service acts
485 While Icinga 1.x defines `notification_failure_criteria` and `execution_failure_criteria` as dependency
486 filters, this behaviour has changed in Icinga 2. There is no 1:1 migration but generally speaking
487 the state filter defined in the `execution_failure_criteria` defines the Icinga 2 `state` attribute.
488 If the state filter matches, you can define whether to disable checks and notifications or not.
490 The following example describes service dependencies. If you migrate from Icinga 1.x you will only
491 want to use the classic `Host-to-Host` and `Service-to-Service` dependency relationships.
494 service_description dep_svc01
495 hostgroup_name hg_svcdep1
501 service_description dep_svc02
502 hostgroup_name hg_svcdep2
508 hostgroup_name hg_svcdep2
513 use linux-server-template
518 # with hostgroup_name and service_description
519 define servicedependency {
521 dependent_hostgroup_name hg_svcdep2
522 service_description dep_svc01
523 dependent_service_description *
524 execution_failure_criteria u,c
525 notification_failure_criteria w,u,c
529 Map the dependency attributes accordingly.
531 Icinga 1.x | Icinga 2
532 ----------------------|---------------------
533 host_name | parent_host_name
534 dependent_host_name | child_host_name (used in assign/ignore)
535 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
536 service_description | parent_service_name
537 dependent_service_description | child_service_name (used in assign/ignore)
539 And migrate the host and services.
541 object Host "host1" {
542 import "linux-server-template"
543 address = "192.168.1.10"
546 object HostGroup "hg_svcdep2" {
547 assign where host.name == "host2"
550 apply Service "dep_svc01" {
551 import "generic-service"
552 check_command = "test2"
554 assign where "hp_svcdep1" in host.groups
557 apply Service "dep_svc02" {
558 import "generic-service"
559 check_command = "test2"
561 assign where "hp_svcdep2" in host.groups
564 When it comes to the `execution_failure_criteria` and `notification_failure_criteria` attribute migration,
565 you will need to map the most common values, in this example `u,c` (`Unknown` and `Critical` will cause the
566 dependency to fail). Therefore the `Dependency` should be ok on Ok and Warning. `inherits_parents` is always
569 apply Dependency "all-svc-for-hg-hg_svcdep2-on-host1-dep_svc01" to Service {
570 parent_host_name = "host1"
571 parent_service_name = "dep_svc01"
573 states = [ Ok, Warning ]
574 disable_checks = true
575 disable_notifications = true
577 assign where "hg_svcdep2" in host.groups
580 Host dependencies are explained in the [next chapter](21-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
584 #### <a id="manual-config-migration-hints-host-parents"></a> Manual Config Migration Hints for Host Parents
586 Host parents from Icinga 1.x are migrated into `Host-to-Host` dependencies in Icinga 2.
588 The following example defines the `vmware-master` host as parent host for the guest
589 virtual machines `vmware-vm1` and `vmware-vm2`.
591 By default all hosts in the hostgroup `vmware` should get the parent assigned. This isn't really
592 solvable with Icinga 1.x parents, but only with host dependencies.
595 use linux-server-template
596 host_name vmware-master
602 use linux-server-template
606 parents vmware-master
610 use linux-server-template
614 parents vmware-master
617 By default all hosts in the hostgroup `vmware` should get the parent assigned (but not the `vmware-master`
618 host itself). This isn't really solvable with Icinga 1.x parents, but only with host dependencies as shown
621 define hostdependency {
622 dependent_hostgroup_name vmware
623 dependent_host_name !vmware-master
624 host_name vmware-master
626 notification_failure_criteria d,u
627 execution_failure_criteria d,u
628 dependency_period testconfig-24x7
631 When migrating to Icinga 2, the parents must be changed to a newly created host dependency.
634 Map the following attributes
636 Icinga 1.x | Icinga 2
637 ----------------------|---------------------
638 host_name | parent_host_name
639 dependent_host_name | child_host_name (used in assign/ignore)
640 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
642 The Icinga 2 configuration looks like this:
645 object Host "vmware-master" {
646 import "linux-server-template"
647 groups += [ "vmware" ]
648 address = "192.168.1.10"
649 vars.is_vmware_master = true
652 object Host "vmware-vm1" {
653 import "linux-server-template"
654 groups += [ "vmware" ]
655 address = "192.168.27.1"
658 object Host "vmware-vm2" {
659 import "linux-server-template"
660 groups += [ "vmware" ]
661 address = "192.168.28.1"
664 apply Dependency "vmware-master" to Host {
665 parent_host_name = "vmware-master"
667 assign where "vmware" in host.groups
668 ignore where host.vars.is_vmware_master
669 ignore where host.name == "vmware-master"
672 For easier identification you could add the `vars.is_vmware_master` attribute to the `vmware-master`
673 host and let the dependency ignore that instead of the hardcoded host name. That's different
674 to the Icinga 1.x example and a best practice hint only.
677 #### <a id="manual-config-migration-hints-distributed-setup"></a> Manual Config Migration Hints for Distributed Setups
679 * Icinga 2 does not use active/passive instances calling OSCP commands and requiring the NSCA
680 daemon for passing check results between instances.
681 * Icinga 2 does not support any 1.x NEB addons for check load distribution
683 * If your current setup consists of instances distributing the check load, you should consider
684 building a [load distribution](13-distributed-monitoring-ha.md#cluster-scenarios-load-distribution) setup with Icinga 2.
685 * If your current setup includes active/passive clustering with external tools like Pacemaker/DRBD
686 consider the [High Availability](13-distributed-monitoring-ha.md#cluster-scenarios-high-availability) setup.
687 * If you have build your own custom configuration deployment and check result collecting mechanism
688 you should re-design your setup and re-evaluate your requirements, and how they may be fulfilled
689 using the Icinga 2 cluster capabilities.
692 ## <a id="differences-1x-2"></a> Differences between Icinga 1.x and 2
694 ### <a id="differences-1x-2-configuration-format"></a> Configuration Format
696 Icinga 1.x supports two configuration formats: key-value-based settings in the
697 `icinga.cfg` configuration file and object-based in included files (`cfg_dir`,
698 `cfg_file`). The path to the `icinga.cfg` configuration file must be passed to
699 the Icinga daemon at startup.
703 enable_notifications=1
708 notifications_enabled 0
711 Icinga 2 supports objects and (global) variables, but does not make a difference
712 if it's the main configuration file, or any included file.
716 const EnableNotifications = true
718 object Service "test" {
719 enable_notifications = false
722 #### <a id="differences-1x-2-sample-configuration-itl"></a> Sample Configuration and ITL
724 While Icinga 1.x ships sample configuration and templates spread in various
725 object files, Icinga 2 moves all templates into the Icinga Template Library (ITL)
726 and includes them in the sample configuration.
728 Additional plugin check commands are shipped with Icinga 2 as well.
730 The ITL will be updated on every release and must not be edited by the user.
732 There are still generic templates available for your convenience which may or may
733 not be re-used in your configuration. For instance, `generic-service` includes
734 all required attributes except `check_command` for a service.
736 Sample configuration files are located in the `conf.d/` directory which is
737 included in `icinga2.conf` by default.
741 > Add your own custom templates in the `conf.d/` directory as well, e.g. inside
742 > the [templates.conf](4-configuring-icinga-2.md#templates-conf) file.
744 ### <a id="differences-1x-2-main-config"></a> Main Config File
746 In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
747 Icinga 2 only uses a small set of [global constants](18-language-reference.md#constants) allowing
748 you to specify certain different setting such as the `NodeName` in a cluster scenario.
750 Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
751 global constants, enabled [features](8-cli-commands.md#enable-features) and the object configuration.
753 ### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
755 In Icinga 1.x the `icinga.cfg` file contains `cfg_file` and `cfg_dir`
756 directives. The `cfg_dir` directive recursively includes all files with a `.cfg`
757 suffix in the given directory. Only absolute paths may be used. The `cfg_file`
758 and `cfg_dir` directives can include the same file twice which leads to
759 configuration errors in Icinga 1.x.
761 cfg_file=/etc/icinga/objects/commands.cfg
762 cfg_dir=/etc/icinga/objects
764 Icinga 2 supports wildcard includes and relative paths, e.g. for including
765 `conf.d/*.conf` in the same directory.
767 include "conf.d/*.conf"
769 If you want to include files and directories recursively, you need to define
770 a separate option and add the directory and an optional pattern.
772 include_recursive "conf.d"
774 A global search path for includes is available for advanced features like
775 the Icinga Template Library (ITL) or additional monitoring plugins check
776 command configuration.
781 By convention the `.conf` suffix is used for Icinga 2 configuration files.
783 ### <a id="differences-1x-2-resource-file-global-macros"></a> Resource File and Global Macros
785 Global macros such as for the plugin directory, usernames and passwords can be
786 set in the `resource.cfg` configuration file in Icinga 1.x. By convention the
787 `USER1` macro is used to define the directory for the plugins.
789 Icinga 2 uses global constants instead. In the default config these are
790 set in the `constants.conf` configuration file:
793 * This file defines global constants which can be used in
794 * the other configuration files. At a minimum the
795 * PluginDir constant should be defined.
798 const PluginDir = "/usr/lib/nagios/plugins"
800 [Global macros](18-language-reference.md#constants) can only be defined once. Trying to modify a
801 global constant will result in an error.
803 ### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
805 In Icinga 1.x comments are made using a leading hash (`#`) or a semi-colon (`;`)
808 In Icinga 2 comments can either be encapsulated by `/*` and `*/` (allowing for
809 multi-line comments) or starting with two slashes (`//`). A leading hash (`#`)
812 ### <a id="differences-1x-2-object-names"></a> Object Names
814 Object names must not contain an exclamation mark (`!`). Use the `display_name` attribute
815 to specify user-friendly names which should be shown in UIs (supported by
816 Icinga Web 2 for example).
818 Object names are not specified using attributes (e.g. `service_description` for
819 services) like in Icinga 1.x but directly after their type definition.
823 service_description ping4
826 object Service "ping4" {
827 host_name = "localhost"
830 ### <a id="differences-1x-2-templates"></a> Templates
832 In Icinga 1.x templates are identified using the `register 0` setting. Icinga 2
833 uses the `template` identifier:
835 template Service "ping4-template" { }
837 Icinga 1.x objects inherit from templates using the `use` attribute.
838 Icinga 2 uses the keyword `import` with template names in double quotes.
841 service_description testservice
842 use tmpl1,tmpl2,tmpl3
845 object Service "testservice" {
851 The last template overrides previously set values.
853 ### <a id="differences-1x-2-object-attributes"></a> Object attributes
855 Icinga 1.x separates attribute and value pairs with whitespaces/tabs. Icinga 2
856 requires an equal sign (=) between them.
862 object Service "test" {
866 Please note that the default time value is seconds, if no duration literal
867 is given. `check_interval = 5` behaves the same as `check_interval = 5s`.
869 All strings require double quotes in Icinga 2. Therefore a double quote
870 must be escaped by a backslash (e.g. in command line).
871 If an attribute identifier starts with a number, it must be enclosed
872 in double quotes as well.
874 #### <a id="differences-1x-2-alias-display-name"></a> Alias vs. Display Name
876 In Icinga 1.x a host can have an `alias` and a `display_name` attribute used
877 for a more descriptive name. A service only can have a `display_name` attribute.
878 The `alias` is used for group, timeperiod, etc. objects too.
879 Icinga 2 only supports the `display_name` attribute which is also taken into
880 account by Icinga web interfaces.
882 ### <a id="differences-1x-2-custom-attributes"></a> Custom Attributes
884 Icinga 2 allows you to define custom attributes in the `vars` dictionary.
885 The `notes`, `notes_url`, `action_url`, `icon_image`, `icon_image_alt`
886 attributes for host and service objects are still available in Icinga 2.
888 `2d_coords` and `statusmap_image` are not supported in Icinga 2.
890 #### <a id="differences-1x-2-custom-variables"></a> Custom Variables
892 Icinga 1.x custom variable attributes must be prefixed using an underscore (`_`).
893 In Icinga 2 these attributes must be added to the `vars` dictionary as custom attributes.
895 vars.dn = "cn=icinga2-dev-host,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org"
896 vars.cv = "my custom cmdb description"
898 These custom attributes are also used as [command parameters](3-monitoring-basics.md#command-passing-parameters).
900 While Icinga 1.x only supports numbers and strings as custom attribute values,
901 Icinga 2 extends that to arrays and (nested) dictionaries. For more details
902 look [here](3-monitoring-basics.md#custom-attributes).
904 ### <a id="differences-1x-2-host-service-relation"></a> Host Service Relation
906 In Icinga 1.x a service object is associated with a host by defining the
907 `host_name` attribute in the service definition. Alternate methods refer
908 to `hostgroup_name` or behaviour changing regular expression.
910 The preferred way of associating hosts with services in Icinga 2 is by
911 using the [apply](3-monitoring-basics.md#using-apply) keyword.
913 Direct object relations between a service and a host still allow you to use
914 the `host_name` [Service](6-object-types.md#objecttype-service) object attribute.
916 ### <a id="differences-1x-2-users"></a> Users
918 Contacts have been renamed to users (same for groups). A contact does not
919 only provide (custom) attributes and notification commands used for notifications,
920 but is also used for authorization checks in Icinga 1.x.
922 Icinga 2 changes that behavior and makes the user an attribute provider only.
923 These attributes can be accessed using [runtime macros](3-monitoring-basics.md#runtime-macros)
924 inside notification command definitions.
926 In Icinga 2 notification commands are not directly associated with users.
927 Instead the notification command is specified inside `Notification` objects next to
928 user and user group relations.
930 The `StatusDataWriter`, `IdoMySqlConnection` and `LivestatusListener` types will
931 provide the contact and contactgroups attributes for services for compatibility
932 reasons. These values are calculated from all services, their notifications,
935 ### <a id="differences-1x-2-macros"></a> Macros
937 Various object attributes and runtime variables can be accessed as macros in
938 commands in Icinga 1.x - Icinga 2 supports all required [custom attributes](3-monitoring-basics.md#custom-attributes).
940 #### <a id="differences-1x-2-command-arguments"></a> Command Arguments
942 If you have previously used Icinga 1.x you may already be familiar with
943 user and argument definitions (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x
944 the Icinga 2 custom attributes may have arbitrary names and arguments are no
945 longer specified in the `check_command` setting.
947 In Icinga 1.x arguments are specified in the `check_command` attribute and
948 are separated from the command name using an exclamation mark (`!`).
950 Please check the migration hints for a detailed
951 [migration example](21-migrating-from-icinga-1x.md#manual-config-migration-hints-check-command-arguments).
955 > The Classic UI feature named `Command Expander` does not work with Icinga 2.
957 #### <a id="differences-1x-2-environment-macros"></a> Environment Macros
959 The global configuration setting `enable_environment_macros` does not exist in
962 Macros exported into the [environment](3-monitoring-basics.md#command-environment-variables)
963 can be set using the `env` attribute in command objects.
965 #### <a id="differences-1x-2-runtime-macros"></a> Runtime Macros
967 Icinga 2 requires an object specific namespace when accessing configuration
968 and stateful runtime macros. Custom attributes can be accessed directly.
970 If a runtime macro from Icinga 1.x is not listed here, it is not supported
973 Changes to user (contact) runtime macros
975 Icinga 1.x | Icinga 2
976 -----------------------|----------------------
977 CONTACTNAME | user.name
978 CONTACTALIAS | user.display_name
979 CONTACTEMAIL | user.email
980 CONTACTPAGER | user.pager
982 `CONTACTADDRESS*` is not supported but can be accessed as `$user.vars.address1$`
985 Changes to service runtime macros
987 Icinga 1.x | Icinga 2
988 -----------------------|----------------------
989 SERVICEDESC | service.name
990 SERVICEDISPLAYNAME | service.display_name
991 SERVICECHECKCOMMAND | service.check_command
992 SERVICESTATE | service.state
993 SERVICESTATEID | service.state_id
994 SERVICESTATETYPE | service.state_type
995 SERVICEATTEMPT | service.check_attempt
996 MAXSERVICEATTEMPT | service.max_check_attempts
997 LASTSERVICESTATE | service.last_state
998 LASTSERVICESTATEID | service.last_state_id
999 LASTSERVICESTATETYPE | service.last_state_type
1000 LASTSERVICESTATECHANGE | service.last_state_change
1001 SERVICEDOWNTIME | service.downtime_depth
1002 SERVICEDURATIONSEC | service.duration_sec
1003 SERVICELATENCY | service.latency
1004 SERVICEEXECUTIONTIME | service.execution_time
1005 SERVICEOUTPUT | service.output
1006 SERVICEPERFDATA | service.perfdata
1007 LASTSERVICECHECK | service.last_check
1008 SERVICENOTES | service.notes
1009 SERVICENOTESURL | service.notes_url
1010 SERVICEACTIONURL | service.action_url
1013 Changes to host runtime macros
1015 Icinga 1.x | Icinga 2
1016 -----------------------|----------------------
1017 HOSTNAME | host.name
1018 HOSTADDRESS | host.address
1019 HOSTADDRESS6 | host.address6
1020 HOSTDISPLAYNAME | host.display_name
1021 HOSTALIAS | (use `host.display_name` instead)
1022 HOSTCHECKCOMMAND | host.check_command
1023 HOSTSTATE | host.state
1024 HOSTSTATEID | host.state_id
1025 HOSTSTATETYPE | host.state_type
1026 HOSTATTEMPT | host.check_attempt
1027 MAXHOSTATTEMPT | host.max_check_attempts
1028 LASTHOSTSTATE | host.last_state
1029 LASTHOSTSTATEID | host.last_state_id
1030 LASTHOSTSTATETYPE | host.last_state_type
1031 LASTHOSTSTATECHANGE | host.last_state_change
1032 HOSTDOWNTIME | host.downtime_depth
1033 HOSTDURATIONSEC | host.duration_sec
1034 HOSTLATENCY | host.latency
1035 HOSTEXECUTIONTIME | host.execution_time
1036 HOSTOUTPUT | host.output
1037 HOSTPERFDATA | host.perfdata
1038 LASTHOSTCHECK | host.last_check
1039 HOSTNOTES | host.notes
1040 HOSTNOTESURL | host.notes_url
1041 HOSTACTIONURL | host.action_url
1042 TOTALSERVICES | host.num_services
1043 TOTALSERVICESOK | host.num_services_ok
1044 TOTALSERVICESWARNING | host.num_services_warning
1045 TOTALSERVICESUNKNOWN | host.num_services_unknown
1046 TOTALSERVICESCRITICAL | host.num_services_critical
1048 Changes to command runtime macros
1050 Icinga 1.x | Icinga 2
1051 -----------------------|----------------------
1052 COMMANDNAME | command.name
1054 Changes to notification runtime macros
1056 Icinga 1.x | Icinga 2
1057 -----------------------|----------------------
1058 NOTIFICATIONTYPE | notification.type
1059 NOTIFICATIONAUTHOR | notification.author
1060 NOTIFICATIONCOMMENT | notification.comment
1061 NOTIFICATIONAUTHORNAME | (use `notification.author`)
1062 NOTIFICATIONAUTHORALIAS | (use `notification.author`)
1065 Changes to global runtime macros:
1067 Icinga 1.x | Icinga 2
1068 -----------------------|----------------------
1069 TIMET | icinga.timet
1070 LONGDATETIME | icinga.long_date_time
1071 SHORTDATETIME | icinga.short_date_time
1074 PROCESSSTARTTIME | icinga.uptime
1076 Changes to global statistic macros:
1078 Icinga 1.x | Icinga 2
1079 ----------------------------------|----------------------
1080 TOTALHOSTSUP | icinga.num_hosts_up
1081 TOTALHOSTSDOWN | icinga.num_hosts_down
1082 TOTALHOSTSUNREACHABLE | icinga.num_hosts_unreachable
1083 TOTALHOSTSDOWNUNHANDLED | --
1084 TOTALHOSTSUNREACHABLEUNHANDLED | --
1085 TOTALHOSTPROBLEMS | down
1086 TOTALHOSTPROBLEMSUNHANDLED | down-(downtime+acknowledged)
1087 TOTALSERVICESOK | icinga.num_services_ok
1088 TOTALSERVICESWARNING | icinga.num_services_warning
1089 TOTALSERVICESCRITICAL | icinga.num_services_critical
1090 TOTALSERVICESUNKNOWN | icinga.num_services_unknown
1091 TOTALSERVICESWARNINGUNHANDLED | --
1092 TOTALSERVICESCRITICALUNHANDLED | --
1093 TOTALSERVICESUNKNOWNUNHANDLED | --
1094 TOTALSERVICEPROBLEMS | ok+warning+critical+unknown
1095 TOTALSERVICEPROBLEMSUNHANDLED | warning+critical+unknown-(downtime+acknowledged)
1100 ### <a id="differences-1x-2-external-commands"></a> External Commands
1102 `CHANGE_CUSTOM_CONTACT_VAR` was renamed to `CHANGE_CUSTOM_USER_VAR`.
1103 `CHANGE_CONTACT_MODATTR` was renamed to `CHANGE_USER_MODATTR`.
1105 The following external commands are not supported:
1107 CHANGE_CONTACT_HOST_NOTIFICATION_TIMEPERIOD
1108 CHANGE_HOST_NOTIFICATION_TIMEPERIOD
1109 CHANGE_SVC_NOTIFICATION_TIMEPERIOD
1110 DEL_DOWNTIME_BY_HOSTGROUP_NAME
1111 DEL_DOWNTIME_BY_START_TIME_COMMENT
1112 DISABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1113 DISABLE_CONTACT_HOST_NOTIFICATIONS
1114 DISABLE_CONTACT_SVC_NOTIFICATIONS
1115 DISABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1116 DISABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1117 DISABLE_FAILURE_PREDICTION
1118 DISABLE_HOST_AND_CHILD_NOTIFICATIONS
1119 DISABLE_HOST_FRESHNESS_CHECKS
1120 DISABLE_NOTIFICATIONS_EXPIRE_TIME
1121 DISABLE_SERVICE_FRESHNESS_CHECKS
1122 ENABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1123 ENABLE_CONTACT_HOST_NOTIFICATIONS
1124 ENABLE_CONTACT_SVC_NOTIFICATIONS
1125 ENABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1126 ENABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1127 ENABLE_FAILURE_PREDICTION
1128 ENABLE_HOST_AND_CHILD_NOTIFICATIONS
1129 ENABLE_HOST_FRESHNESS_CHECKS
1130 ENABLE_SERVICE_FRESHNESS_CHECKS
1131 READ_STATE_INFORMATION
1132 SAVE_STATE_INFORMATION
1133 SCHEDULE_AND_PROPAGATE_HOST_DOWNTIME
1134 SCHEDULE_AND_PROPAGATE_TRIGGERED_HOST_DOWNTIME
1135 SET_HOST_NOTIFICATION_NUMBER
1136 SET_SVC_NOTIFICATION_NUMBER
1137 START_ACCEPTING_PASSIVE_HOST_CHECKS
1138 START_ACCEPTING_PASSIVE_SVC_CHECKS
1139 START_OBSESSING_OVER_HOST
1140 START_OBSESSING_OVER_HOST_CHECKS
1141 START_OBSESSING_OVER_SVC
1142 START_OBSESSING_OVER_SVC_CHECKS
1143 STOP_ACCEPTING_PASSIVE_HOST_CHECKS
1144 STOP_ACCEPTING_PASSIVE_SVC_CHECKS
1145 STOP_OBSESSING_OVER_HOST
1146 STOP_OBSESSING_OVER_HOST_CHECKS
1147 STOP_OBSESSING_OVER_SVC
1148 STOP_OBSESSING_OVER_SVC_CHECKS
1150 ### <a id="differences-1x-2-async-event-execution"></a> Asynchronous Event Execution
1152 Unlike Icinga 1.x, Icinga 2 does not block when it waits for a command
1153 being executed - be it a check, notification, event handler, performance data writing update, etc.
1154 That way you'll recognize low to zero (check) latencies with Icinga 2.
1156 ### <a id="differences-1x-2-checks"></a> Checks
1158 #### <a id="differences-1x-2-check-output"></a> Check Output
1160 Icinga 2 does not make a difference between `output` (first line) and
1161 `long_output` (remaining lines) like in Icinga 1.x. Performance Data is
1162 provided separately.
1164 There is no output length restriction as known from Icinga 1.x using an
1165 [8KB static buffer](http://docs.icinga.org/latest/en/pluginapi.html#outputlengthrestrictions).
1167 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1168 split the raw output into `output` (first line) and `long_output` (remaining
1169 lines) for compatibility reasons.
1171 #### <a id="differences-1x-2-initial-state"></a> Initial State
1173 Icinga 1.x uses the `max_service_check_spread` setting to specify a timerange
1174 where the initial state checks must have happened. Icinga 2 will use the
1175 `retry_interval` setting instead and `check_interval` divided by 5 if
1176 `retry_interval` is not defined.
1178 ### <a id="differences-1x-2-comments"></a> Comments
1180 Icinga 2 doesn't support non-persistent comments.
1182 ### <a id="differences-1x-2-commands"></a> Commands
1184 Unlike in Icinga 1.x there are three different command types in Icinga 2:
1185 `CheckCommand`, `NotificationCommand`, and `EventCommand`.
1187 For example in Icinga 1.x it is possible to accidently use a notification
1188 command as an event handler which might cause problems depending on which
1189 runtime macros are used in the notification command.
1191 In Icinga 2 these command types are separated and will generate an error on
1192 configuration validation if used in the wrong context.
1194 While Icinga 2 still supports the complete command line in command objects, it's
1195 recommended to use [command arguments](3-monitoring-basics.md#command-arguments)
1196 with optional and conditional command line parameters instead.
1198 It's also possible to define default argument values for the command itself
1199 which can be overridden by the host or service then.
1201 #### <a id="differences-1x-2-commands-timeouts"></a> Command Timeouts
1203 In Icinga 1.x there were two global options defining a host and service check
1204 timeout. This was essentially bad when there only was a couple of check plugins
1205 requiring some command timeouts to be extended.
1207 Icinga 2 allows you to specify the command timeout directly on the command. So
1208 if your VMVware check plugin takes 15 minutes, [increase the timeout](6-object-types.md#objecttype-checkcommand)
1212 ### <a id="differences-1x-2-groups"></a> Groups
1214 In Icinga 2 hosts, services, and users are added to groups using the `groups`
1215 attribute in the object. The old way of listing all group members in the group's
1216 `members` attribute is available through `assign where` and `ignore where`
1217 expressions by using [group assign](3-monitoring-basics.md#group-assign-intro).
1219 object Host "web-dev" {
1220 import "generic-host"
1223 object HostGroup "dev-hosts" {
1224 display_name = "Dev Hosts"
1225 assign where match("*-dev", host.name)
1228 #### <a id="differences-1x-2-service-hostgroup-host"></a> Add Service to Hostgroup where Host is Member
1230 In order to associate a service with all hosts in a host group the [apply](3-monitoring-basics.md#using-apply)
1231 keyword can be used:
1233 apply Service "ping4" {
1234 import "generic-service"
1236 check_command = "ping4"
1238 assign where "dev-hosts" in host.groups
1241 ### <a id="differences-1x-2-notifications"></a> Notifications
1243 Notifications are a new object type in Icinga 2. Imagine the following
1244 notification configuration problem in Icinga 1.x:
1246 * Service A should notify contact X via SMS
1247 * Service B should notify contact X via Mail
1248 * Service C should notify contact Y via Mail and SMS
1249 * Contact X and Y should also be used for authorization (e.g. in Classic UI)
1251 The only way achieving a semi-clean solution is to
1253 * Create contact X-sms, set service_notification_command for sms, assign contact
1255 * Create contact X-mail, set service_notification_command for mail, assign
1256 contact to service B
1257 * Create contact Y, set service_notification_command for sms and mail, assign
1258 contact to service C
1259 * Create contact X without notification commands, assign to service A and B
1261 Basically you are required to create duplicated contacts for either each
1262 notification method or used for authorization only.
1264 Icinga 2 attempts to solve that problem in this way
1266 * Create user X, set SMS and Mail attributes, used for authorization
1267 * Create user Y, set SMS and Mail attributes, used for authorization
1268 * Create notification A-SMS, set command for sms, add user X,
1269 assign notification A-SMS to service A
1270 * Create notification B-Mail, set command for mail, add user X,
1271 assign notification Mail to service B
1272 * Create notification C-SMS, set command for sms, add user Y,
1273 assign notification C-SMS to service C
1274 * Create notification C-Mail, set command for mail, add user Y,
1275 assign notification C-Mail to service C
1277 Previously in Icinga 1.x it looked like this:
1279 service -> (contact, contactgroup) -> notification command
1281 In Icinga 2 it will look like this:
1283 Service -> Notification -> NotificationCommand
1286 #### <a id="differences-1x-2-escalations"></a> Escalations
1288 Escalations in Icinga 1.x require a separated object matching on existing
1289 objects. Escalations happen between a defined start and end time which is
1290 calculated from the notification_interval:
1292 start = notification start + (notification_interval * first_notification)
1293 end = notification start + (notification_interval * last_notification)
1295 In theory first_notification and last_notification can be set to readable
1296 numbers. In practice users are manipulating those attributes in combination
1297 with notification_interval in order to get a start and end time.
1299 In Icinga 2 the notification object can be used as notification escalation
1300 if the start and end times are defined within the 'times' attribute using
1301 duration literals (e.g. 30m).
1303 The Icinga 2 escalation does not replace the current running notification.
1304 In Icinga 1.x it's required to copy the contacts from the service notification
1305 to the escalation to guarantee the normal notifications once an escalation
1307 That's not necessary with Icinga 2 only requiring an additional notification
1308 object for the escalation itself.
1310 #### <a id="differences-1x-2-notification-options"></a> Notification Options
1312 Unlike Icinga 1.x with the 'notification_options' attribute with comma-separated
1313 state and type filters, Icinga 2 uses two configuration attributes for that.
1314 All state and type filter use long names OR'd with a pipe together
1316 notification_options w,u,c,r,f,s
1318 states = [ Warning, Unknown, Critical ]
1319 filters = [ Problem, Recovery, FlappingStart, FlappingEnd, DowntimeStart, DowntimeEnd, DowntimeRemoved ]
1321 Icinga 2 adds more fine-grained type filters for acknowledgements, downtime,
1322 and flapping type (start, end, ...).
1324 ### <a id="differences-1x-2-dependencies-parents"></a> Dependencies and Parents
1326 In Icinga 1.x it's possible to define host parents to determine network reachability
1327 and keep a host's state unreachable rather than down.
1328 Furthermore there are host and service dependencies preventing unnecessary checks and
1329 notifications. A host must not depend on a service, and vice versa. All dependencies
1330 are configured as separate objects and cannot be set directly on the host or service
1333 A service can now depend on a host, and vice versa. A service has an implicit dependency
1334 (parent) to its host. A host to host dependency acts implicitly as host parent relation.
1336 The former `host_name` and `dependent_host_name` have been renamed to `parent_host_name`
1337 and `child_host_name` (same for the service attribute). When using apply rules the
1338 child attributes may be omitted.
1340 For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
1343 Dependencies can be applied to hosts or services using the [apply rules](18-language-reference.md#apply).
1345 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1346 support the Icinga 1.x schema with dependencies and parent attributes for
1347 compatibility reasons.
1349 ### <a id="differences-1x-2-flapping"></a> Flapping
1351 The Icinga 1.x flapping detection uses the last 21 states of a service. This
1352 value is hardcoded and cannot be changed. The algorithm on determining a flapping state
1355 flapping value = (number of actual state changes / number of possible state changes)
1357 The flapping value is then compared to the low and high flapping thresholds.
1359 The algorithm used in Icinga 2 does not store the past states but calculcates the flapping
1360 threshold from a single value based on counters and half-life values. Icinga 2 compares
1361 the value with a single flapping threshold configuration attribute.
1363 ### <a id="differences-1x-2-check-result-freshness"></a> Check Result Freshness
1365 Freshness of check results must be enabled explicitly in Icinga 1.x. The attribute
1366 `freshness_threshold` defines the threshold in seconds. Once the threshold is triggered, an
1367 active freshness check is executed defined by the `check_command` attribute. Both check
1368 methods (active and passive) use the same freshness check method.
1370 In Icinga 2 active check freshness is determined by the `check_interval` attribute and no
1371 incoming check results in that period of time (last check + check interval). Passive check
1372 freshness is calculated from the `check_interval` attribute if set. There is no extra
1373 `freshness_threshold` attribute in Icinga 2. If the freshness checks are invalid, a new
1374 service check is forced.
1376 ### <a id="differences-1x-2-real-reload"></a> Real Reload
1378 In Nagios / Icinga 1.x a daemon reload does the following:
1380 * receive reload signal SIGHUP
1381 * stop all events (checks, notifications, etc)
1382 * read the configuration from disk and validate all config objects in a single threaded fashion
1383 * validation NOT ok: stop the daemon (cannot restore old config state)
1384 * validation ok: start with new objects, dump status.dat / ido
1386 Unlike Icinga 1.x the Icinga 2 daemon reload does not block any event
1387 execution during config validation:
1389 * receive reload signal SIGHUP
1390 * fork a child process, start configuration validation in parallel work queues
1391 * parent process continues with old configuration objects and the event scheduling
1392 (doing checks, replicating cluster events, triggering alert notifications, etc.)
1393 * validation NOT ok: child process terminates, parent process continues with old configuration state
1394 (this is **essential** for the [cluster config synchronisation](13-distributed-monitoring-ha.md#cluster-zone-config-sync))
1395 * validation ok: child process signals parent process to terminate and save its current state
1396 (all events until now) into the icinga2 state file
1397 * parent process shuts down writing icinga2.state file
1398 * child process waits for parent process gone, reads the icinga2 state file and synchronizes all historical and status data
1399 * child becomes the new session leader
1401 The DB IDO configuration dump and status/historical event updates use a queue
1402 not blocking event execution. Same goes for any other enabled feature.
1403 The configuration validation itself runs in parallel allowing fast verification checks.
1405 That way your monitoring does not stop during a configuration reload.
1408 ### <a id="differences-1x-2-state-retention"></a> State Retention
1410 Icinga 1.x uses the `retention.dat` file to save its state in order to be able
1411 to reload it after a restart. In Icinga 2 this file is called `icinga2.state`.
1413 The format is **not** compatible with Icinga 1.x.
1415 ### <a id="differences-1x-2-logging"></a> Logging
1417 Icinga 1.x supports syslog facilities and writes its own `icinga.log` log file
1418 and archives. These logs are used in Icinga 1.x Classic UI to generate
1421 Icinga 2 compat library provides the CompatLogger object which writes the icinga.log and archive
1422 in Icinga 1.x format in order to stay compatible with Classic UI and other addons.
1424 The native Icinga 2 logging facilities are split into three configuration objects: SyslogLogger,
1425 FileLogger, StreamLogger. Each of them has their own severity and target configuration.
1427 The Icinga 2 daemon log does not log any alerts but is considered an application log only.
1429 ### <a id="differences-1x-2-broker-modules-features"></a> Broker Modules and Features
1431 Icinga 1.x broker modules are incompatible with Icinga 2.
1433 In order to provide compatibility with Icinga 1.x the functionality of several
1434 popular broker modules was implemented for Icinga 2:
1438 * Cluster (allows for high availability and load balancing)
1441 ### <a id="differences-1x-2-distributed-monitoring"></a> Distributed Monitoring
1443 Icinga 1.x uses the native "obsess over host/service" method which requires the NSCA addon
1444 passing the slave's check results passively onto the master's external command pipe.
1445 While this method may be used for check load distribution, it does not provide any configuration
1446 distribution out-of-the-box. Furthermore comments, downtimes, and other stateful runtime data is
1447 not synced between the master and slave nodes. There are addons available solving the check
1448 and configuration distribution problems Icinga 1.x distributed monitoring currently suffers from.
1450 Icinga 2 implements a new built-in
1451 [distributed monitoring architecture](13-distributed-monitoring-ha.md#distributed-monitoring-high-availability),
1452 including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
1453 High Availability and load balancing are also part of the Icinga 2 Cluster feature, next to local replay
1454 logs on connection loss ensuring that the event history is kept in sync.