Check_http2 Support

General
21

And the underlying problem is solved anyway in 2.3.0 with the new check_http_v2 from us

1 Like
22

Thanks for the feedback and I’m looking forward to test the new check_http_v2.

Regardless of this, there are also good reasons why to include check_curl:

  • check_curl already supports HTTP/2 since 2021 in contrast to check_http_v2, which will not be available before June 2024 and only for users of the 2.3 release

  • Behind check_curl is the full power of libcurl, which already supports HTTP/3 while we are still talking about HTTP/2, is under active development and is used by a very large community worldwide.

  • Including libcurl does not hurt anyone and should not be a big deal.

  • With the “Integrate Nagios plugins” rule set, customers have the freedom to use all available options of all plugins as they wish. This means they are independent of your roadmap and your discretion as to what is best for checkmk (example option -B for check_http)

  • We also distribute and use some of the monitoring plugins on our remote servers via mrpe and appreciate very much that you ship the latest version and that we don’t have to compile them ourselves every time.

  • With adding check_curl you can make many customers happy with minimal effort and without having to invest a lot of time and development ressources.

Just to add my two cents :wink:

4 Likes
23

Before it disappears, the arguments and facts from @LaSoe are valid.
Why put development effort into something that already exists? And is significantly more advanced?

@marcel.arentz and @martin.hirschvogel

2 Likes
24

The feedback on the new check_http and check_cert is so positive that we are convinced it was the right decision. It is a step change from what was possible before and using check_curl or any other community plug-in would have prevented this.
We strive to not bring mediocre results, but make the product significantly better - even if it means a major effort on our side.
Thus, try it for yourself and share with us if it works for you.

For us as a vendor, managing strategic dependencies is important. Monitoring web services (e.g. HTTP endpoints) is a key element of Checkmk. The ability to build new features, make improvements or fix something in short time is important - all of this is not possible with check_curl (as it was not with check_http). With our new check-http, we have the proper platform (with adequate testing) to do so. The speed at which we were able to implement feedback from the user testing in the last months has shown that it was indeed the right way.
Quick fixes might sound very appealing, but as a vendor, our responsibility is to think long-term. Quick fixes can very well turn into headaches and bring you into a one-way street one struggles to get out, and lead to only focusing on fixing things, thus not solving the underlying issue. We speak from experience…
New features become available after proper specification, dev and testing in new major releases - thus check_curl would have only been included in 2.3 as well. However, we have given users the power to fix things themselves in earlier Checkmk versions as already pointed out by you guys.

3 Likes