Checking for Strings

The general expectation of check_httpv2 is that it behaves like a browser. After all, the aim is to check whether regular users (carbon-based forms of life) can actually visit the page. Even if this is the case, the content could still be missing (e.g., because of a defective CMS in the background).

The HTTP check can be used to check whether certain content appears in the header or body; both have options for fixed strings or regular expressions. This example ensures that either checkmk or check_mk appears somewhere in the HTML body of a password-protected page:

./check_httpv2 --auth-user peter --auth-pw-plain spiderman --body-regex '(?m)check(_)?mk'

However, such checks can be used for more than just monitoring the proper functioning of a page. How about monitoring the company's internal bulletin board for terms that could be relevant to the IT department (e.g., an alert when the word "restructuring" appears)? This feature definitely shows off its capabilities!

Bonus: Performance Tests with hyperfine

Invoking the HTTP check not only provides all kinds of information about the remote host and a status code for evaluation in monitoring, but also the response time, which, however, is not particularly meaningful for a single invocation, especially when load balancers, proxies, and the like do not always resolve to the same physical server.

The clever little tool hyperfine [5] is ideal for real performance tests, for example:

hyperfine --warmup 2 -r 20'./check_httpv2 --url https://checkmk.com'

In this case, hyperfine would first perform two warm-up runs that do not contribute to the result, which is sometimes helpful for caches. The HTTP check is then run 20 times; finally, a small report is output (Listing 2).

Time (mean ± sigma):       124.6 ms ±     9.8 ms      [User: 4.9 ms, System: 10.9 ms]
Range (min ... max):   108.3 ms ... 139.9 ms      20 runs

Summary and Outlook

Even in its first version, the new HTTP check can handle most situations (Table 1) and, together with the certificate check (Table 2), can check the availability, performance, and integrity of websites, solo or in Nagios-compatible platforms.

In Checkmk, command-line options are mapped almost 1:1 to configuration options in the GUI, but additional functions enable the monitoring of many pages, a few simplifications, and contextual help. Of course, various kinds of graphs nicely present various performance data (e.g., response time, time to fetch a header or content).

What's next for check_httpv2 and check_cert? Many ideas for extended functions and further performance data is on the wish list, but specifically, certificates behind proxies are on the agenda for now. Do you have your own ideas for features? You can submit and upvote feature requests on the Checkmk Idea Portal [6].