1. The monitoring core
The monitoring core is at the heart of the Checkmk system. Its tasks are:
regularly initiating checks and the collecting their results,
providing the current states to the GUI,
detecting state changes and generating notifications from these.
The architecture diagram below shows the core and its connections to the primary components of the commercial editions:
1.1. Nagios and Icinga
The 
Checkmk Raw Edition is a construction based on the core from the well-established Nagios Open Source project.
This provides numerous useful functions and has been proven over many years by millions of users worldwide.
This inherent flexibility is one of the reasons for the success of Nagios.
Alternatively, the core from Icinga can also be utilized. 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, stable 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 load during execution of checks
The long restart time when changing a configuration
The fact that the system is not available during such a restart
2. The Checkmk Micro Core (CMC)
Since Checkmk 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 commercial editions.
The Checkmk Micro Core — or CMC — has not simply been created as a fork from Nagios, rather it has a complete code basis of its own.
The CMC utilizes a unique software architecture, and it has been perfectly-tailored for Checkmk.
Its primary advantages are:
High efficiency when executing checks - This applies for active checks as well as Checkmk-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 Livestatus 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 scheduled downtimes and acknowledgements with automatic expiry times.
Other elements have also been optimized. For example, performance data is passed without detours directly from the core to the RRD cache daemon, 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 lower demand for processing power enables virtualization to substitute for hardware in many cases.
The seamless activation of changes allows frequent configuration changes.
Demands such as Cloud monitoring, in which servers can be added and removed in quick succession, can thus be satisfied.
The two diagrams below show the CPU load and utilization for a Checkmk server before and after changing from Nagios to the CMC. These graphics have been kindly provided by the company DFi Service SA. At this point in time they were monitoring 1,205 hosts and 13,555 services on a server with 10 cores.
Another project shows similar results. The following graphs show a restructuring from a Nagios core to 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 site that had not been restructured runs on the same server. Without this the difference in CPU and disk load would be even more noticeable.
Further aspects of the CMC are explained in the following articles:
3. Frequently Asked Questions (FAQs)
3.1. Can the CMC also run normal Nagios Plug-ins?
The CMC can of course also run classic Nagios checks both actively and passively.
3.2. Will Checkmk continue to support Nagios?
Checkmk is and will remain compatible with Nagios, and will continue to fully-support the Nagios core. Likewise the commercial editions will continue to have Nagios as an optional core — but only to support a migration from the Raw Edition to the commercial editions.
3.3. Can I switch between Nagios and the CMC?
Switching between the two cores is easy as long as your configuration was created exclusively using the Setup menu in the Checkmk web interface. Details on this can be found in the Migration to the CMC article. By default the commercial editions create new sites with the CMC as their core.
3.4. Is the CMC freely-available?
The CMC is included as a component in the commercial editions, which are available via subscription. The Cloud Edition can be tested without obligation for a limited period of time and operated permanently on a small scale without licensing.