Hi All,
I have issue use check http service in checkmk to monitor our company’s website which hosted on cloud. It’s getting below HTTP WARNING: HTTP/1.1 400 Bad Request warning. After troubleshooting, it’s found that that the request is blocked by the WAF on the cloud, it’s because the checkmk’s http request is different from the real Browser request so WAF block it. I have tried filled in the user agent field which I got it the from the website through Developemnt tool but it doesn’t fix the issue. So I’ve developed a python script to simulate the browser request. I have tested the script in the CheckMk Linux and it works fine , getting 200 status code, so it should be good to go. I’ve put the script under /usr/lib/check_mk_agent/local which should be correct. The issue is I have is how do I use the script in checkMk, what should I configure in the GUI or CLI to make the checkMK to use this script ? Please help . Many thanks.
Thanks for reply. It looks the guidelines you shared need to distribute the script to the target host( the one being monitoring) , right ? But my target host is a website hosted the cloud and it’s not managed by my team, so we can’t put the script to the target host. What we want is as following:
Write a python script and test in the CheckMK Linux
First of all you must make sure, that your local check, is executable, so
that you don’t have to write "python3 <SCRIPTNAME>" to actually run it,
otherwise the agent will not ever execute it as a “local” check.
Now to your undertaking: Spontaneously, I see at least two possibilities to get this “into monitoring”.
You could execute it as “local” check on any host (again: make sure it’s executable). You just have to document somewhere that “this service” shows the status of “the website”.
Another idea, is to implement the check with “piggyback” data, to assign
it to “another” host. The script would still be executed by a host
with an agent (e.g. the Checkmk server itself), but the service
will “appear” on the “other” host.
To do this, your output must be “extended” with piggyback
data, as described here Piggyback transport.
Let’s say, your “piggyback” data, returns <<<<MYWEBSITE>>>> as “host” (Check the example in the documentation above).
You could then:
Create a “dummy” host, with “no IP, no agent”, which will be called MYWEBSITE and will thus, always be OK.
Place your script in the “local” directory of any host, running the agent (e.g. the Checkmk server). Its results, will automagically “appear” on the host MYWEBSITE.
