Wrote Icinga 2 intro documentation.

doc/icinga2-intro.txt

@@ -0,0 +1,147 @@
+Icinga 2
+========
+
+Icinga 2 is a network monitoring application that tries to improve upon the
+success of Icinga 1.x while fixing some of its shortcomings. A few frequently
+encountered issues are:
+
+- Scalability problems in large monitoring setups
+- Difficult configuration with dozens of "magic" tweaks and several ways of
+  defining services
+- Code quality and the resulting inability to implement changes without
+  breaking add-ons
+- Limited access to the runtime state of Icinga (e.g. for querying a service's
+  state or for dynamically creating new services)
+
+Fixing these issues would involve major breaking changes to the Icinga 1.x core
+and configuration syntax. Icinga users would likely experience plenty of
+problems with the Icinga versions introducing these changes. Many of these
+changes would likely break add-ons which rely on the NEB API and other core
+internals.
+
+From a developer standpoint this may be justifiable in order to get to a better
+end-product. However, for (business) users spending time on getting familiar
+with these changes for each new version may become quite frustrating and may
+easily cause users to lose their confidence in Icinga.
+
+Nagios(TM) 4 is currently following this approach and it remains to be seen how
+this fares with its users.
+
+Instead the Icinga project will maintain two active development branches. One
+for Icinga 1.x which focuses on improving the existing Icinga 1.x code base -
+just like it has been done so far. Independent from Icinga 1.x development
+on Icinga 2 will happen in a separate branch.
+
+Code Quality
+------------
+
+Icinga 2 will not be using any code from the Icinga 1.x branch due to the
+rampant code quality issues with the existing code base. However, an important
+property of the Icinga development process has always been to rely on proven
+technologies and Icinga 2 will be no exception.
+
+A lot of effort has gone into designing a maintainable architecture for Icinga
+2 and making sure that algorithmic choices are in alignment with our
+scalability goals for Icinga 2.
+
+There are plans to implement unit tests for most Icinga 2 features in order to
+make sure that changes to the code base do not break things that were known
+to work before.
+
+Language Choice
+---------------
+
+Icinga 1.x is written in C and while in general C has quite a number of
+advantages (e.g. performance and relatively easy portability to other *NIX-
+based platforms) some of its disadvantages show in the context of a project
+that is as large as Icinga.
+
+With a complex software project like Icinga an object-oriented design helps
+tremendously with keeping things modular and making changes to the existing
+code easier.
+
+While it is true that you can write object-oriented software in C (the Linux
+kernel is one of the best examples of how to do that) a truly object-oriented
+language makes the programmers' life just a little bit easier.
+
+For Icinga 2 we have chosen C++ as the main language. This decision was
+influenced by a number of criteria including performance, support on different
+platforms and general user acceptability.
+
+In general there is nothing wrong with other languages like Java, C# or Python;
+however - even when ignoring technical problems for just a moment - in a
+community as conservative as the monitoring community these languages seem out
+of place.
+
+Knowing that users will likely want to run Icinga 2 on older systems (which
+are still fully vendor-supported even for years to come) we will make every
+effort to ensure that Icinga 2 can be built and run on commonly used operating
+systems and refrain from using new and exotic features like C++11.
+
+Configuration
+-------------
+
+Icinga 1.x has a configuration format that is fully backwards-compatible to the
+Nagios(TM) configurationi format. This has the advantage of allowing users to
+easily upgrade their existing Nagios(TM) installations as well as downgrading
+if they choose to do so (even though this is generally not the case).
+
+The Nagios(TM) configuration format has evolved organically over time and
+for the most part it does what it's supposed to do. However this evolutionary
+process has brought with it a number of problems that make it difficult for
+new users to understand the full breadth of available options and ways of
+setting up their monitoring environment.
+
+Experience with other configuration formats like the one used by Puppet has
+shown that it is often better to have a single "right" way of doing things
+rather than having multiple ways like Nagios(TM) does (e.g. defining
+host/service dependencies and parent/child relationships for hosts).
+
+Icinga 2 tries to fix those issues by introducing a new configuration format
+that is heavily based on templates and supports user-friendly features like
+freeform macros.
+
+External Interfaces
+-------------------
+
+While Icinga 1.x has easily accessible interfaces to its internal state (e.g.
+status.dat, objects.cache and the command pipe) there is no standards-based
+way of getting that information.
+
+For example, using Icinga's status information in a custom script generally
+involves writing a parser for the status.dat format and there are literally
+dozens of Icinga-specific status.dat parsers out there.
+
+While Icinga 2 will support these legacy interfaces in order to make migration
+easier and allowing users to use the existing CGIs and whatever other scripts
+they may have Icinga 2 will focus on providing a unified interface to Icinga's
+state. The exact details for such an interface are yet to be determined but
+this will likely be an RPC interface based on one of the commonly used
+web-based remoting technologies.
+
+Icinga 2 will also feature dynamic reconfiguration which means users can
+create, delete and update any configuration object (e.g. hosts and services)
+on-the-fly.
+
+Scalability
+-----------
+
+Icinga 1.x has some serious scalability issues which explains why there are
+several add-ons which try to improve the core's check performance. One of
+these add-ons is mod_gearman which can be used to distribute checks to
+multiple workers running on remote systems.
+
+A problem that remains is the performance of the core when processing check
+results. Scaling Icinga 1.x beyond 25.000 services proves to be a challenging
+problem and usually involves setting up a cascade of Icinga 1.x instances and
+dividing the service checks between those instances. This significantly
+increases the maintenance overhead when updating the configuration for such a
+setup.
+
+Icinga 2 natively supports setting up multiple Icinga 2 instances in a cluster
+to distribute work between those instances. This is not limited to service
+checks but may also be used for other tasks such as writing the history
+database, doing notifications, etc.
+
+In order to support using Icinga 2 in a partially trusted environment SSL is
+used for all network communication between individual instances.