tyler.durden
/
icinga2
mirror of https://github.com/Icinga/icinga2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated intro text.

This commit is contained in:
Gunnar Beutner 2012-09-07 09:54:14 +02:00
parent e3d95a4181
commit 55355b19c6
1 changed files with 121 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
doc/icinga2-intro.txt
View File

@ -27,10 +27,14 @@ easily cause users to lose their confidence in Icinga.
Nagios(TM) 4 is currently following this approach and it remains to be seen how Nagios(TM) 4 is currently following this approach and it remains to be seen how
this fares with its users. this fares with its users.
Instead the Icinga project will maintain two active development branches. One Instead the Icinga project will maintain two active development branches. There
for Icinga 1.x which focuses on improving the existing Icinga 1.x code base - will be one branch for Icinga 1.x which focuses on improving the existing
just like it has been done so far. Independent from Icinga 1.x development Icinga 1.x code base - just like it has been done so far.
on Icinga 2 will happen in a separate branch.
Independently from Icinga 1.x development on Icinga 2 will happen in a separate
branch and some of the long-term design goals will be outlined in this
document. Status updates for Icinga 2 will be posted on the project website
(www.icinga.org) as they become available.
Code Quality Code Quality
------------ ------------
@ -78,6 +82,11 @@ 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 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. systems and refrain from using new and exotic features like C++11.
Unlike Icinga 1.x there will be Windows support for Icinga 2. Some of the
compatibility features (e.g. the command pipe) which rely on *NIX features
may not be supported on Windows but all new features will be designed in such
a way as to support *NIX as well as Windows.
Configuration Configuration
------------- -------------
@ -97,9 +106,9 @@ 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 rather than having multiple ways like Nagios(TM) does (e.g. defining
host/service dependencies and parent/child relationships for hosts). host/service dependencies and parent/child relationships for hosts).
Icinga 2 tries to fix those issues by introducing a new configuration format Icinga 2 tries to fix those issues by introducing a new object-based
that is heavily based on templates and supports user-friendly features like configuration format that is heavily based on templates and supports
freeform macros. user-friendly features like freely definable macros.
External Interfaces External Interfaces
------------------- -------------------
@ -115,13 +124,53 @@ dozens of Icinga-specific status.dat parsers out there.
While Icinga 2 will support these legacy interfaces in order to make migration 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 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 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 state and providing similar functionality to that provided by the command pipe
this will likely be an RPC interface based on one of the commonly used in Icinga 1.x. 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. web-based remoting technologies.
Icinga 2 will also feature dynamic reconfiguration which means users can Icinga 1.x exports historical data using the IDO database interface (Icinga
create, delete and update any configuration object (e.g. hosts and services) Data Output). Icinga 2 will support IDO in a backwards-compatible fashion in
on-the-fly. order to support icinga-web. Additionally there will be a newly-designed
backend for historical data which can be queried using the built-in API when
available. Effort will be put into making this new data source more efficient
for use with SLA reporting.
Icinga 2 will also feature dynamic reconfiguration using the API which means
users can create, delete and update any configuration object (e.g. hosts and
services) on-the-fly. Based on the API there are plans to implement a
command-line configuration tool similar to what Pacemaker has with "crm". Later
on this API may also be used to implement auto-discovery for new services.
The RPC interface may also be used to receive events in real-time, e.g. when
service checks are being executed or when a service's state changes. Some
possible uses of this interface would be to export performance data for
services (RRD, graphite, etc.) or general log information (logstash, graylog2,
etc.).
Checks
-------
In Icinga 2 services are the only checkable objects. Hosts only have a
calculated state and no check are ever run for them.
In order to maintain compatibility with the hundreds of existing check plugins
for Icinga 1.x there will be support for Nagios(TM)-style checks. The check
interface however will be modular so that support for other kinds of checks
can be implemented later on (e.g. built-in checks for commonly used services
like PING, HTTP, etc. in order to avoid spawning a process for each check).
Based on the availability of remote Icinga 2 instances the core can delegate
execution of service checks to them in order to support large-scale distributed
setups with a minimal amount of maintenance. Services can be assigned to
specific check instances using configuration settings.
Notifications
-------------
Event handlers and notifications will be supported similar to Icinga 1.x.
Thanks to the dynamic configuration it is possible to easily adjust the
notification settings at runtime (e.g. in order to implement on-call rotation).
Scalability Scalability
----------- -----------
@ -139,9 +188,65 @@ increases the maintenance overhead when updating the configuration for such a
setup. setup.
Icinga 2 natively supports setting up multiple Icinga 2 instances in a cluster 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 to distribute work between those instances. Independent tasks (e.g. performing
checks but may also be used for other tasks such as writing the history service checks, sending notifications, updating the history database, etc.) are
database, doing notifications, etc. implemented as components which can be loaded for each instance. Configuration
as well as program state is automatically replicated between instances.
In order to support using Icinga 2 in a partially trusted environment SSL is In order to support using Icinga 2 in a partially trusted environment SSL is
used for all network communication between individual instances. used for all network communication between individual instances. Objects (like
hosts and services) can be grouped into security domains for which permissions
can be specified on a per-instance basis (so e.g. you can have a separate API
or checker instance for a specific domain).
Agent-based Checks
------------------
Traditionally most service checks have been performed actively, meaning that
check plugins are executed on the same server that is also running Icinga.
This works great for checking most network-based services, e.g. PING and HTTP.
However, there are a number of services which cannot be checked remotely either
because they are not network-based or because firewall settings or network
policies ("no unencrypted traffic") disallow accessing these services from the
network where Icinga is running.
To solve this problem two add-ons have emerged, namely NRPE and NSCA. NRPE
can be thought of as a light-weight remote shell which allows the execution
of a restricted set of commands while supporting some Nagios(TM)-specific
concepts like command timeouts. However unlike with the design of commonly used
protocols like SSH security in NRPE is merely an afterthought.
In most monitoring setups all NRPE agents share the same secret key which is
embedded into the NRPE binary at compile time. This means that users can
extract this secret key from their NRPE agent binary and use it to query
sensitive monitoring information from other systems running the same NRPE
binary. NSCA has similar problems.
Based on Icinga 2's code for check execution there will be an agent which can
be used on *NIX as well as on Windows platforms. The agent will be using the
same configuration format like Icinga 2 itself and will support SSL and
IPv4/IPv6 to communicate with Icinga 2.
Business Processes
-------------
In most cases users don't care about the availability of individual services
but rather the aggregated state of multiple related services. For example one
might have a database cluster that is used for a web shop. For an end-user the
shop is available as long as at least one of the database servers is working.
Icinga 1.x does not have any support for business processes out of the box.
There are several add-ons which implement business process support for Icinga,
however none of those are well-integrated into Icinga.
Icinga 2 will have native support for business processes which are built right
into the core and can be configured in a similar manner to Nagios(TM)-style
checks. Users can define their own services based on business rules which can
be used as dependencies for other hosts or services.
Logging
-------
Icinga 2 supports file-based logged as well as syslog (on *NIX) and event log
(on Windows). Additionally Icinga 2 supports remote logging to a central Icinga
2 instance.