mirror of https://github.com/Icinga/icinga2.git
Michael Friedrich
parent
4525ce5040
commit
b393e8eb62
|
|
@ -32,13 +32,13 @@ Please get in touch with the Icinga team at [https://www.icinga.org/community/].
|
|||
You can follow Icinga 2's development closely by checking
|
||||
out these resources:
|
||||
|
||||
* Development Bug Tracker: [https://dev.icinga.org/projects/i2] ([http://www.icinga.org/faq/how-to-report-a-bug/])
|
||||
* Git Repositories: [https://git.icinga.org/?p=icinga2.git;a=summary] (mirror at [https://github.com/Icinga/icinga2])
|
||||
* Git Checkins Mailinglist: [https://lists.icinga.org/mailman/listinfo/icinga-checkins]
|
||||
* Development Mailinglist: [https://lists.icinga.org/mailman/listinfo/icinga-devel]
|
||||
* \#icinga-devel on irc.freenode.net [http://webchat.freenode.net/?channels=icinga-devel] including a Git Commit Bot
|
||||
* [Development Bug Tracker](https://dev.icinga.org/projects/i2): [How to report a bug?](http://www.icinga.org/faq/how-to-report-a-bug/)
|
||||
* Git Repositories: [main mirror on icinga.org](https://git.icinga.org/?p=icinga2.git;a=summary) [release mirror at github.com](https://github.com/Icinga/icinga2)
|
||||
* (Git Checkins Mailinglist](https://lists.icinga.org/mailman/listinfo/icinga-checkins)
|
||||
* [Development](https://lists.icinga.org/mailman/listinfo/icinga-devel) and [Users](https://lists.icinga.org/mailman/listinfo/icinga-users) Mailinglists
|
||||
* [#icinga-devel on irc.freenode.net](http://webchat.freenode.net/?channels=icinga-devel) including a Git Commit Bot
|
||||
|
||||
For general support questions, please refer to [https://www.icinga.org/support/].
|
||||
For general support questions, please refer to the [community support channels](https://support.icinga.org).
|
||||
|
||||
## <a id="demo-vm"></a> Demo VM
|
||||
|
||||
|
|
@ -52,7 +52,6 @@ Lots of things. Please read [Icinga 2 in a nutshell](#icinga2-in-a-nutshell).
|
|||
|
||||
#### Changes
|
||||
|
||||
|
||||
### Archive
|
||||
|
||||
Please check the `ChangeLog` file.
|
||||
|
|
@ -76,6 +75,11 @@ High Availability for DB IDO: Only active on the current zone master, failover h
|
|||
|
||||
Multithreaded and scalable for small embedded systems as well as large scale environments.
|
||||
Running checks every second is no longer a problem and enables real-time monitoring capabilities.
|
||||
Unlike Icinga 1.x the [daemon reload](#differences-1x-2-real-reload) happens asynchronously.
|
||||
A child daemon validates the new configuration, the parent process is still doing checks, replicating cluster events, triggering alert notifications, etc. If the configuration validation is ok, all remaining events are synchronized and the child process continues as normal.
|
||||
The DB IDO configuration dump and status/historical event updates also runs asynchronously in a queue not blocking the core anymore. The configuration validation itself runs in paralell allowing fast verification checks.
|
||||
That way you are not blind (anymore) during a configuration reload and benefit from a real scalable architecture.
|
||||
|
||||
|
||||
* Modular & flexible [features](#features)
|
||||
|
||||
|
|
|
|||
|
|
@ -1014,6 +1014,8 @@ safely reload the Icinga 2 daemon.
|
|||
> The `reload` action will send the `SIGHUP` signal to the Icinga 2 daemon
|
||||
> which will validate the configuration in a separate process and not stop
|
||||
> the other events like check execution, notifications, etc.
|
||||
>
|
||||
> Details can be found [here](#differences-1x-2-real-reload).
|
||||
|
||||
|
||||
## <a id="vagrant"></a> Vagrant Demo VM
|
||||
|
|
|
|||
|
|
@ -1398,6 +1398,36 @@ freshness is calculated from the `check_interval` attribute if set. There is no
|
|||
`freshness_threshold` attribute in Icinga 2. If the freshness checks are invalid, a new
|
||||
service check is forced.
|
||||
|
||||
### <a id="differences-1x-2-real-reload"></a> Real Reload
|
||||
|
||||
In Nagios / Icinga 1.x a daemon reload happens like so
|
||||
|
||||
* receive reload signal SIGHUP
|
||||
* stop all events (checks, notifications, etc)
|
||||
* read the configuration from disk and validate all config objects in a single threaded fashion
|
||||
* validation NOT ok: stop the daemon (cannot restore old config state)
|
||||
* validation ok: start with new objects, dump status.dat / ido
|
||||
|
||||
Unlike Icinga 1.x the Icinga 2 daemon reload happens asynchronously.
|
||||
|
||||
* receive reload signal SIGHUP
|
||||
* fork a child process, start configuration validation in parallel work queues
|
||||
* parent process continues with old configuration objects and the event scheduling
|
||||
(doing checks, replicating cluster events, triggering alert notifications, etc.)
|
||||
* validation NOT ok: child process terminates, parent process continues with old configuration state
|
||||
(this is ESSENTIAL for the [cluster config synchronisation](#cluster-zone-config-sync))
|
||||
* validation ok: child process signals parent process to terminate and save its current state
|
||||
(all events til now) into the icinga2 state file
|
||||
* parent process shuts down writing icinga2.state file
|
||||
* child process waits for parent process gone, reads the icinga2 state file and synchronizes all historical and status data
|
||||
* child becomes the new session leader
|
||||
|
||||
The DB IDO configuration dump and status/historical event updates also runs asynchronously in a queue not blocking the core anymore. Same goes for any other enabled feature running in its own thread.
|
||||
The configuration validation itself runs in paralell allowing fast verification checks.
|
||||
|
||||
That way you are not blind (anymore) during a configuration reload and benefit from a real scalable architecture.
|
||||
|
||||
|
||||
### <a id="differences-1x-2-state-retention"></a> State Retention
|
||||
|
||||
Icinga 1.x uses the `retention.dat` file to save its state in order to be able
|
||||
|
|
|
|||
Loading…
Reference in New Issue