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="manual-config-migration"></a> Manual Config Migration
11 For a long-term migration of your configuration you should consider re-creating
12 your configuration based on the proposed Icinga 2 configuration paradigm.
14 Please read the [next chapter](23-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
17 ### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
19 These hints should provide you with enough details for manually migrating your configuration,
20 or to adapt your configuration export tool to dump Icinga 2 configuration instead of
21 Icinga 1.x configuration.
23 The examples are taken from Icinga 1.x test and production environments and converted
24 straight into a possible Icinga 2 format. If you found a different strategy, please
27 If you require in-depth explanations, please check the [next chapter](23-migrating-from-icinga-1x.md#differences-1x-2).
29 #### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
31 By default all intervals without any duration literal are interpreted as seconds. Therefore
32 all existing Icinga 1.x `*_interval` attributes require an additional `m` duration literal.
37 service_description service1
39 check_command test_customvar
47 object Service "service1" {
48 import "generic-service"
49 host_name = "localhost1"
50 check_command = "test_customvar"
55 #### <a id="manual-config-migration-hints-services"></a> Manual Config Migration Hints for Services
57 If you have used the `host_name` attribute in Icinga 1.x with one or more host names this service
58 belongs to, you can migrate this to the [apply rules](3-monitoring-basics.md#using-apply) syntax.
63 service_description service1
64 host_name localhost1,localhost2
65 check_command test_check
71 apply Service "service1" {
72 import "generic-service"
73 check_command = "test_check"
75 assign where host.name in [ "localhost1", "localhost2" ]
78 In Icinga 1.x you would have organized your services with hostgroups using the `hostgroup_name` attribute
79 like the following example:
82 service_description servicewithhostgroups
83 hostgroup_name hostgroup1,hostgroup3
84 check_command test_check
88 Using Icinga 2 you can migrate this to the [apply rules](3-monitoring-basics.md#using-apply) syntax:
90 apply Service "servicewithhostgroups" {
91 import "generic-service"
92 check_command = "test_check"
94 assign where "hostgroup1" in host.groups
95 assign where "hostgroup3" in host.groups
98 #### <a id="manual-config-migration-hints-group-members"></a> Manual Config Migration Hints for Group Members
100 The Icinga 1.x hostgroup `hg1` has two members `host1` and `host2`. The hostgroup `hg2` has `host3` as
101 a member and includes all members of the `hg1` hostgroup.
111 hostgroup_members hg1
114 This can be migrated to Icinga 2 and [using group assign](18-language-reference.md#group-assign). The additional nested hostgroup
115 `hg1` is included into `hg2` with the `groups` attribute.
118 object HostGroup "hg1" {
119 assign where host.name in [ "host1", "host2" ]
122 object HostGroup "hg2" {
124 assign where host.name == "host3"
127 These assign rules can be applied for all groups: `HostGroup`, `ServiceGroup` and `UserGroup`
128 (requires renaming from `contactgroup`).
132 > Define custom attributes and assign/ignore members based on these attribute pattern matches.
136 #### <a id="manual-config-migration-hints-check-command-arguments"></a> Manual Config Migration Hints for Check Command Arguments
138 Host and service check command arguments are separated by a `!` in Icinga 1.x. Their order is important and they
139 are referenced as `$ARGn$` where `n` is the argument counter.
143 command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
149 service_description my-ping
150 check_command my-ping-check!100.0,20%!500.0,60%
153 While you could manually migrate this like (please note the new generic command arguments and default argument values!):
155 object CheckCommand "my-ping-check" {
156 import "plugin-check-command"
159 PluginDir + "/check_ping", "-4"
163 "-H" = "$ping_address$"
164 "-w" = "$ping_wrta$,$ping_wpl$%"
165 "-c" = "$ping_crta$,$ping_cpl$%"
166 "-p" = "$ping_packets$"
167 "-t" = "$ping_timeout$"
170 vars.ping_address = "$address$"
177 object Service "my-ping" {
178 import "generic-service"
179 host_name = "my-server"
180 check_command = "my-ping-check"
188 #### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
190 Runtime macros have been renamed. A detailed comparison table can be found [here](23-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
192 For example, accessing the service check output looks like the following in Icinga 1.x:
196 In Icinga 2 you will need to write:
200 Another example referencing the host's address attribute in Icinga 1.x:
204 In Icinga 2 you'd just use the following macro to access all `address` attributes (even overridden from the service objects):
209 #### <a id="manual-config-migration-hints-runtime-custom-attributes"></a> Manual Config Migration Hints for Runtime Custom Attributes
211 Custom variables from Icinga 1.x are available as Icinga 2 custom attributes.
214 command_name test_customvar
215 command_line echo "Host CV: $_HOSTCVTEST$ Service CV: $_SERVICECVTEST$\n"
220 check_command test_customvar
222 _CVTEST host cv value
226 service_description service1
228 check_command test_customvar
230 _CVTEST service cv value
233 Can be written as the following in Icinga 2:
235 object CheckCommand "test_customvar" {
236 import "plugin-check-command"
237 command = "echo "Host CV: $host.vars.CVTEST$ Service CV: $service.vars.CVTEST$\n""
240 object Host "localhost1" {
241 import "generic-host"
242 check_command = "test_customvar"
243 vars.CVTEST = "host cv value"
246 object Service "service1" {
247 host_name = "localhost1"
248 check_command = "test_customvar"
249 vars.CVTEST = "service cv value"
252 If you are just defining `$CVTEST$` in your command definition, its value depends on the
253 execution scope -- the host check command will fetch the host attribute value of `vars.CVTEST`
254 while the service check command resolves its value to the service attribute attribute `vars.CVTEST`.
258 > Custom attributes in Icinga 2 are case-sensitive. `vars.CVTEST` is not the same as `vars.CvTest`.
260 #### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
262 Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
263 This migration part is explained in the [next chapter](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
266 contact_name testconfig-user
268 alias Icinga Test User
269 service_notification_options c,f,s,u
270 email icinga@localhost
273 The `service_notification_options` can be [mapped](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
274 into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
275 renamed to `display_name`.
277 object User "testconfig-user" {
278 import "generic-user"
279 display_name = "Icinga Test User"
280 email = "icinga@localhost"
283 This user can be put into usergroups (former contactgroups) or referenced in newly migration notification
286 #### <a id="manual-config-migration-hints-notifications"></a> Manual Config Migration Hints for Notifications
288 If you are migrating a host or service notification, you'll need to extract the following information from
289 your existing Icinga 1.x configuration objects
291 * host/service attribute `contacts` and `contact_groups`
292 * host/service attribute `notification_options`
293 * host/service attribute `notification_period`
294 * host/service attribute `notification_interval`
296 The clean approach is to refactor your current contacts and their notification command methods into a
299 * host or service has a notification type (for example mail)
300 * which contacts (users) are notified by mail?
301 * do the notification filters, periods, intervals still apply for them? (do a cleanup during migration)
302 * assign users and groups to these notifications
303 * Redesign the notifications into generic [apply rules](3-monitoring-basics.md#using-apply-notifications)
306 The ugly workaround solution could look like this:
308 Extract all contacts from the remaining groups, and create a unique list. This is required for determining
309 the host and service notification commands involved.
311 * contact attributes `host_notification_commands` and `service_notification_commands` (can be a comma separated list)
312 * get the command line for each notification command and store them for later
313 * create a new notification name and command name
315 Generate a new notification object based on these values. Import the generic template based on the type (`host` or `service`).
316 Assign it to the host or service and set the newly generated notification command name as `command` attribute.
318 object Notification "<notificationname>" {
319 import "mail-host-notification"
320 host_name = "<thishostname>"
321 command = "<notificationcommandname>"
324 Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
325 [here](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
327 states = [ OK, Warning, Critical ]
328 types = [ Recovery, Problem, Custom ]
331 The current contact acts as `users` attribute.
333 users = [ "<contactwithnotificationcommand>" ]
336 Do this in a loop for all notification commands (depending if host or service contact). Once done, dump the
337 collected notification commands.
339 The result of this migration are lots of unnecessary notification objects and commands but it will unroll
340 the Icinga 1.x logic into the revamped Icinga 2 notification object schema. If you are looking for code
341 examples, try [LConf](https://www.netways.org).
345 #### <a id="manual-config-migration-hints-notification-filters"></a> Manual Config Migration Hints for Notification Filters
347 Icinga 1.x defines all notification filters in an attribute called `notification_options`. Using Icinga 2 you will
348 have to split these values into the `states` and `types` attributes.
352 > `Recovery` type requires the `Ok` state.
353 > `Custom` and `Problem` should always be set as `type` filter.
355 Icinga 1.x option | Icinga 2 state | Icinga 2 type
356 ----------------------|-----------------------|-------------------
357 o | OK (Up for hosts) |
358 w | Warning | Problem
359 c | Critical | Problem
360 u | Unknown | Problem
362 s | . | DowntimeStart / DowntimeEnd / DowntimeRemoved
364 f | . | FlappingStart / FlappingEnd
365 n | 0 (none) | 0 (none)
370 #### <a id="manual-config-migration-hints-escalations"></a> Manual Config Migration Hints for Escalations
372 Escalations in Icinga 1.x are a bit tricky. By default service escalations can be applied to hosts and
373 hostgroups and require a defined service object.
375 The following example applies a service escalation to the service `dep_svc01` and all hosts in the `hg_svcdep2`
376 hostgroup. The default `notification_interval` is set to `10` minutes notifying the `cg_admin` contact.
377 After 20 minutes (`10*2`, notification_interval * first_notification) the notification is escalated to the
378 `cg_ops` contactgroup until 60 minutes (`10*6`) have passed.
381 service_description dep_svc01
382 host_name dep_hostsvc01,dep_hostsvc03
385 notification_interval 10
386 contact_groups cg_admin
390 hostgroup_name hg_svcdep2
391 members dep_hostsvc03
394 # with hostgroup_name and service_description
395 define serviceescalation {
396 hostgroup_name hg_svcdep2
397 service_description dep_svc01
400 contact_groups cg_ops
403 In Icinga 2 the service and hostgroup definition will look quite the same. Save the `notification_interval`
404 and `contact_groups` attribute for an additional notification.
406 apply Service "dep_svc01" {
407 import "generic-service"
409 check_command = "test2"
411 assign where host.name == "dep_hostsvc01"
412 assign where host.name == "dep_hostsvc03"
415 object HostGroup "hg_svcdep2" {
416 assign where host.name == "dep_hostsvc03"
419 apply Notification "email" to Service {
420 import "service-mail-notification"
423 user_groups = [ "cg_admin" ]
425 assign where service.name == "dep_svc01" && (host.name == "dep_hostsvc01" || host.name == "dep_hostsvc03")
428 Calculate the begin and end time for the newly created escalation notification:
430 * begin = first_notification * notification_interval = 2 * 10m = 20m
431 * end = last_notification * notification_interval = 6 * 10m = 60m = 1h
433 Assign the notification escalation to the service `dep_svc01` on all hosts in the hostgroup `hg_svcdep2`.
435 apply Notification "email-escalation" to Service {
436 import "service-mail-notification"
439 user_groups = [ "cg_ops" ]
446 assign where service.name == "dep_svc01" && "hg_svcdep2" in host.groups
449 The assign rule could be made more generic and the notification be applied to more than
450 just this service belonging to hosts in the matched hostgroup.
455 > When the notification is escalated, Icinga 1.x suppresses notifications to the default contacts.
456 > In Icinga 2 an escalation is an additional notification with a defined begin and end time. The
457 > `email` notification will continue as normal.
461 #### <a id="manual-config-migration-hints-dependencies"></a> Manual Config Migration Hints for Dependencies
463 There are some dependency examples already in the [basics chapter](3-monitoring-basics.md#dependencies). Dependencies in
464 Icinga 1.x can be confusing in terms of which host/service is the parent and which host/service acts
467 While Icinga 1.x defines `notification_failure_criteria` and `execution_failure_criteria` as dependency
468 filters, this behaviour has changed in Icinga 2. There is no 1:1 migration but generally speaking
469 the state filter defined in the `execution_failure_criteria` defines the Icinga 2 `state` attribute.
470 If the state filter matches, you can define whether to disable checks and notifications or not.
472 The following example describes service dependencies. If you migrate from Icinga 1.x, you will only
473 want to use the classic `Host-to-Host` and `Service-to-Service` dependency relationships.
476 service_description dep_svc01
477 hostgroup_name hg_svcdep1
483 service_description dep_svc02
484 hostgroup_name hg_svcdep2
490 hostgroup_name hg_svcdep2
495 use linux-server-template
500 # with hostgroup_name and service_description
501 define servicedependency {
503 dependent_hostgroup_name hg_svcdep2
504 service_description dep_svc01
505 dependent_service_description *
506 execution_failure_criteria u,c
507 notification_failure_criteria w,u,c
511 Map the dependency attributes accordingly.
513 Icinga 1.x | Icinga 2
514 ----------------------|---------------------
515 host_name | parent_host_name
516 dependent_host_name | child_host_name (used in assign/ignore)
517 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
518 service_description | parent_service_name
519 dependent_service_description | child_service_name (used in assign/ignore)
521 And migrate the host and services.
523 object Host "host1" {
524 import "linux-server-template"
525 address = "192.168.1.10"
528 object HostGroup "hg_svcdep2" {
529 assign where host.name == "host2"
532 apply Service "dep_svc01" {
533 import "generic-service"
534 check_command = "test2"
536 assign where "hp_svcdep1" in host.groups
539 apply Service "dep_svc02" {
540 import "generic-service"
541 check_command = "test2"
543 assign where "hp_svcdep2" in host.groups
546 When it comes to the `execution_failure_criteria` and `notification_failure_criteria` attribute migration,
547 you will need to map the most common values, in this example `u,c` (`Unknown` and `Critical` will cause the
548 dependency to fail). Therefore the `Dependency` should be ok on Ok and Warning. `inherits_parents` is always
551 apply Dependency "all-svc-for-hg-hg_svcdep2-on-host1-dep_svc01" to Service {
552 parent_host_name = "host1"
553 parent_service_name = "dep_svc01"
555 states = [ Ok, Warning ]
556 disable_checks = true
557 disable_notifications = true
559 assign where "hg_svcdep2" in host.groups
562 Host dependencies are explained in the [next chapter](23-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
566 #### <a id="manual-config-migration-hints-host-parents"></a> Manual Config Migration Hints for Host Parents
568 Host parents from Icinga 1.x are migrated into `Host-to-Host` dependencies in Icinga 2.
570 The following example defines the `vmware-master` host as parent host for the guest
571 virtual machines `vmware-vm1` and `vmware-vm2`.
573 By default all hosts in the hostgroup `vmware` should get the parent assigned. This isn't really
574 solvable with Icinga 1.x parents, but only with host dependencies.
577 use linux-server-template
578 host_name vmware-master
584 use linux-server-template
588 parents vmware-master
592 use linux-server-template
596 parents vmware-master
599 By default all hosts in the hostgroup `vmware` should get the parent assigned (but not the `vmware-master`
600 host itself). This isn't really solvable with Icinga 1.x parents, but only with host dependencies as shown
603 define hostdependency {
604 dependent_hostgroup_name vmware
605 dependent_host_name !vmware-master
606 host_name vmware-master
608 notification_failure_criteria d,u
609 execution_failure_criteria d,u
610 dependency_period testconfig-24x7
613 When migrating to Icinga 2, the parents must be changed to a newly created host dependency.
616 Map the following attributes
618 Icinga 1.x | Icinga 2
619 ----------------------|---------------------
620 host_name | parent_host_name
621 dependent_host_name | child_host_name (used in assign/ignore)
622 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
624 The Icinga 2 configuration looks like this:
627 object Host "vmware-master" {
628 import "linux-server-template"
629 groups += [ "vmware" ]
630 address = "192.168.1.10"
631 vars.is_vmware_master = true
634 object Host "vmware-vm1" {
635 import "linux-server-template"
636 groups += [ "vmware" ]
637 address = "192.168.27.1"
640 object Host "vmware-vm2" {
641 import "linux-server-template"
642 groups += [ "vmware" ]
643 address = "192.168.28.1"
646 apply Dependency "vmware-master" to Host {
647 parent_host_name = "vmware-master"
649 assign where "vmware" in host.groups
650 ignore where host.vars.is_vmware_master
651 ignore where host.name == "vmware-master"
654 For easier identification you could add the `vars.is_vmware_master` attribute to the `vmware-master`
655 host and let the dependency ignore that instead of the hardcoded host name. That's different
656 to the Icinga 1.x example and a best practice hint only.
659 #### <a id="manual-config-migration-hints-distributed-setup"></a> Manual Config Migration Hints for Distributed Setups
661 * Icinga 2 does not use active/passive instances calling OSCP commands and requiring the NSCA
662 daemon for passing check results between instances.
663 * Icinga 2 does not support any 1.x NEB addons for check load distribution
665 * If your current setup consists of instances distributing the check load, you should consider
666 building a [load distribution](13-distributed-monitoring-ha.md#cluster-scenarios-load-distribution) setup with Icinga 2.
667 * If your current setup includes active/passive clustering with external tools like Pacemaker/DRBD,
668 consider the [High Availability](13-distributed-monitoring-ha.md#cluster-scenarios-high-availability) setup.
669 * If you have build your own custom configuration deployment and check result collecting mechanism,
670 you should re-design your setup and re-evaluate your requirements, and how they may be fulfilled
671 using the Icinga 2 cluster capabilities.
674 ## <a id="differences-1x-2"></a> Differences between Icinga 1.x and 2
676 ### <a id="differences-1x-2-configuration-format"></a> Configuration Format
678 Icinga 1.x supports two configuration formats: key-value-based settings in the
679 `icinga.cfg` configuration file and object-based in included files (`cfg_dir`,
680 `cfg_file`). The path to the `icinga.cfg` configuration file must be passed to
681 the Icinga daemon at startup.
685 enable_notifications=1
690 notifications_enabled 0
693 Icinga 2 supports objects and (global) variables, but does not make a difference
694 between the main configuration file or any other included file.
698 const EnableNotifications = true
700 object Service "test" {
701 enable_notifications = false
704 #### <a id="differences-1x-2-sample-configuration-itl"></a> Sample Configuration and ITL
706 While Icinga 1.x ships sample configuration and templates spread in various
707 object files, Icinga 2 moves all templates into the Icinga Template Library (ITL)
708 and includes them in the sample configuration.
710 Additional plugin check commands are shipped with Icinga 2 as well.
712 The ITL will be updated on every release and must not be edited by the user.
714 There are still generic templates available for your convenience which may or may
715 not be re-used in your configuration. For instance, `generic-service` includes
716 all required attributes except `check_command` for a service.
718 Sample configuration files are located in the `conf.d/` directory which is
719 included in `icinga2.conf` by default.
723 > Add your own custom templates in the `conf.d/` directory as well, e.g. inside
724 > the [templates.conf](4-configuring-icinga-2.md#templates-conf) file.
726 ### <a id="differences-1x-2-main-config"></a> Main Config File
728 In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
729 Icinga 2 only uses a small set of [global constants](18-language-reference.md#constants) allowing
730 you to specify certain different setting such as the `NodeName` in a cluster scenario.
732 Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
733 global constants, enabled [features](8-cli-commands.md#enable-features) and the object configuration.
735 ### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
737 In Icinga 1.x the `icinga.cfg` file contains `cfg_file` and `cfg_dir`
738 directives. The `cfg_dir` directive recursively includes all files with a `.cfg`
739 suffix in the given directory. Only absolute paths may be used. The `cfg_file`
740 and `cfg_dir` directives can include the same file twice which leads to
741 configuration errors in Icinga 1.x.
743 cfg_file=/etc/icinga/objects/commands.cfg
744 cfg_dir=/etc/icinga/objects
746 Icinga 2 supports wildcard includes and relative paths, e.g. for including
747 `conf.d/*.conf` in the same directory.
749 include "conf.d/*.conf"
751 If you want to include files and directories recursively, you need to define
752 a separate option and add the directory and an optional pattern.
754 include_recursive "conf.d"
756 A global search path for includes is available for advanced features like
757 the Icinga Template Library (ITL) or additional monitoring plugins check
758 command configuration.
763 By convention the `.conf` suffix is used for Icinga 2 configuration files.
765 ### <a id="differences-1x-2-resource-file-global-macros"></a> Resource File and Global Macros
767 Global macros such as for the plugin directory, usernames and passwords can be
768 set in the `resource.cfg` configuration file in Icinga 1.x. By convention the
769 `USER1` macro is used to define the directory for the plugins.
771 Icinga 2 uses global constants instead. In the default config these are
772 set in the `constants.conf` configuration file:
775 * This file defines global constants which can be used in
776 * the other configuration files. At a minimum the
777 * PluginDir constant should be defined.
780 const PluginDir = "/usr/lib/nagios/plugins"
782 [Global macros](18-language-reference.md#constants) can only be defined once. Trying to modify a
783 global constant will result in an error.
785 ### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
787 In Icinga 1.x comments are made using a leading hash (`#`) or a semi-colon (`;`)
790 In Icinga 2 comments can either be encapsulated by `/*` and `*/` (allowing for
791 multi-line comments) or starting with two slashes (`//`). A leading hash (`#`)
794 ### <a id="differences-1x-2-object-names"></a> Object Names
796 Object names must not contain an exclamation mark (`!`). Use the `display_name` attribute
797 to specify user-friendly names which should be shown in UIs (supported by
798 Icinga Web 2 for example).
800 Object names are not specified using attributes (e.g. `service_description` for
801 services) like in Icinga 1.x but directly after their type definition.
805 service_description ping4
808 object Service "ping4" {
809 host_name = "localhost"
812 ### <a id="differences-1x-2-templates"></a> Templates
814 In Icinga 1.x templates are identified using the `register 0` setting. Icinga 2
815 uses the `template` identifier:
817 template Service "ping4-template" { }
819 Icinga 1.x objects inherit from templates using the `use` attribute.
820 Icinga 2 uses the keyword `import` with template names in double quotes.
823 service_description testservice
824 use tmpl1,tmpl2,tmpl3
827 object Service "testservice" {
833 The last template overrides previously set values.
835 ### <a id="differences-1x-2-object-attributes"></a> Object attributes
837 Icinga 1.x separates attribute and value pairs with whitespaces/tabs. Icinga 2
838 requires an equal sign (=) between them.
844 object Service "test" {
848 Please note that the default time value is seconds if no duration literal
849 is given. `check_interval = 5` behaves the same as `check_interval = 5s`.
851 All strings require double quotes in Icinga 2. Therefore a double quote
852 must be escaped by a backslash (e.g. in command line).
853 If an attribute identifier starts with a number, it must be enclosed
854 in double quotes as well.
856 #### <a id="differences-1x-2-alias-display-name"></a> Alias vs. Display Name
858 In Icinga 1.x a host can have an `alias` and a `display_name` attribute used
859 for a more descriptive name. A service only can have a `display_name` attribute.
860 The `alias` is used for group, timeperiod, etc. objects too.
861 Icinga 2 only supports the `display_name` attribute which is also taken into
862 account by Icinga web interfaces.
864 ### <a id="differences-1x-2-custom-attributes"></a> Custom Attributes
866 Icinga 2 allows you to define custom attributes in the `vars` dictionary.
867 The `notes`, `notes_url`, `action_url`, `icon_image`, `icon_image_alt`
868 attributes for host and service objects are still available in Icinga 2.
870 `2d_coords` and `statusmap_image` are not supported in Icinga 2.
872 #### <a id="differences-1x-2-custom-variables"></a> Custom Variables
874 Icinga 1.x custom variable attributes must be prefixed using an underscore (`_`).
875 In Icinga 2 these attributes must be added to the `vars` dictionary as custom attributes.
877 vars.dn = "cn=icinga2-dev-host,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org"
878 vars.cv = "my custom cmdb description"
880 These custom attributes are also used as [command parameters](3-monitoring-basics.md#command-passing-parameters).
882 While Icinga 1.x only supports numbers and strings as custom attribute values,
883 Icinga 2 extends that to arrays and (nested) dictionaries. For more details
884 look [here](3-monitoring-basics.md#custom-attributes).
886 ### <a id="differences-1x-2-host-service-relation"></a> Host Service Relation
888 In Icinga 1.x a service object is associated with a host by defining the
889 `host_name` attribute in the service definition. Alternate methods refer
890 to `hostgroup_name` or behaviour changing regular expression.
892 The preferred way of associating hosts with services in Icinga 2 is by
893 using the [apply](3-monitoring-basics.md#using-apply) keyword.
895 Direct object relations between a service and a host still allow you to use
896 the `host_name` [Service](6-object-types.md#objecttype-service) object attribute.
898 ### <a id="differences-1x-2-users"></a> Users
900 Contacts have been renamed to users (same for groups). A contact does not
901 only provide (custom) attributes and notification commands used for notifications,
902 but is also used for authorization checks in Icinga 1.x.
904 Icinga 2 changes that behavior and makes the user an attribute provider only.
905 These attributes can be accessed using [runtime macros](3-monitoring-basics.md#runtime-macros)
906 inside notification command definitions.
908 In Icinga 2 notification commands are not directly associated with users.
909 Instead the notification command is specified inside `Notification` objects next to
910 user and user group relations.
912 The `StatusDataWriter`, `IdoMySqlConnection` and `LivestatusListener` types will
913 provide the contact and contactgroups attributes for services for compatibility
914 reasons. These values are calculated from all services, their notifications,
917 ### <a id="differences-1x-2-macros"></a> Macros
919 Various object attributes and runtime variables can be accessed as macros in
920 commands in Icinga 1.x -- Icinga 2 supports all required [custom attributes](3-monitoring-basics.md#custom-attributes).
922 #### <a id="differences-1x-2-command-arguments"></a> Command Arguments
924 If you have previously used Icinga 1.x, you may already be familiar with
925 user and argument definitions (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x
926 the Icinga 2 custom attributes may have arbitrary names and arguments are no
927 longer specified in the `check_command` setting.
929 In Icinga 1.x arguments are specified in the `check_command` attribute and
930 are separated from the command name using an exclamation mark (`!`).
932 Please check the migration hints for a detailed
933 [migration example](23-migrating-from-icinga-1x.md#manual-config-migration-hints-check-command-arguments).
937 > The Classic UI feature named `Command Expander` does not work with Icinga 2.
939 #### <a id="differences-1x-2-environment-macros"></a> Environment Macros
941 The global configuration setting `enable_environment_macros` does not exist in
944 Macros exported into the [environment](3-monitoring-basics.md#command-environment-variables)
945 can be set using the `env` attribute in command objects.
947 #### <a id="differences-1x-2-runtime-macros"></a> Runtime Macros
949 Icinga 2 requires an object specific namespace when accessing configuration
950 and stateful runtime macros. Custom attributes can be accessed directly.
952 If a runtime macro from Icinga 1.x is not listed here, it is not supported
955 Changes to user (contact) runtime macros
957 Icinga 1.x | Icinga 2
958 -----------------------|----------------------
959 CONTACTNAME | user.name
960 CONTACTALIAS | user.display_name
961 CONTACTEMAIL | user.email
962 CONTACTPAGER | user.pager
964 `CONTACTADDRESS*` is not supported but can be accessed as `$user.vars.address1$`
967 Changes to service runtime macros
969 Icinga 1.x | Icinga 2
970 -----------------------|----------------------
971 SERVICEDESC | service.name
972 SERVICEDISPLAYNAME | service.display_name
973 SERVICECHECKCOMMAND | service.check_command
974 SERVICESTATE | service.state
975 SERVICESTATEID | service.state_id
976 SERVICESTATETYPE | service.state_type
977 SERVICEATTEMPT | service.check_attempt
978 MAXSERVICEATTEMPT | service.max_check_attempts
979 LASTSERVICESTATE | service.last_state
980 LASTSERVICESTATEID | service.last_state_id
981 LASTSERVICESTATETYPE | service.last_state_type
982 LASTSERVICESTATECHANGE | service.last_state_change
983 SERVICEDOWNTIME | service.downtime_depth
984 SERVICEDURATIONSEC | service.duration_sec
985 SERVICELATENCY | service.latency
986 SERVICEEXECUTIONTIME | service.execution_time
987 SERVICEOUTPUT | service.output
988 SERVICEPERFDATA | service.perfdata
989 LASTSERVICECHECK | service.last_check
990 SERVICENOTES | service.notes
991 SERVICENOTESURL | service.notes_url
992 SERVICEACTIONURL | service.action_url
995 Changes to host runtime macros
997 Icinga 1.x | Icinga 2
998 -----------------------|----------------------
1000 HOSTADDRESS | host.address
1001 HOSTADDRESS6 | host.address6
1002 HOSTDISPLAYNAME | host.display_name
1003 HOSTALIAS | (use `host.display_name` instead)
1004 HOSTCHECKCOMMAND | host.check_command
1005 HOSTSTATE | host.state
1006 HOSTSTATEID | host.state_id
1007 HOSTSTATETYPE | host.state_type
1008 HOSTATTEMPT | host.check_attempt
1009 MAXHOSTATTEMPT | host.max_check_attempts
1010 LASTHOSTSTATE | host.last_state
1011 LASTHOSTSTATEID | host.last_state_id
1012 LASTHOSTSTATETYPE | host.last_state_type
1013 LASTHOSTSTATECHANGE | host.last_state_change
1014 HOSTDOWNTIME | host.downtime_depth
1015 HOSTDURATIONSEC | host.duration_sec
1016 HOSTLATENCY | host.latency
1017 HOSTEXECUTIONTIME | host.execution_time
1018 HOSTOUTPUT | host.output
1019 HOSTPERFDATA | host.perfdata
1020 LASTHOSTCHECK | host.last_check
1021 HOSTNOTES | host.notes
1022 HOSTNOTESURL | host.notes_url
1023 HOSTACTIONURL | host.action_url
1024 TOTALSERVICES | host.num_services
1025 TOTALSERVICESOK | host.num_services_ok
1026 TOTALSERVICESWARNING | host.num_services_warning
1027 TOTALSERVICESUNKNOWN | host.num_services_unknown
1028 TOTALSERVICESCRITICAL | host.num_services_critical
1030 Changes to command runtime macros
1032 Icinga 1.x | Icinga 2
1033 -----------------------|----------------------
1034 COMMANDNAME | command.name
1036 Changes to notification runtime macros
1038 Icinga 1.x | Icinga 2
1039 -----------------------|----------------------
1040 NOTIFICATIONTYPE | notification.type
1041 NOTIFICATIONAUTHOR | notification.author
1042 NOTIFICATIONCOMMENT | notification.comment
1043 NOTIFICATIONAUTHORNAME | (use `notification.author`)
1044 NOTIFICATIONAUTHORALIAS | (use `notification.author`)
1047 Changes to global runtime macros:
1049 Icinga 1.x | Icinga 2
1050 -----------------------|----------------------
1051 TIMET | icinga.timet
1052 LONGDATETIME | icinga.long_date_time
1053 SHORTDATETIME | icinga.short_date_time
1056 PROCESSSTARTTIME | icinga.uptime
1058 Changes to global statistic macros:
1060 Icinga 1.x | Icinga 2
1061 ----------------------------------|----------------------
1062 TOTALHOSTSUP | icinga.num_hosts_up
1063 TOTALHOSTSDOWN | icinga.num_hosts_down
1064 TOTALHOSTSUNREACHABLE | icinga.num_hosts_unreachable
1065 TOTALHOSTSDOWNUNHANDLED | --
1066 TOTALHOSTSUNREACHABLEUNHANDLED | --
1067 TOTALHOSTPROBLEMS | down
1068 TOTALHOSTPROBLEMSUNHANDLED | down-(downtime+acknowledged)
1069 TOTALSERVICESOK | icinga.num_services_ok
1070 TOTALSERVICESWARNING | icinga.num_services_warning
1071 TOTALSERVICESCRITICAL | icinga.num_services_critical
1072 TOTALSERVICESUNKNOWN | icinga.num_services_unknown
1073 TOTALSERVICESWARNINGUNHANDLED | --
1074 TOTALSERVICESCRITICALUNHANDLED | --
1075 TOTALSERVICESUNKNOWNUNHANDLED | --
1076 TOTALSERVICEPROBLEMS | ok+warning+critical+unknown
1077 TOTALSERVICEPROBLEMSUNHANDLED | warning+critical+unknown-(downtime+acknowledged)
1082 ### <a id="differences-1x-2-external-commands"></a> External Commands
1084 `CHANGE_CUSTOM_CONTACT_VAR` was renamed to `CHANGE_CUSTOM_USER_VAR`.
1086 The following external commands are not supported:
1089 CHANGE_CONTACT_HOST_NOTIFICATION_TIMEPERIOD
1090 CHANGE_HOST_NOTIFICATION_TIMEPERIOD
1091 CHANGE_SVC_NOTIFICATION_TIMEPERIOD
1092 DEL_DOWNTIME_BY_HOSTGROUP_NAME
1093 DEL_DOWNTIME_BY_START_TIME_COMMENT
1094 DISABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1095 DISABLE_CONTACT_HOST_NOTIFICATIONS
1096 DISABLE_CONTACT_SVC_NOTIFICATIONS
1097 DISABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1098 DISABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1099 DISABLE_FAILURE_PREDICTION
1100 DISABLE_HOST_AND_CHILD_NOTIFICATIONS
1101 DISABLE_HOST_FRESHNESS_CHECKS
1102 DISABLE_NOTIFICATIONS_EXPIRE_TIME
1103 DISABLE_SERVICE_FRESHNESS_CHECKS
1104 ENABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1105 ENABLE_CONTACT_HOST_NOTIFICATIONS
1106 ENABLE_CONTACT_SVC_NOTIFICATIONS
1107 ENABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1108 ENABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1109 ENABLE_FAILURE_PREDICTION
1110 ENABLE_HOST_AND_CHILD_NOTIFICATIONS
1111 ENABLE_HOST_FRESHNESS_CHECKS
1112 ENABLE_SERVICE_FRESHNESS_CHECKS
1113 READ_STATE_INFORMATION
1114 SAVE_STATE_INFORMATION
1115 SCHEDULE_AND_PROPAGATE_HOST_DOWNTIME
1116 SCHEDULE_AND_PROPAGATE_TRIGGERED_HOST_DOWNTIME
1117 SET_HOST_NOTIFICATION_NUMBER
1118 SET_SVC_NOTIFICATION_NUMBER
1119 START_ACCEPTING_PASSIVE_HOST_CHECKS
1120 START_ACCEPTING_PASSIVE_SVC_CHECKS
1121 START_OBSESSING_OVER_HOST
1122 START_OBSESSING_OVER_HOST_CHECKS
1123 START_OBSESSING_OVER_SVC
1124 START_OBSESSING_OVER_SVC_CHECKS
1125 STOP_ACCEPTING_PASSIVE_HOST_CHECKS
1126 STOP_ACCEPTING_PASSIVE_SVC_CHECKS
1127 STOP_OBSESSING_OVER_HOST
1128 STOP_OBSESSING_OVER_HOST_CHECKS
1129 STOP_OBSESSING_OVER_SVC
1130 STOP_OBSESSING_OVER_SVC_CHECKS
1132 ### <a id="differences-1x-2-async-event-execution"></a> Asynchronous Event Execution
1134 Unlike Icinga 1.x, Icinga 2 does not block when it's waiting for a command
1135 being executed -- whether if it's a check, a notification, an event
1136 handler, a performance data writing update, etc. That way you'll
1137 recognize low to zero (check) latencies with Icinga 2.
1139 ### <a id="differences-1x-2-checks"></a> Checks
1141 #### <a id="differences-1x-2-check-output"></a> Check Output
1143 Icinga 2 does not make a difference between `output` (first line) and
1144 `long_output` (remaining lines) like in Icinga 1.x. Performance Data is
1145 provided separately.
1147 There is no output length restriction as known from Icinga 1.x using an
1148 [8KB static buffer](http://docs.icinga.org/latest/en/pluginapi.html#outputlengthrestrictions).
1150 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1151 split the raw output into `output` (first line) and `long_output` (remaining
1152 lines) for compatibility reasons.
1154 #### <a id="differences-1x-2-initial-state"></a> Initial State
1156 Icinga 1.x uses the `max_service_check_spread` setting to specify a timerange
1157 where the initial state checks must have happened. Icinga 2 will use the
1158 `retry_interval` setting instead and `check_interval` divided by 5 if
1159 `retry_interval` is not defined.
1161 ### <a id="differences-1x-2-comments"></a> Comments
1163 Icinga 2 doesn't support non-persistent comments.
1165 ### <a id="differences-1x-2-commands"></a> Commands
1167 Unlike in Icinga 1.x there are three different command types in Icinga 2:
1168 `CheckCommand`, `NotificationCommand`, and `EventCommand`.
1170 For example in Icinga 1.x it is possible to accidentally use a notification
1171 command as an event handler which might cause problems depending on which
1172 runtime macros are used in the notification command.
1174 In Icinga 2 these command types are separated and will generate an error on
1175 configuration validation if used in the wrong context.
1177 While Icinga 2 still supports the complete command line in command objects, it's
1178 recommended to use [command arguments](3-monitoring-basics.md#command-arguments)
1179 with optional and conditional command line parameters instead.
1181 It's also possible to define default argument values for the command itself
1182 which can be overridden by the host or service then.
1184 #### <a id="differences-1x-2-commands-timeouts"></a> Command Timeouts
1186 In Icinga 1.x there were two global options defining a host and service check
1187 timeout. This was essentially bad when there only was a couple of check plugins
1188 requiring some command timeouts to be extended.
1190 Icinga 2 allows you to specify the command timeout directly on the command. So,
1191 if your VMVware check plugin takes 15 minutes, [increase the timeout](6-object-types.md#objecttype-checkcommand)
1195 ### <a id="differences-1x-2-groups"></a> Groups
1197 In Icinga 2 hosts, services, and users are added to groups using the `groups`
1198 attribute in the object. The old way of listing all group members in the group's
1199 `members` attribute is available through `assign where` and `ignore where`
1200 expressions by using [group assign](3-monitoring-basics.md#group-assign-intro).
1202 object Host "web-dev" {
1203 import "generic-host"
1206 object HostGroup "dev-hosts" {
1207 display_name = "Dev Hosts"
1208 assign where match("*-dev", host.name)
1211 #### <a id="differences-1x-2-service-hostgroup-host"></a> Add Service to Hostgroup where Host is Member
1213 In order to associate a service with all hosts in a host group the [apply](3-monitoring-basics.md#using-apply)
1214 keyword can be used:
1216 apply Service "ping4" {
1217 import "generic-service"
1219 check_command = "ping4"
1221 assign where "dev-hosts" in host.groups
1224 ### <a id="differences-1x-2-notifications"></a> Notifications
1226 Notifications are a new object type in Icinga 2. Imagine the following
1227 notification configuration problem in Icinga 1.x:
1229 * Service A should notify contact X via SMS
1230 * Service B should notify contact X via Mail
1231 * Service C should notify contact Y via Mail and SMS
1232 * Contact X and Y should also be used for authorization (e.g. in Classic UI)
1234 The only way achieving a semi-clean solution is to
1236 * Create contact X-sms, set service_notification_command for sms, assign contact
1238 * Create contact X-mail, set service_notification_command for mail, assign
1239 contact to service B
1240 * Create contact Y, set service_notification_command for sms and mail, assign
1241 contact to service C
1242 * Create contact X without notification commands, assign to service A and B
1244 Basically you are required to create duplicated contacts for either each
1245 notification method or used for authorization only.
1247 Icinga 2 attempts to solve that problem in this way
1249 * Create user X, set SMS and Mail attributes, used for authorization
1250 * Create user Y, set SMS and Mail attributes, used for authorization
1251 * Create notification A-SMS, set command for sms, add user X,
1252 assign notification A-SMS to service A
1253 * Create notification B-Mail, set command for mail, add user X,
1254 assign notification Mail to service B
1255 * Create notification C-SMS, set command for sms, add user Y,
1256 assign notification C-SMS to service C
1257 * Create notification C-Mail, set command for mail, add user Y,
1258 assign notification C-Mail to service C
1260 Previously in Icinga 1.x it looked like this:
1262 service -> (contact, contactgroup) -> notification command
1264 In Icinga 2 it will look like this:
1266 Service -> Notification -> NotificationCommand
1269 #### <a id="differences-1x-2-escalations"></a> Escalations
1271 Escalations in Icinga 1.x require a separated object matching on existing
1272 objects. Escalations happen between a defined start and end time which is
1273 calculated from the notification_interval:
1275 start = notification start + (notification_interval * first_notification)
1276 end = notification start + (notification_interval * last_notification)
1278 In theory first_notification and last_notification can be set to readable
1279 numbers. In practice users are manipulating those attributes in combination
1280 with notification_interval in order to get a start and end time.
1282 In Icinga 2 the notification object can be used as notification escalation
1283 if the start and end times are defined within the 'times' attribute using
1284 duration literals (e.g. 30m).
1286 The Icinga 2 escalation does not replace the current running notification.
1287 In Icinga 1.x it's required to copy the contacts from the service notification
1288 to the escalation to guarantee the normal notifications once an escalation
1290 That's not necessary with Icinga 2 only requiring an additional notification
1291 object for the escalation itself.
1293 #### <a id="differences-1x-2-notification-options"></a> Notification Options
1295 Unlike Icinga 1.x with the 'notification_options' attribute with comma-separated
1296 state and type filters, Icinga 2 uses two configuration attributes for that.
1297 All state and type filter use long names OR'd with a pipe together
1299 notification_options w,u,c,r,f,s
1301 states = [ Warning, Unknown, Critical ]
1302 filters = [ Problem, Recovery, FlappingStart, FlappingEnd, DowntimeStart, DowntimeEnd, DowntimeRemoved ]
1304 Icinga 2 adds more fine-grained type filters for acknowledgements, downtime,
1305 and flapping type (start, end, ...).
1307 ### <a id="differences-1x-2-dependencies-parents"></a> Dependencies and Parents
1309 In Icinga 1.x it's possible to define host parents to determine network reachability
1310 and keep a host's state unreachable rather than down.
1311 Furthermore there are host and service dependencies preventing unnecessary checks and
1312 notifications. A host must not depend on a service, and vice versa. All dependencies
1313 are configured as separate objects and cannot be set directly on the host or service
1316 A service can now depend on a host, and vice versa. A service has an implicit dependency
1317 (parent) to its host. A host to host dependency acts implicitly as host parent relation.
1319 The former `host_name` and `dependent_host_name` have been renamed to `parent_host_name`
1320 and `child_host_name` (same for the service attribute). When using apply rules the
1321 child attributes may be omitted.
1323 For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
1326 Dependencies can be applied to hosts or services using the [apply rules](18-language-reference.md#apply).
1328 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1329 support the Icinga 1.x schema with dependencies and parent attributes for
1330 compatibility reasons.
1332 ### <a id="differences-1x-2-flapping"></a> Flapping
1334 The Icinga 1.x flapping detection uses the last 21 states of a service. This
1335 value is hardcoded and cannot be changed. The algorithm on determining a flapping state
1338 flapping value = (number of actual state changes / number of possible state changes)
1340 The flapping value is then compared to the low and high flapping thresholds.
1342 The algorithm used in Icinga 2 does not store the past states but calculates the flapping
1343 threshold from a single value based on counters and half-life values. Icinga 2 compares
1344 the value with a single flapping threshold configuration attribute.
1346 ### <a id="differences-1x-2-check-result-freshness"></a> Check Result Freshness
1348 Freshness of check results must be enabled explicitly in Icinga 1.x. The attribute
1349 `freshness_threshold` defines the threshold in seconds. Once the threshold is triggered, an
1350 active freshness check is executed defined by the `check_command` attribute. Both check
1351 methods (active and passive) use the same freshness check method.
1353 In Icinga 2 active check freshness is determined by the `check_interval` attribute and no
1354 incoming check results in that period of time (last check + check interval). Passive check
1355 freshness is calculated from the `check_interval` attribute if set. There is no extra
1356 `freshness_threshold` attribute in Icinga 2. If the freshness checks are invalid, a new
1357 service check is forced.
1359 ### <a id="differences-1x-2-real-reload"></a> Real Reload
1361 In Nagios / Icinga 1.x a daemon reload does the following:
1363 * receive reload signal SIGHUP
1364 * stop all events (checks, notifications, etc.)
1365 * read the configuration from disk and validate all config objects in a single threaded fashion
1366 * validation NOT ok: stop the daemon (cannot restore old config state)
1367 * validation ok: start with new objects, dump status.dat / ido
1369 Unlike Icinga 1.x the Icinga 2 daemon reload does not block any event
1370 execution during config validation:
1372 * receive reload signal SIGHUP
1373 * fork a child process, start configuration validation in parallel work queues
1374 * parent process continues with old configuration objects and the event scheduling
1375 (doing checks, replicating cluster events, triggering alert notifications, etc.)
1376 * validation NOT ok: child process terminates, parent process continues with old configuration state
1377 (this is **essential** for the [cluster config synchronisation](13-distributed-monitoring-ha.md#cluster-zone-config-sync))
1378 * validation ok: child process signals parent process to terminate and save its current state
1379 (all events until now) into the icinga2 state file
1380 * parent process shuts down writing icinga2.state file
1381 * child process waits for parent process gone, reads the icinga2 state file and synchronizes all historical and status data
1382 * child becomes the new session leader
1384 The DB IDO configuration dump and status/historical event updates use a queue
1385 not blocking event execution. Same goes for any other enabled feature.
1386 The configuration validation itself runs in parallel allowing fast verification checks.
1388 That way your monitoring does not stop during a configuration reload.
1391 ### <a id="differences-1x-2-state-retention"></a> State Retention
1393 Icinga 1.x uses the `retention.dat` file to save its state in order to be able
1394 to reload it after a restart. In Icinga 2 this file is called `icinga2.state`.
1396 The format is **not** compatible with Icinga 1.x.
1398 ### <a id="differences-1x-2-logging"></a> Logging
1400 Icinga 1.x supports syslog facilities and writes its own `icinga.log` log file
1401 and archives. These logs are used in Icinga 1.x Classic UI to generate
1404 Icinga 2 compat library provides the CompatLogger object which writes the icinga.log and archive
1405 in Icinga 1.x format in order to stay compatible with Classic UI and other addons.
1407 The native Icinga 2 logging facilities are split into three configuration objects: SyslogLogger,
1408 FileLogger, StreamLogger. Each of them has their own severity and target configuration.
1410 The Icinga 2 daemon log does not log any alerts but is considered an application log only.
1412 ### <a id="differences-1x-2-broker-modules-features"></a> Broker Modules and Features
1414 Icinga 1.x broker modules are incompatible with Icinga 2.
1416 In order to provide compatibility with Icinga 1.x the functionality of several
1417 popular broker modules was implemented for Icinga 2:
1421 * Cluster (allows for high availability and load balancing)
1424 ### <a id="differences-1x-2-distributed-monitoring"></a> Distributed Monitoring
1426 Icinga 1.x uses the native "obsess over host/service" method which requires the NSCA addon
1427 passing the slave's check results passively onto the master's external command pipe.
1428 While this method may be used for check load distribution, it does not provide any configuration
1429 distribution out-of-the-box. Furthermore comments, downtimes, and other stateful runtime data is
1430 not synced between the master and slave nodes. There are addons available solving the check
1431 and configuration distribution problems Icinga 1.x distributed monitoring currently suffers from.
1433 Icinga 2 implements a new built-in
1434 [distributed monitoring architecture](13-distributed-monitoring-ha.md#distributed-monitoring-high-availability),
1435 including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
1436 High Availability and load balancing are also part of the Icinga 2 Cluster feature, next to local replay
1437 logs on connection loss ensuring that the event history is kept in sync.