1 # Migration from Icinga 1.x <a id="migration"></a>
3 ## Configuration Migration <a id="configuration-migration"></a>
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 ### Manual Config Migration <a id="manual-config-migration"></a>
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 ### Manual Config Migration Hints <a id="manual-config-migration-hints"></a>
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 #### Manual Config Migration Hints for Intervals <a id="manual-config-migration-hints-Intervals"></a>
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 #### Manual Config Migration Hints for Services <a id="manual-config-migration-hints-services"></a>
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](03-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](03-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 #### Manual Config Migration Hints for Group Members <a id="manual-config-migration-hints-group-members"></a>
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](17-language-reference.md#group-assign). The additional nested hostgroup
115 `hg1` is included into `hg2` with the `groups` attribute.
118 object HostGroup "hg1" {
120 assign where host.name in [ "host1", "host2" ]
123 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 #### Manual Config Migration Hints for Check Command Arguments <a id="manual-config-migration-hints-check-command-arguments"></a>
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" {
157 PluginDir + "/check_ping", "-4"
161 "-H" = "$ping_address$"
162 "-w" = "$ping_wrta$,$ping_wpl$%"
163 "-c" = "$ping_crta$,$ping_cpl$%"
164 "-p" = "$ping_packets$"
165 "-t" = "$ping_timeout$"
168 vars.ping_address = "$address$"
175 object Service "my-ping" {
176 import "generic-service"
177 host_name = "my-server"
178 check_command = "my-ping-check"
186 #### Manual Config Migration Hints for Runtime Macros <a id="manual-config-migration-hints-runtime-macros"></a>
188 Runtime macros have been renamed. A detailed comparison table can be found [here](23-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
190 For example, accessing the service check output looks like the following in Icinga 1.x:
194 In Icinga 2 you will need to write:
198 Another example referencing the host's address attribute in Icinga 1.x:
202 In Icinga 2 you'd just use the following macro to access all `address` attributes (even overridden from the service objects):
207 #### Manual Config Migration Hints for Runtime Custom Attributes <a id="manual-config-migration-hints-runtime-custom-attributes"></a>
209 Custom variables from Icinga 1.x are available as Icinga 2 custom attributes.
212 command_name test_customvar
213 command_line echo "Host CV: $_HOSTCVTEST$ Service CV: $_SERVICECVTEST$\n"
218 check_command test_customvar
220 _CVTEST host cv value
224 service_description service1
226 check_command test_customvar
228 _CVTEST service cv value
231 Can be written as the following in Icinga 2:
233 object CheckCommand "test_customvar" {
234 command = "echo "Host CV: $host.vars.CVTEST$ Service CV: $service.vars.CVTEST$\n""
237 object Host "localhost1" {
238 import "generic-host"
239 check_command = "test_customvar"
240 vars.CVTEST = "host cv value"
243 object Service "service1" {
244 host_name = "localhost1"
245 check_command = "test_customvar"
246 vars.CVTEST = "service cv value"
249 If you are just defining `$CVTEST$` in your command definition, its value depends on the
250 execution scope -- the host check command will fetch the host attribute value of `vars.CVTEST`
251 while the service check command resolves its value to the service attribute attribute `vars.CVTEST`.
255 > Custom attributes in Icinga 2 are case-sensitive. `vars.CVTEST` is not the same as `vars.CvTest`.
257 #### Manual Config Migration Hints for Contacts (Users) <a id="manual-config-migration-hints-contacts-users"></a>
259 Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
260 This migration part is explained in the [next chapter](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
263 contact_name testconfig-user
265 alias Icinga Test User
266 service_notification_options c,f,s,u
267 email icinga@localhost
270 The `service_notification_options` can be [mapped](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
271 into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
272 renamed to `display_name`.
274 object User "testconfig-user" {
275 import "generic-user"
276 display_name = "Icinga Test User"
277 email = "icinga@localhost"
280 This user can be put into usergroups (former contactgroups) or referenced in newly migration notification
283 #### Manual Config Migration Hints for Notifications <a id="manual-config-migration-hints-notifications"></a>
285 If you are migrating a host or service notification, you'll need to extract the following information from
286 your existing Icinga 1.x configuration objects
288 * host/service attribute `contacts` and `contact_groups`
289 * host/service attribute `notification_options`
290 * host/service attribute `notification_period`
291 * host/service attribute `notification_interval`
293 The clean approach is to refactor your current contacts and their notification command methods into a
296 * host or service has a notification type (for example mail)
297 * which contacts (users) are notified by mail?
298 * do the notification filters, periods, intervals still apply for them? (do a cleanup during migration)
299 * assign users and groups to these notifications
300 * Redesign the notifications into generic [apply rules](03-monitoring-basics.md#using-apply-notifications)
303 The ugly workaround solution could look like this:
305 Extract all contacts from the remaining groups, and create a unique list. This is required for determining
306 the host and service notification commands involved.
308 * contact attributes `host_notification_commands` and `service_notification_commands` (can be a comma separated list)
309 * get the command line for each notification command and store them for later
310 * create a new notification name and command name
312 Generate a new notification object based on these values. Import the generic template based on the type (`host` or `service`).
313 Assign it to the host or service and set the newly generated notification command name as `command` attribute.
315 object Notification "<notificationname>" {
316 import "mail-host-notification"
317 host_name = "<thishostname>"
318 command = "<notificationcommandname>"
321 Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
322 [here](23-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
324 states = [ OK, Warning, Critical ]
325 types = [ Recovery, Problem, Custom ]
328 The current contact acts as `users` attribute.
330 users = [ "<contactwithnotificationcommand>" ]
333 Do this in a loop for all notification commands (depending if host or service contact). Once done, dump the
334 collected notification commands.
336 The result of this migration are lots of unnecessary notification objects and commands but it will unroll
337 the Icinga 1.x logic into the revamped Icinga 2 notification object schema. If you are looking for code
338 examples, try [LConf](https://www.netways.org).
342 #### Manual Config Migration Hints for Notification Filters <a id="manual-config-migration-hints-notification-filters"></a>
344 Icinga 1.x defines all notification filters in an attribute called `notification_options`. Using Icinga 2 you will
345 have to split these values into the `states` and `types` attributes.
349 > `Recovery` type requires the `Ok` state.
350 > `Custom` and `Problem` should always be set as `type` filter.
352 Icinga 1.x option | Icinga 2 state | Icinga 2 type
353 ----------------------|-----------------------|-------------------
354 o | OK (Up for hosts) |
355 w | Warning | Problem
356 c | Critical | Problem
357 u | Unknown | Problem
359 s | . | DowntimeStart / DowntimeEnd / DowntimeRemoved
361 f | . | FlappingStart / FlappingEnd
362 n | 0 (none) | 0 (none)
367 #### Manual Config Migration Hints for Escalations <a id="manual-config-migration-hints-escalations"></a>
369 Escalations in Icinga 1.x are a bit tricky. By default service escalations can be applied to hosts and
370 hostgroups and require a defined service object.
372 The following example applies a service escalation to the service `dep_svc01` and all hosts in the `hg_svcdep2`
373 hostgroup. The default `notification_interval` is set to `10` minutes notifying the `cg_admin` contact.
374 After 20 minutes (`10*2`, notification_interval * first_notification) the notification is escalated to the
375 `cg_ops` contactgroup until 60 minutes (`10*6`) have passed.
378 service_description dep_svc01
379 host_name dep_hostsvc01,dep_hostsvc03
382 notification_interval 10
383 contact_groups cg_admin
387 hostgroup_name hg_svcdep2
388 members dep_hostsvc03
391 # with hostgroup_name and service_description
392 define serviceescalation {
393 hostgroup_name hg_svcdep2
394 service_description dep_svc01
397 contact_groups cg_ops
400 In Icinga 2 the service and hostgroup definition will look quite the same. Save the `notification_interval`
401 and `contact_groups` attribute for an additional notification.
403 apply Service "dep_svc01" {
404 import "generic-service"
406 check_command = "test2"
408 assign where host.name == "dep_hostsvc01"
409 assign where host.name == "dep_hostsvc03"
412 object HostGroup "hg_svcdep2" {
413 assign where host.name == "dep_hostsvc03"
416 apply Notification "email" to Service {
417 import "service-mail-notification"
420 user_groups = [ "cg_admin" ]
422 assign where service.name == "dep_svc01" && (host.name == "dep_hostsvc01" || host.name == "dep_hostsvc03")
425 Calculate the begin and end time for the newly created escalation notification:
427 * begin = first_notification * notification_interval = 2 * 10m = 20m
428 * end = last_notification * notification_interval = 6 * 10m = 60m = 1h
430 Assign the notification escalation to the service `dep_svc01` on all hosts in the hostgroup `hg_svcdep2`.
432 apply Notification "email-escalation" to Service {
433 import "service-mail-notification"
436 user_groups = [ "cg_ops" ]
443 assign where service.name == "dep_svc01" && "hg_svcdep2" in host.groups
446 The assign rule could be made more generic and the notification be applied to more than
447 just this service belonging to hosts in the matched hostgroup.
452 > When the notification is escalated, Icinga 1.x suppresses notifications to the default contacts.
453 > In Icinga 2 an escalation is an additional notification with a defined begin and end time. The
454 > `email` notification will continue as normal.
458 #### Manual Config Migration Hints for Dependencies <a id="manual-config-migration-hints-dependencies"></a>
460 There are some dependency examples already in the [basics chapter](03-monitoring-basics.md#dependencies). Dependencies in
461 Icinga 1.x can be confusing in terms of which host/service is the parent and which host/service acts
464 While Icinga 1.x defines `notification_failure_criteria` and `execution_failure_criteria` as dependency
465 filters, this behaviour has changed in Icinga 2. There is no 1:1 migration but generally speaking
466 the state filter defined in the `execution_failure_criteria` defines the Icinga 2 `state` attribute.
467 If the state filter matches, you can define whether to disable checks and notifications or not.
469 The following example describes service dependencies. If you migrate from Icinga 1.x, you will only
470 want to use the classic `Host-to-Host` and `Service-to-Service` dependency relationships.
473 service_description dep_svc01
474 hostgroup_name hg_svcdep1
480 service_description dep_svc02
481 hostgroup_name hg_svcdep2
487 hostgroup_name hg_svcdep2
492 use linux-server-template
497 # with hostgroup_name and service_description
498 define servicedependency {
500 dependent_hostgroup_name hg_svcdep2
501 service_description dep_svc01
502 dependent_service_description *
503 execution_failure_criteria u,c
504 notification_failure_criteria w,u,c
508 Map the dependency attributes accordingly.
510 Icinga 1.x | Icinga 2
511 ----------------------|---------------------
512 host_name | parent_host_name
513 dependent_host_name | child_host_name (used in assign/ignore)
514 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
515 service_description | parent_service_name
516 dependent_service_description | child_service_name (used in assign/ignore)
518 And migrate the host and services.
520 object Host "host1" {
521 import "linux-server-template"
522 address = "192.168.1.10"
525 object HostGroup "hg_svcdep2" {
526 assign where host.name == "host2"
529 apply Service "dep_svc01" {
530 import "generic-service"
531 check_command = "test2"
533 assign where "hp_svcdep1" in host.groups
536 apply Service "dep_svc02" {
537 import "generic-service"
538 check_command = "test2"
540 assign where "hp_svcdep2" in host.groups
543 When it comes to the `execution_failure_criteria` and `notification_failure_criteria` attribute migration,
544 you will need to map the most common values, in this example `u,c` (`Unknown` and `Critical` will cause the
545 dependency to fail). Therefore the `Dependency` should be ok on Ok and Warning. `inherits_parents` is always
548 apply Dependency "all-svc-for-hg-hg_svcdep2-on-host1-dep_svc01" to Service {
549 parent_host_name = "host1"
550 parent_service_name = "dep_svc01"
552 states = [ Ok, Warning ]
553 disable_checks = true
554 disable_notifications = true
556 assign where "hg_svcdep2" in host.groups
559 Host dependencies are explained in the [next chapter](23-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
563 #### Manual Config Migration Hints for Host Parents <a id="manual-config-migration-hints-host-parents"></a>
565 Host parents from Icinga 1.x are migrated into `Host-to-Host` dependencies in Icinga 2.
567 The following example defines the `vmware-master` host as parent host for the guest
568 virtual machines `vmware-vm1` and `vmware-vm2`.
570 By default all hosts in the hostgroup `vmware` should get the parent assigned. This isn't really
571 solvable with Icinga 1.x parents, but only with host dependencies.
574 use linux-server-template
575 host_name vmware-master
581 use linux-server-template
585 parents vmware-master
589 use linux-server-template
593 parents vmware-master
596 By default all hosts in the hostgroup `vmware` should get the parent assigned (but not the `vmware-master`
597 host itself). This isn't really solvable with Icinga 1.x parents, but only with host dependencies as shown
600 define hostdependency {
601 dependent_hostgroup_name vmware
602 dependent_host_name !vmware-master
603 host_name vmware-master
605 notification_failure_criteria d,u
606 execution_failure_criteria d,u
607 dependency_period testconfig-24x7
610 When migrating to Icinga 2, the parents must be changed to a newly created host dependency.
613 Map the following attributes
615 Icinga 1.x | Icinga 2
616 ----------------------|---------------------
617 host_name | parent_host_name
618 dependent_host_name | child_host_name (used in assign/ignore)
619 dependent_hostgroup_name | all child hosts in group (used in assign/ignore)
621 The Icinga 2 configuration looks like this:
624 object Host "vmware-master" {
625 import "linux-server-template"
626 groups += [ "vmware" ]
627 address = "192.168.1.10"
628 vars.is_vmware_master = true
631 object Host "vmware-vm1" {
632 import "linux-server-template"
633 groups += [ "vmware" ]
634 address = "192.168.27.1"
637 object Host "vmware-vm2" {
638 import "linux-server-template"
639 groups += [ "vmware" ]
640 address = "192.168.28.1"
643 apply Dependency "vmware-master" to Host {
644 parent_host_name = "vmware-master"
646 assign where "vmware" in host.groups
647 ignore where host.vars.is_vmware_master
648 ignore where host.name == "vmware-master"
651 For easier identification you could add the `vars.is_vmware_master` attribute to the `vmware-master`
652 host and let the dependency ignore that instead of the hardcoded host name. That's different
653 to the Icinga 1.x example and a best practice hint only.
656 Another way to express the same configuration would be something like:
658 object Host "vmware-master" {
659 import "linux-server-template"
660 groups += [ "vmware" ]
661 address = "192.168.1.10"
664 object Host "vmware-vm1" {
665 import "linux-server-template"
666 groups += [ "vmware" ]
667 address = "192.168.27.1"
668 vars.parents = [ "vmware-master" ]
671 object Host "vmware-vm2" {
672 import "linux-server-template"
673 groups += [ "vmware" ]
674 address = "192.168.28.1"
675 vars.parents = [ "vmware-master" ]
678 apply Dependency "host-to-parent-" for (parent in host.vars.parents) to Host {
679 parent_host_name = parent
682 This example allows finer grained host-to-host dependency, as well as multiple dependency support.
684 #### Manual Config Migration Hints for Distributed Setups <a id="manual-config-migration-hints-distributed-setup"></a>
686 * Icinga 2 does not use active/passive instances calling OSCP commands and requiring the NSCA
687 daemon for passing check results between instances.
688 * Icinga 2 does not support any 1.x NEB addons for check load distribution
690 * If your current setup consists of instances distributing the check load, you should consider
691 building a [load distribution](06-distributed-monitoring.md#distributed-monitoring-scenarios) setup with Icinga 2.
692 * If your current setup includes active/passive clustering with external tools like Pacemaker/DRBD,
693 consider the [High Availability](06-distributed-monitoring.md#distributed-monitoring-scenarios) setup.
694 * If you have build your own custom configuration deployment and check result collecting mechanism,
695 you should re-design your setup and re-evaluate your requirements, and how they may be fulfilled
696 using the Icinga 2 cluster capabilities.
699 ## Differences between Icinga 1.x and 2 <a id="differences-1x-2"></a>
701 ### Configuration Format <a id="differences-1x-2-configuration-format"></a>
703 Icinga 1.x supports two configuration formats: key-value-based settings in the
704 `icinga.cfg` configuration file and object-based in included files (`cfg_dir`,
705 `cfg_file`). The path to the `icinga.cfg` configuration file must be passed to
706 the Icinga daemon at startup.
710 enable_notifications=1
715 notifications_enabled 0
718 Icinga 2 supports objects and (global) variables, but does not make a difference
719 between the main configuration file or any other included file.
723 const EnableNotifications = true
725 object Service "test" {
726 enable_notifications = false
729 #### Sample Configuration and ITL <a id="differences-1x-2-sample-configuration-itl"></a>
731 While Icinga 1.x ships sample configuration and templates spread in various
732 object files, Icinga 2 moves all templates into the Icinga Template Library (ITL)
733 and includes them in the sample configuration.
735 Additional plugin check commands are shipped with Icinga 2 as well.
737 The ITL will be updated on every release and must not be edited by the user.
739 There are still generic templates available for your convenience which may or may
740 not be re-used in your configuration. For instance, `generic-service` includes
741 all required attributes except `check_command` for a service.
743 Sample configuration files are located in the `conf.d/` directory which is
744 included in `icinga2.conf` by default.
748 > Add your own custom templates in the `conf.d/` directory as well, e.g. inside
749 > the [templates.conf](04-configuring-icinga-2.md#templates-conf) file.
751 ### Main Config File <a id="differences-1x-2-main-config"></a>
753 In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
754 Icinga 2 only uses a small set of [global constants](17-language-reference.md#constants) allowing
755 you to specify certain different setting such as the `NodeName` in a cluster scenario.
757 Aside from that, the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) should take care of including
758 global constants, enabled [features](11-cli-commands.md#enable-features) and the object configuration.
760 ### Include Files and Directories <a id="differences-1x-2-include-files-dirs"></a>
762 In Icinga 1.x the `icinga.cfg` file contains `cfg_file` and `cfg_dir`
763 directives. The `cfg_dir` directive recursively includes all files with a `.cfg`
764 suffix in the given directory. Only absolute paths may be used. The `cfg_file`
765 and `cfg_dir` directives can include the same file twice which leads to
766 configuration errors in Icinga 1.x.
768 cfg_file=/etc/icinga/objects/commands.cfg
769 cfg_dir=/etc/icinga/objects
771 Icinga 2 supports wildcard includes and relative paths, e.g. for including
772 `conf.d/*.conf` in the same directory.
774 include "conf.d/*.conf"
776 If you want to include files and directories recursively, you need to define
777 a separate option and add the directory and an optional pattern.
779 include_recursive "conf.d"
781 A global search path for includes is available for advanced features like
782 the Icinga Template Library (ITL) or additional monitoring plugins check
783 command configuration.
788 By convention the `.conf` suffix is used for Icinga 2 configuration files.
790 ### Resource File and Global Macros <a id="differences-1x-2-resource-file-global-macros"></a>
792 Global macros such as for the plugin directory, usernames and passwords can be
793 set in the `resource.cfg` configuration file in Icinga 1.x. By convention the
794 `USER1` macro is used to define the directory for the plugins.
796 Icinga 2 uses global constants instead. In the default config these are
797 set in the `constants.conf` configuration file:
800 * This file defines global constants which can be used in
801 * the other configuration files. At a minimum the
802 * PluginDir constant should be defined.
805 const PluginDir = "/usr/lib/nagios/plugins"
807 [Global macros](17-language-reference.md#constants) can only be defined once. Trying to modify a
808 global constant will result in an error.
810 ### Configuration Comments <a id="differences-1x-2-configuration-comments"></a>
812 In Icinga 1.x comments are made using a leading hash (`#`) or a semi-colon (`;`)
815 In Icinga 2 comments can either be encapsulated by `/*` and `*/` (allowing for
816 multi-line comments) or starting with two slashes (`//`). A leading hash (`#`)
819 ### Object Names <a id="differences-1x-2-object-names"></a>
821 Object names must not contain an exclamation mark (`!`). Use the `display_name` attribute
822 to specify user-friendly names which should be shown in UIs (supported by
823 Icinga Web 2 for example).
825 Object names are not specified using attributes (e.g. `service_description` for
826 services) like in Icinga 1.x but directly after their type definition.
830 service_description ping4
833 object Service "ping4" {
834 host_name = "localhost"
837 ### Templates <a id="differences-1x-2-templates"></a>
839 In Icinga 1.x templates are identified using the `register 0` setting. Icinga 2
840 uses the `template` identifier:
842 template Service "ping4-template" { }
844 Icinga 1.x objects inherit from templates using the `use` attribute.
845 Icinga 2 uses the keyword `import` with template names in double quotes.
848 service_description testservice
849 use tmpl1,tmpl2,tmpl3
852 object Service "testservice" {
858 The last template overrides previously set values.
860 ### Object attributes <a id="differences-1x-2-object-attributes"></a>
862 Icinga 1.x separates attribute and value pairs with whitespaces/tabs. Icinga 2
863 requires an equal sign (=) between them.
869 object Service "test" {
873 Please note that the default time value is seconds if no duration literal
874 is given. `check_interval = 5` behaves the same as `check_interval = 5s`.
876 All strings require double quotes in Icinga 2. Therefore a double quote
877 must be escaped by a backslash (e.g. in command line).
878 If an attribute identifier starts with a number, it must be enclosed
879 in double quotes as well.
881 #### Alias vs. Display Name <a id="differences-1x-2-alias-display-name"></a>
883 In Icinga 1.x a host can have an `alias` and a `display_name` attribute used
884 for a more descriptive name. A service only can have a `display_name` attribute.
885 The `alias` is used for group, timeperiod, etc. objects too.
886 Icinga 2 only supports the `display_name` attribute which is also taken into
887 account by Icinga web interfaces.
889 ### Custom Attributes <a id="differences-1x-2-custom-attributes"></a>
891 Icinga 2 allows you to define custom attributes in the `vars` dictionary.
892 The `notes`, `notes_url`, `action_url`, `icon_image`, `icon_image_alt`
893 attributes for host and service objects are still available in Icinga 2.
895 `2d_coords` and `statusmap_image` are not supported in Icinga 2.
897 #### Custom Variables <a id="differences-1x-2-custom-variables"></a>
899 Icinga 1.x custom variable attributes must be prefixed using an underscore (`_`).
900 In Icinga 2 these attributes must be added to the `vars` dictionary as custom attributes.
902 vars.dn = "cn=icinga2-dev-host,ou=icinga,ou=main,ou=IcingaConfig,ou=LConf,dc=icinga,dc=org"
903 vars.cv = "my custom cmdb description"
905 These custom attributes are also used as [command parameters](03-monitoring-basics.md#command-passing-parameters).
907 While Icinga 1.x only supports numbers and strings as custom attribute values,
908 Icinga 2 extends that to arrays and (nested) dictionaries. For more details
909 look [here](03-monitoring-basics.md#custom-attributes).
911 ### Host Service Relation <a id="differences-1x-2-host-service-relation"></a>
913 In Icinga 1.x a service object is associated with a host by defining the
914 `host_name` attribute in the service definition. Alternate methods refer
915 to `hostgroup_name` or behaviour changing regular expression.
917 The preferred way of associating hosts with services in Icinga 2 is by
918 using the [apply](03-monitoring-basics.md#using-apply) keyword.
920 Direct object relations between a service and a host still allow you to use
921 the `host_name` [Service](09-object-types.md#objecttype-service) object attribute.
923 ### Users <a id="differences-1x-2-users"></a>
925 Contacts have been renamed to users (same for groups). A contact does not
926 only provide (custom) attributes and notification commands used for notifications,
927 but is also used for authorization checks in Icinga 1.x.
929 Icinga 2 changes that behavior and makes the user an attribute provider only.
930 These attributes can be accessed using [runtime macros](03-monitoring-basics.md#runtime-macros)
931 inside notification command definitions.
933 In Icinga 2 notification commands are not directly associated with users.
934 Instead the notification command is specified inside `Notification` objects next to
935 user and user group relations.
937 The `StatusDataWriter`, `IdoMySqlConnection` and `LivestatusListener` types will
938 provide the contact and contactgroups attributes for services for compatibility
939 reasons. These values are calculated from all services, their notifications,
942 ### Macros <a id="differences-1x-2-macros"></a>
944 Various object attributes and runtime variables can be accessed as macros in
945 commands in Icinga 1.x -- Icinga 2 supports all required [custom attributes](03-monitoring-basics.md#custom-attributes).
947 #### Command Arguments <a id="differences-1x-2-command-arguments"></a>
949 If you have previously used Icinga 1.x, you may already be familiar with
950 user and argument definitions (e.g., `USER1` or `ARG1`). Unlike in Icinga 1.x
951 the Icinga 2 custom attributes may have arbitrary names and arguments are no
952 longer specified in the `check_command` setting.
954 In Icinga 1.x arguments are specified in the `check_command` attribute and
955 are separated from the command name using an exclamation mark (`!`).
957 Please check the migration hints for a detailed
958 [migration example](23-migrating-from-icinga-1x.md#manual-config-migration-hints-check-command-arguments).
962 > The Icinga 1.x feature named `Command Expander` does not work with Icinga 2.
964 #### Environment Macros <a id="differences-1x-2-environment-macros"></a>
966 The global configuration setting `enable_environment_macros` does not exist in
969 Macros exported into the [environment](03-monitoring-basics.md#command-environment-variables)
970 can be set using the `env` attribute in command objects.
972 #### Runtime Macros <a id="differences-1x-2-runtime-macros"></a>
974 Icinga 2 requires an object specific namespace when accessing configuration
975 and stateful runtime macros. Custom attributes can be accessed directly.
977 If a runtime macro from Icinga 1.x is not listed here, it is not supported
980 Changes to user (contact) runtime macros
982 Icinga 1.x | Icinga 2
983 -----------------------|----------------------
984 CONTACTNAME | user.name
985 CONTACTALIAS | user.display_name
986 CONTACTEMAIL | user.email
987 CONTACTPAGER | user.pager
989 `CONTACTADDRESS*` is not supported but can be accessed as `$user.vars.address1$`
992 Changes to service runtime macros
994 Icinga 1.x | Icinga 2
995 -----------------------|----------------------
996 SERVICEDESC | service.name
997 SERVICEDISPLAYNAME | service.display_name
998 SERVICECHECKCOMMAND | service.check_command
999 SERVICESTATE | service.state
1000 SERVICESTATEID | service.state_id
1001 SERVICESTATETYPE | service.state_type
1002 SERVICEATTEMPT | service.check_attempt
1003 MAXSERVICEATTEMPT | service.max_check_attempts
1004 LASTSERVICESTATE | service.last_state
1005 LASTSERVICESTATEID | service.last_state_id
1006 LASTSERVICESTATETYPE | service.last_state_type
1007 LASTSERVICESTATECHANGE | service.last_state_change
1008 SERVICEDOWNTIME | service.downtime_depth
1009 SERVICEDURATIONSEC | service.duration_sec
1010 SERVICELATENCY | service.latency
1011 SERVICEEXECUTIONTIME | service.execution_time
1012 SERVICEOUTPUT | service.output
1013 SERVICEPERFDATA | service.perfdata
1014 LASTSERVICECHECK | service.last_check
1015 SERVICENOTES | service.notes
1016 SERVICENOTESURL | service.notes_url
1017 SERVICEACTIONURL | service.action_url
1020 Changes to host runtime macros
1022 Icinga 1.x | Icinga 2
1023 -----------------------|----------------------
1024 HOSTNAME | host.name
1025 HOSTADDRESS | host.address
1026 HOSTADDRESS6 | host.address6
1027 HOSTDISPLAYNAME | host.display_name
1028 HOSTALIAS | (use `host.display_name` instead)
1029 HOSTCHECKCOMMAND | host.check_command
1030 HOSTSTATE | host.state
1031 HOSTSTATEID | host.state_id
1032 HOSTSTATETYPE | host.state_type
1033 HOSTATTEMPT | host.check_attempt
1034 MAXHOSTATTEMPT | host.max_check_attempts
1035 LASTHOSTSTATE | host.last_state
1036 LASTHOSTSTATEID | host.last_state_id
1037 LASTHOSTSTATETYPE | host.last_state_type
1038 LASTHOSTSTATECHANGE | host.last_state_change
1039 HOSTDOWNTIME | host.downtime_depth
1040 HOSTDURATIONSEC | host.duration_sec
1041 HOSTLATENCY | host.latency
1042 HOSTEXECUTIONTIME | host.execution_time
1043 HOSTOUTPUT | host.output
1044 HOSTPERFDATA | host.perfdata
1045 LASTHOSTCHECK | host.last_check
1046 HOSTNOTES | host.notes
1047 HOSTNOTESURL | host.notes_url
1048 HOSTACTIONURL | host.action_url
1049 TOTALSERVICES | host.num_services
1050 TOTALSERVICESOK | host.num_services_ok
1051 TOTALSERVICESWARNING | host.num_services_warning
1052 TOTALSERVICESUNKNOWN | host.num_services_unknown
1053 TOTALSERVICESCRITICAL | host.num_services_critical
1055 Changes to command runtime macros
1057 Icinga 1.x | Icinga 2
1058 -----------------------|----------------------
1059 COMMANDNAME | command.name
1061 Changes to notification runtime macros
1063 Icinga 1.x | Icinga 2
1064 -----------------------|----------------------
1065 NOTIFICATIONTYPE | notification.type
1066 NOTIFICATIONAUTHOR | notification.author
1067 NOTIFICATIONCOMMENT | notification.comment
1068 NOTIFICATIONAUTHORNAME | (use `notification.author`)
1069 NOTIFICATIONAUTHORALIAS | (use `notification.author`)
1072 Changes to global runtime macros:
1074 Icinga 1.x | Icinga 2
1075 -----------------------|----------------------
1076 TIMET | icinga.timet
1077 LONGDATETIME | icinga.long_date_time
1078 SHORTDATETIME | icinga.short_date_time
1081 PROCESSSTARTTIME | icinga.uptime
1083 Changes to global statistic macros:
1085 Icinga 1.x | Icinga 2
1086 ----------------------------------|----------------------
1087 TOTALHOSTSUP | icinga.num_hosts_up
1088 TOTALHOSTSDOWN | icinga.num_hosts_down
1089 TOTALHOSTSUNREACHABLE | icinga.num_hosts_unreachable
1090 TOTALHOSTSDOWNUNHANDLED | --
1091 TOTALHOSTSUNREACHABLEUNHANDLED | --
1092 TOTALHOSTPROBLEMS | down
1093 TOTALHOSTPROBLEMSUNHANDLED | down-(downtime+acknowledged)
1094 TOTALSERVICESOK | icinga.num_services_ok
1095 TOTALSERVICESWARNING | icinga.num_services_warning
1096 TOTALSERVICESCRITICAL | icinga.num_services_critical
1097 TOTALSERVICESUNKNOWN | icinga.num_services_unknown
1098 TOTALSERVICESWARNINGUNHANDLED | --
1099 TOTALSERVICESCRITICALUNHANDLED | --
1100 TOTALSERVICESUNKNOWNUNHANDLED | --
1101 TOTALSERVICEPROBLEMS | ok+warning+critical+unknown
1102 TOTALSERVICEPROBLEMSUNHANDLED | warning+critical+unknown-(downtime+acknowledged)
1107 ### External Commands <a id="differences-1x-2-external-commands"></a>
1109 `CHANGE_CUSTOM_CONTACT_VAR` was renamed to `CHANGE_CUSTOM_USER_VAR`.
1111 The following external commands are not supported:
1114 CHANGE_CONTACT_HOST_NOTIFICATION_TIMEPERIOD
1115 CHANGE_HOST_NOTIFICATION_TIMEPERIOD
1116 CHANGE_SVC_NOTIFICATION_TIMEPERIOD
1117 DEL_DOWNTIME_BY_HOSTGROUP_NAME
1118 DEL_DOWNTIME_BY_START_TIME_COMMENT
1119 DISABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1120 DISABLE_CONTACT_HOST_NOTIFICATIONS
1121 DISABLE_CONTACT_SVC_NOTIFICATIONS
1122 DISABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1123 DISABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1124 DISABLE_FAILURE_PREDICTION
1125 DISABLE_HOST_AND_CHILD_NOTIFICATIONS
1126 DISABLE_HOST_FRESHNESS_CHECKS
1127 DISABLE_NOTIFICATIONS_EXPIRE_TIME
1128 DISABLE_SERVICE_FRESHNESS_CHECKS
1129 ENABLE_ALL_NOTIFICATIONS_BEYOND_HOST
1130 ENABLE_CONTACT_HOST_NOTIFICATIONS
1131 ENABLE_CONTACT_SVC_NOTIFICATIONS
1132 ENABLE_CONTACTGROUP_HOST_NOTIFICATIONS
1133 ENABLE_CONTACTGROUP_SVC_NOTIFICATIONS
1134 ENABLE_FAILURE_PREDICTION
1135 ENABLE_HOST_AND_CHILD_NOTIFICATIONS
1136 ENABLE_HOST_FRESHNESS_CHECKS
1137 ENABLE_SERVICE_FRESHNESS_CHECKS
1138 READ_STATE_INFORMATION
1139 SAVE_STATE_INFORMATION
1140 SET_HOST_NOTIFICATION_NUMBER
1141 SET_SVC_NOTIFICATION_NUMBER
1142 START_ACCEPTING_PASSIVE_HOST_CHECKS
1143 START_ACCEPTING_PASSIVE_SVC_CHECKS
1144 START_OBSESSING_OVER_HOST
1145 START_OBSESSING_OVER_HOST_CHECKS
1146 START_OBSESSING_OVER_SVC
1147 START_OBSESSING_OVER_SVC_CHECKS
1148 STOP_ACCEPTING_PASSIVE_HOST_CHECKS
1149 STOP_ACCEPTING_PASSIVE_SVC_CHECKS
1150 STOP_OBSESSING_OVER_HOST
1151 STOP_OBSESSING_OVER_HOST_CHECKS
1152 STOP_OBSESSING_OVER_SVC
1153 STOP_OBSESSING_OVER_SVC_CHECKS
1155 ### Asynchronous Event Execution <a id="differences-1x-2-async-event-execution"></a>
1157 Unlike Icinga 1.x, Icinga 2 does not block when it's waiting for a command
1158 being executed -- whether if it's a check, a notification, an event
1159 handler, a performance data writing update, etc. That way you'll
1160 recognize low to zero (check) latencies with Icinga 2.
1162 ### Checks <a id="differences-1x-2-checks"></a>
1164 #### Check Output <a id="differences-1x-2-check-output"></a>
1166 Icinga 2 does not make a difference between `output` (first line) and
1167 `long_output` (remaining lines) like in Icinga 1.x. Performance Data is
1168 provided separately.
1170 There is no output length restriction as known from Icinga 1.x using an
1171 [8KB static buffer](https://docs.icinga.com/latest/en/pluginapi.html#outputlengthrestrictions).
1173 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1174 split the raw output into `output` (first line) and `long_output` (remaining
1175 lines) for compatibility reasons.
1177 #### Initial State <a id="differences-1x-2-initial-state"></a>
1179 Icinga 1.x uses the `max_service_check_spread` setting to specify a timerange
1180 where the initial state checks must have happened. Icinga 2 will use the
1181 `retry_interval` setting instead and `check_interval` divided by 5 if
1182 `retry_interval` is not defined.
1184 ### Comments <a id="differences-1x-2-comments"></a>
1186 Icinga 2 doesn't support non-persistent comments.
1188 ### Commands <a id="differences-1x-2-commands"></a>
1190 Unlike in Icinga 1.x there are three different command types in Icinga 2:
1191 `CheckCommand`, `NotificationCommand`, and `EventCommand`.
1193 For example in Icinga 1.x it is possible to accidentally use a notification
1194 command as an event handler which might cause problems depending on which
1195 runtime macros are used in the notification command.
1197 In Icinga 2 these command types are separated and will generate an error on
1198 configuration validation if used in the wrong context.
1200 While Icinga 2 still supports the complete command line in command objects, it's
1201 recommended to use [command arguments](03-monitoring-basics.md#command-arguments)
1202 with optional and conditional command line parameters instead.
1204 It's also possible to define default argument values for the command itself
1205 which can be overridden by the host or service then.
1207 #### Command Timeouts <a id="differences-1x-2-commands-timeouts"></a>
1209 In Icinga 1.x there were two global options defining a host and service check
1210 timeout. This was essentially bad when there only was a couple of check plugins
1211 requiring some command timeouts to be extended.
1213 Icinga 2 allows you to specify the command timeout directly on the command. So,
1214 if your VMVware check plugin takes 15 minutes, [increase the timeout](09-object-types.md#objecttype-checkcommand)
1218 ### Groups <a id="differences-1x-2-groups"></a>
1220 In Icinga 2 hosts, services, and users are added to groups using the `groups`
1221 attribute in the object. The old way of listing all group members in the group's
1222 `members` attribute is available through `assign where` and `ignore where`
1223 expressions by using [group assign](03-monitoring-basics.md#group-assign-intro).
1225 object Host "web-dev" {
1226 import "generic-host"
1229 object HostGroup "dev-hosts" {
1230 display_name = "Dev Hosts"
1231 assign where match("*-dev", host.name)
1234 #### Add Service to Hostgroup where Host is Member <a id="differences-1x-2-service-hostgroup-host"></a>
1236 In order to associate a service with all hosts in a host group the [apply](03-monitoring-basics.md#using-apply)
1237 keyword can be used:
1239 apply Service "ping4" {
1240 import "generic-service"
1242 check_command = "ping4"
1244 assign where "dev-hosts" in host.groups
1247 ### Notifications <a id="differences-1x-2-notifications"></a>
1249 Notifications are a new object type in Icinga 2. Imagine the following
1250 notification configuration problem in Icinga 1.x:
1252 * Service A should notify contact X via SMS
1253 * Service B should notify contact X via Mail
1254 * Service C should notify contact Y via Mail and SMS
1255 * Contact X and Y should also be used for authorization
1257 The only way achieving a semi-clean solution is to
1259 * Create contact X-sms, set service_notification_command for sms, assign contact
1261 * Create contact X-mail, set service_notification_command for mail, assign
1262 contact to service B
1263 * Create contact Y, set service_notification_command for sms and mail, assign
1264 contact to service C
1265 * Create contact X without notification commands, assign to service A and B
1267 Basically you are required to create duplicated contacts for either each
1268 notification method or used for authorization only.
1270 Icinga 2 attempts to solve that problem in this way
1272 * Create user X, set SMS and Mail attributes, used for authorization
1273 * Create user Y, set SMS and Mail attributes, used for authorization
1274 * Create notification A-SMS, set command for sms, add user X,
1275 assign notification A-SMS to service A
1276 * Create notification B-Mail, set command for mail, add user X,
1277 assign notification Mail to service B
1278 * Create notification C-SMS, set command for sms, add user Y,
1279 assign notification C-SMS to service C
1280 * Create notification C-Mail, set command for mail, add user Y,
1281 assign notification C-Mail to service C
1283 Previously in Icinga 1.x it looked like this:
1285 service -> (contact, contactgroup) -> notification command
1287 In Icinga 2 it will look like this:
1289 Service -> Notification -> NotificationCommand
1292 #### Escalations <a id="differences-1x-2-escalations"></a>
1294 Escalations in Icinga 1.x require a separated object matching on existing
1295 objects. Escalations happen between a defined start and end time which is
1296 calculated from the notification_interval:
1298 start = notification start + (notification_interval * first_notification)
1299 end = notification start + (notification_interval * last_notification)
1301 In theory first_notification and last_notification can be set to readable
1302 numbers. In practice users are manipulating those attributes in combination
1303 with notification_interval in order to get a start and end time.
1305 In Icinga 2 the notification object can be used as notification escalation
1306 if the start and end times are defined within the 'times' attribute using
1307 duration literals (e.g. 30m).
1309 The Icinga 2 escalation does not replace the current running notification.
1310 In Icinga 1.x it's required to copy the contacts from the service notification
1311 to the escalation to guarantee the normal notifications once an escalation
1313 That's not necessary with Icinga 2 only requiring an additional notification
1314 object for the escalation itself.
1316 #### Notification Options <a id="differences-1x-2-notification-options"></a>
1318 Unlike Icinga 1.x with the 'notification_options' attribute with comma-separated
1319 state and type filters, Icinga 2 uses two configuration attributes for that.
1320 All state and type filter use long names OR'd with a pipe together
1322 notification_options w,u,c,r,f,s
1324 states = [ Warning, Unknown, Critical ]
1325 types = [ Problem, Recovery, FlappingStart, FlappingEnd, DowntimeStart, DowntimeEnd, DowntimeRemoved ]
1327 Icinga 2 adds more fine-grained type filters for acknowledgements, downtime,
1328 and flapping type (start, end, ...).
1330 ### Dependencies and Parents <a id="differences-1x-2-dependencies-parents"></a>
1332 In Icinga 1.x it's possible to define host parents to determine network reachability
1333 and keep a host's state unreachable rather than down.
1334 Furthermore there are host and service dependencies preventing unnecessary checks and
1335 notifications. A host must not depend on a service, and vice versa. All dependencies
1336 are configured as separate objects and cannot be set directly on the host or service
1339 A service can now depend on a host, and vice versa. A service has an implicit dependency
1340 (parent) to its host. A host to host dependency acts implicitly as host parent relation.
1342 The former `host_name` and `dependent_host_name` have been renamed to `parent_host_name`
1343 and `child_host_name` (same for the service attribute). When using apply rules the
1344 child attributes may be omitted.
1346 For detailed examples on how to use the dependencies please check the [dependencies](03-monitoring-basics.md#dependencies)
1349 Dependencies can be applied to hosts or services using the [apply rules](17-language-reference.md#apply).
1351 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
1352 support the Icinga 1.x schema with dependencies and parent attributes for
1353 compatibility reasons.
1355 ### Flapping <a id="differences-1x-2-flapping"></a>
1357 The Icinga 1.x flapping detection uses the last 21 states of a service. This
1358 value is hardcoded and cannot be changed. The algorithm on determining a flapping state
1361 flapping value = (number of actual state changes / number of possible state changes)
1363 The flapping value is then compared to the low and high flapping thresholds.
1365 The algorithm used in Icinga 2 does not store the past states but calculates the flapping
1366 threshold from a single value based on counters and half-life values. Icinga 2 compares
1367 the value with a single flapping threshold configuration attribute.
1369 ### Check Result Freshness <a id="differences-1x-2-check-result-freshness"></a>
1371 Freshness of check results must be enabled explicitly in Icinga 1.x. The attribute
1372 `freshness_threshold` defines the threshold in seconds. Once the threshold is triggered, an
1373 active freshness check is executed defined by the `check_command` attribute. Both check
1374 methods (active and passive) use the same freshness check method.
1376 In Icinga 2 active check freshness is determined by the `check_interval` attribute and no
1377 incoming check results in that period of time (last check + check interval). Passive check
1378 freshness is calculated from the `check_interval` attribute if set. There is no extra
1379 `freshness_threshold` attribute in Icinga 2. If the freshness checks are invalid, a new
1380 service check is forced.
1382 ### Real Reload <a id="differences-1x-2-real-reload"></a>
1384 In Nagios / Icinga 1.x a daemon reload does the following:
1386 * receive reload signal SIGHUP
1387 * stop all events (checks, notifications, etc.)
1388 * read the configuration from disk and validate all config objects in a single threaded fashion
1389 * validation NOT ok: stop the daemon (cannot restore old config state)
1390 * validation ok: start with new objects, dump status.dat / ido
1392 Unlike Icinga 1.x the Icinga 2 daemon reload does not block any event
1393 execution during config validation:
1395 * receive reload signal SIGHUP
1396 * fork a child process, start configuration validation in parallel work queues
1397 * parent process continues with old configuration objects and the event scheduling
1398 (doing checks, replicating cluster events, triggering alert notifications, etc.)
1399 * validation NOT ok: child process terminates, parent process continues with old configuration state
1400 (this is **essential** for the [cluster config synchronisation](06-distributed-monitoring.md#distributed-monitoring-top-down-config-sync))
1401 * validation ok: child process signals parent process to terminate and save its current state
1402 (all events until now) into the icinga2 state file
1403 * parent process shuts down writing icinga2.state file
1404 * child process waits for parent process gone, reads the icinga2 state file and synchronizes all historical and status data
1405 * child becomes the new session leader
1407 The DB IDO configuration dump and status/historical event updates use a queue
1408 not blocking event execution. Same goes for any other enabled feature.
1409 The configuration validation itself runs in parallel allowing fast verification checks.
1411 That way your monitoring does not stop during a configuration reload.
1414 ### State Retention <a id="differences-1x-2-state-retention"></a>
1416 Icinga 1.x uses the `retention.dat` file to save its state in order to be able
1417 to reload it after a restart. In Icinga 2 this file is called `icinga2.state`.
1419 The format is **not** compatible with Icinga 1.x.
1421 ### Logging <a id="differences-1x-2-logging"></a>
1423 Icinga 1.x supports syslog facilities and writes its own `icinga.log` log file
1424 and archives. These logs are used in Icinga 1.x to generate
1427 Icinga 2 compat library provides the CompatLogger object which writes the icinga.log and archive
1428 in Icinga 1.x format in order to stay compatible with addons.
1430 The native Icinga 2 logging facilities are split into three configuration objects: SyslogLogger,
1431 FileLogger, StreamLogger. Each of them has their own severity and target configuration.
1433 The Icinga 2 daemon log does not log any alerts but is considered an application log only.
1435 ### Broker Modules and Features <a id="differences-1x-2-broker-modules-features"></a>
1437 Icinga 1.x broker modules are incompatible with Icinga 2.
1439 In order to provide compatibility with Icinga 1.x the functionality of several
1440 popular broker modules was implemented for Icinga 2:
1444 * Cluster (allows for high availability and load balancing)
1447 ### Distributed Monitoring <a id="differences-1x-2-distributed-monitoring"></a>
1449 Icinga 1.x uses the native "obsess over host/service" method which requires the NSCA addon
1450 passing the slave's check results passively onto the master's external command pipe.
1451 While this method may be used for check load distribution, it does not provide any configuration
1452 distribution out-of-the-box. Furthermore comments, downtimes, and other stateful runtime data is
1453 not synced between the master and slave nodes. There are addons available solving the check
1454 and configuration distribution problems Icinga 1.x distributed monitoring currently suffers from.
1456 Icinga 2 implements a new built-in
1457 [distributed monitoring architecture](06-distributed-monitoring.md#distributed-monitoring-scenarios),
1458 including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
1459 High Availability and load balancing are also part of the Icinga 2 Cluster feature, next to local replay
1460 logs on connection loss ensuring that the event history is kept in sync.