1. The monitoring core
The monitoring core is at the heart of the Check_MK-System. Its tasks are:
- the regular querying of checks and the collection of their results.
- providing current states to the GUI
- the recognition of changes to states and the notifications generated from these.
1.1. Nagios and Icinga
Alternatively, the core from Icinga can also be utilised. This is particularly popular in Germany, and is based on the same program code, but in recent years it has been developed independently.
Even though Nagios and Icinga perform exceptionally - being flexible, fast and well-proven - there are still situations in which their limits are reached. Where a large number of hosts and services are being monitored, three problems in particular become evident:
- The high CPU consumption when executing checks
- The long restart time when changing a configuration
- The fact that the system is not available during such a restart
2. The Check_MK micro core
Since Check_MK is being used in ever-larger environments, and in order to overcome
the limitations of Nagios as described above, in 2013 we commenced a new development of
our own core specifically for the
|High efficiency when executing checks||This applies for active checks as well as Check_MK-based checks. In benchmarking, a desktop-PC (Core i7) achieved more than 600,000 checks per minute.|
|Rapid activation of changes||A configuration with 20,000 hosts and 600,000 services can be loaded in 0,5 seconds.|
|Configuration changes during live operations||Currently-running checks and live status connections are not interrupted. The procedure is undetectable to monitoring users.|
|Rapid availability queries||Through the use of special caches, availability analyses - even over long time periods - can be calculated without a noticeable waiting time.|
|Additional features||The CMC makes use of numerous additional features, such as, e.g., recurring planned-downtimes and acknowledgements with automatic expiry times.|
Other elements have also been optimised. For example, performance data is passed without detours directly from the core to the RRD cache, notifications are created in a "KeepAlive"-mode, and host checks are executed by a built-in ICMP helper. All of these reduce costly process-creations and save CPU resources.
These characteristics bring numerous advantages - even in smaller installations:
- The low CPU consumption enables virtualisation to subsitute for hardware in many cases.
- The shock-free activation of changes allows frequent configuration changes.
- Demands such as cloud-monitoring can thus be satisfied, since servers can be added and removed in quick succession.
The graphic below shows the CPU consumption for a Check_MK server before and after changing from Nagios to the CMC. This graphic has been kindly provided by Munich Airport, which monitors 730 hosts and 18,000 services with this server.
Another project shows similar results. The following graphs show a restructuring of Nagios as the core on the CMC in an environment with 56,602 services on 2,230 monitored hosts on a virtual machine with two cores:
The magnitude of the difference in an individual case naturally depends on many factors. In the above case a smaller instance that was not restructured runs on the same server. Without this the difference in consumption would be even more noticeable.
Further articles on the CMC:
- Migration to the CMCRestructuring Nagios/Icinga on the CMC
- Special characteristics of the CMCHow the CMC differs from Nagios/Icinga
- CMC's files and directoriesWhat lies where? Logdata, configuration, etc.
3. Frequently Asked Questions (FAQs)
3.1. Can the CMC also run normal Nagios Plug-ins?
3.2. Will Check_MK continue to support Nagios?
3.3. Can I switch between Nagios and CMC?
Switching between the two cores is simple, as long as your configuration has been created cleanly
with WATO. Details on this can be found in the Migration to the CMC article.
By default the
3.4. Is the CMC freely available?
The CMC is only available as a component of the