[receiver/httpcheck] add metrics check whether substring contains in response body

[sakulali]

Description:
Part of #24913, add metrics check if substring contains in http check response body or not. When set body option and emit httpcheck.body, testing substring contains or not in the response of HTTP Check.

Link to tracking Issue:
#24913

Testing:
make generate
make chlog-validate
go test for httpcheckreceiver

Documentation:
receiver/httpcheckreceiver/README.md

[sakulali]

Thanks for careful reviews. I really appreciate it @atoulme!

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[sakulali]

Could this PR hold on?

[lpegoraro]

Hi @sakulali, if you need help with this, let me know, I can work with you, since this is aligned with what I need for the receiver.

[sakulali]

Hi @sakulali, if you need help with this, let me know, I can work with you, since this is aligned with what I need for the receiver.

Sorry for delay reply @lpegoraro. Could you please help review the code? I'm unsure if my implementation aligns with your issue, and I would also like to collaborate in completing this valuable feature you've proposed.

[sakulali]

Hello @atoulme, cloud you mind help reviews again? I want to work with @lpegoraro to implement the feature, thanks!

[atoulme]

Some English and a couple touches, but it's not far.

[sakulali]

Some English and a couple touches, but it's not far.

Thanks very much for taking the time to reviews @atoulme!

[lpegoraro]

I also think we are very close!
I only have a suggestion about the encoding of the string of the check, if we either get the encoding from the configuration of the target, or do we fetch it from the Header, which I believe is safer, what do you guys think?

[sakulali]

if we either get the encoding from the configuration of the target, or do we fetch it from the Header

Great suggestion! I think it's a good idea to create a separate issue to follow up. I'm not very familiar with encoding best practices either, i think we can retrieve the encoding format from a custom field in the HTTP header, such as X-Encoding: my-custom-encoding, or through URL parameters. We can then use the configuration file to select the appropriate decoding method for processing?

[lpegoraro]

hi there folks, what is the hold up? can we do something about it?

[sakulali]

hi there folks, what is the hold up? can we do something about it?

Thanks for reminder. Could you mind help to reviews again? @codeboten

[lpegoraro]

Hi there! Great work on getting 2 approvals, can we merge this for the next release?

[lpegoraro]

Hi there fellas, @codeboten @atoulme , would this be in the next release?

[codeboten]

Sorry for the delay @lpegoraro, I would like to resolve #27015 (comment) before merging this

[lpegoraro]

Count me in for anything @codeboten

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[tusharbhasme]

This could carry a different meaning when method is POST where the body content will be sent as part of the request.

[AwsmAshraf]

Any one working on this? I actually have a requirement for this. Can we do it in a way in which we can specify the status code to be expected? I actually agree with @andrzej-stencel on this. A single data point would be great, with any additional info in the form of attributes. Also, modifying the name of the metric to something other than httpcheck.status would make identifying the result of multiple http checks a lot easier. What I'm trying to say is different http endpoint checks would be populated as different metrics with the name of the metric specified for that endpoint when configuring this receiver.