Website monitoring has always been an essential part of IT monitoring, and today it is much more complex than in the early years of the Internet. Twenty years ago, a simple ping was often enough to check whether a site was online or not. Today, aspects such as load balancers, encrypted transport paths, and different HTTP versions play a role.

For more than 20 years, monitoring systems have relied on the check_http tool that originated in the Nagios universe. However, this reliable little helper is now showing its age. With check_httpv2 [1], Checkmk now offers a new open source implementation for modern IT environments (see the "About Checkmk" box).

In this article, I show you how to monitor modern websites in detail, including all details of encryption, authentication, complex connection setups, dependencies on proxy servers, and so on. All of this is possible in three different ways: with Checkmk itself, with any Nagios-compatible system, or with the self-compiled check as a standalone tool. Additionally, check_cert [2] is a specialist for checking certificates beyond their mere validity; for example, the issuer of a certificate and the components of crypto suites can also be monitored.

To begin, I'll take a quick look at the history and Checkmk's approach to the new HTTP check.

A New HTTP Check

The http_check Nagios plugin is still in use today, despite being more than 25 years old. Like so many standard tools, especially in the Linux environment, it dates back to the late 1990s. Until recently, Checkmk also left the monitoring of availability, status codes, and certificates to this little heavyweight.

However, it should be noted that the tool has been expanded and patched by changing developers over the years and no longer meets all modern requirements. Want an example? Two separate calls are required to check the certificate lifetime and HTTP status codes. This method is no longer appropriate in this day and age. Additionally, a bunch of expected functionality is simply missing.

The check_http plugin is now maintained in two slightly different versions by Monitoring Plugins [3] and Nagios Plugins [4]; Checkmk developers use the Monitoring Plugins version and quickly rejected the possibility of modernizing the existing check with pull requests. The maintainers would have been burdened with a lot of effort, and additional dependencies and compatibility requirements would have caused problems with the portability of the monitoring plugins.

Therefore, Checkmk decided on a completely new implementation in-house. The programming language of choice was Rust because of relevant experience within the Checkmk development teams; Python couldn't keep up in terms of performance, and maintainability is better than with C/C++. These considerations led to the creation of check_httpv2 and, for more detailed certificate monitoring, the completely new tool check_cert.

Working with check_httpv2

If you are not working with Checkmk or another monitoring system with check_httpv2 implemented, you can easily compile the tool yourself and use it in the terminal or in scripts. All the necessary commands can be found ready to copy and paste in Listing 1, which has been tested in a freshly installed Ubuntu 24.04. The dependencies are important (the Rust package manager Cargo, the TLS/SSL implementation of OpenSSL, and Git, with pkg-config to simplify the compilation process), as are the required files from the Checkmk repository. In the listing, you can see the variant for the compilation of check_httpv2; the check for certificates can be built in exactly the same way: You just have to replace checkmk/packages/site/check-http with checkmk/packages/site/check-cert.

sudo apt install cargo libssl-dev pkg-config git
cd ~/git
git clone https://github.com/Checkmk/checkmk.git
cd checkmk/packages/site/check-http/
cargo check --release
cargo build --release
cd ../target/release/

A First Check

I'll take a look at a simple check in practice, first with Checkmk and then in solo mode. You can find the corresponding rule in Checkmk under Setup | Services | HTTP, TCP, email … ; then, click Networking | Check HTTP web service . Don't confuse this option with the old check (check_http), which is still available under Check HTTP service (deprecated) .

In the simplest version, it is sufficient to enter a name and the URL of the website to be monitored (Figure 1). After activating the rule, you will find a service with the selected name and the standard prefix HTTPS in the monitoring (e.g., HTTPS Webserver Checkmk ; Figure 2).

Figure 1: The simplest way of invocation is passing the website's URL.

Figure 2: Results of an HTTP check in the Checkmk GUI.

In addition to the status, you will see another interesting aspect on the service details page if you scroll all the way down: The Service check command line contains the specific call to the plugin along with the parameters, and you can use these directly on the command line in standalone mode (Figure 3), which is a nice simplification for testing purposes.

Figure 3: Command-line options of the check in Checkmk.

Note that self-compiled binaries are named check-cert and check-http. In Nagios-compatible systems (which Checkmk is), the convention is to use underscores. Thus, in Checkmk the binaries are installed as check_cert and check_httpv2 to allow for coexistence with the old check_http.

If you want to run exactly this check with the self-compiled check_httpv2 in the terminal, the command is:

./check_httpv2 --url https://www.checkmk.com

Of course, the tool also provides detailed help on the command line, so that even more complex queries can be made relatively easily. An example with the check response is shown in Figure 4.

Figure 4: The HTTP check in standalone mode with TLS, certificate, and string options.

Up to this point, the check provides information about whether the page is accessible, which protocol is used, whether a redirect has taken place, and which status code it returns. However, for a real browser to display the page, one more value must be checked – the validity of the certificate:

./check_httpv2 --url https://www.checkmk.com --certificate-levels 40,20

The certificate-levels option at the command line (Certificate validity in Checkmk; Figure 5), sets two values for the remaining validity period of the certificate: From 40 days remaining, the status WARN is returned, and for 20 days remaining, CRIT.

Figure 5: The check_httpv2 plugin checks the certificate lifetime.

Validity is all well and good, but it is not sufficient in every situation. What if a machine-in-the-middle attack occurs and a valid certificate exists, but it is issued from a different authority than usual? What if it is not enough to insist on TLS 1.3, but a standard requires certain encryption algorithms?

This scenario is where check_cert comes into play.