Centreon Engine offers a mature alternative to Nagios. Centreon Engine is a monitoring engine more powerfull than Nagios. More advandes in terms of functionnality and more resource-efficient, it can better integrate into existing systems (cloud, virtualization, light boxes).

Centreon development teams gave life to Centreon Engine engine using version 3.2.3 Nagios as a starting point. Their goal is to improve performance and motivate the community with new challenges.

Today, all external stakeholders are invited to join us to work with our team on larger improvements. For 2 years, we have made sure to meet user demands for technical improvements (performance enhancements, connectors, building code sources, unit testing) and functional (simplified configuration, polling for the second, recurring downtimes , timezones management, correlation, …).

What is the difference between Nagios and Centreon Engine ?

With Centreon Engine, the Centreon developers want to demonstrate to the community that the Nagios core engine can be improved through the partial rewriting code and integration of corresponding patches to new user requirements.

Since the birth of Centreon Engine, many features have been added to the supervision of the heart:

  • Connector: specialized collection daemon (performance improvement)
  • Hot reload configuration
  • Reducing resource consumption (CPU & Disk IO) for better integration in cloud environment

Since version 4 of Nagios, Centreon Engine is no longer compatible with Nagios since there is no compatibility between Nagios 3 and Nagios 4. From this premise, the Centreon teams have decided to accelerate the development Centreon Engine by no longer focusing on backward compatibility. New features will be integrate very soon in version 2 of Centreon Engine.

You find other practical information on the documentation site.

Do not hesitate to contact us if you have any questions about this project.

What he planned in future releases?

With the arrival of Centreon 3, the Centreon team have more freedom and will now be able to satisfy their need of rupture. The next features are:

  • Management timezones
  • Management of recurring downtimes
  • Management of the polling interval with a lower per minute (5 seconds minimum)
  • Integration of a timeout check each resource
  • Centralization of the notification at the broker

If you have innovative ideas that are not included in this list, please let us know through our forge.