search

logstash-plugins / logstash-filter-http

HTTP Filter Plugin for Logstash
Apache License 2.0
12 stars 29 forks source link

added option 'ignorable_codes' to also return failed REST calls #32

Open rpasche opened 3 years ago

rpasche commented 3 years ago

Setting this option to true will return the response headers and response body also for failed REST calls. This means, unless there is an exception, setting ignore_errors to true will always succeed.

The idea behind is to also be able to fetch the results for failed HTTP requests, parse them and - maybe - use that data within elasticsearch.

cla-checker-service[bot] commented 3 years ago

💚 CLA has been signed

MikeKemmerer commented 3 years ago

Any chance you can roll in the "form" change I made, too? They haven't been too quick on accepting pull requests for this plugin.

kares commented 3 years ago

Nice addition, however I think a better approach would be to make the 200-299 "valid" response codes configurable. Accepting intervals as well as individual response code (in an array), wdyt?

rpasche commented 3 years ago

Hmm... Yes. Need to think about it. So you mean that you need to give the codes of "valid" codes in an array of this option is set to true.

kares commented 3 years ago

I mean not having ignore_errors but having a valid_responses => ... option instead (anything else is an error). The idea would be to somehow support ranges => ['200-299', 302] as well as individual response codes => [200, 201, 204], given that LS does not support ranges this might need more work.

Not yet sure what the best approach would be to represent ranges, hopefully some other plugin is using smt similar already.

rpasche commented 3 years ago

@kares Found a bit time to further work on this. For now, I'm just doing exactly the same as the ignorable_codes (https://www.elastic.co/guide/en/logstash/current/plugins-outputs-http.html#plugins-outputs-http-ignorable_codes) within the logstash http output plugin. That should make it a bit more consistent.

rpasche commented 3 years ago

I am not able to run bundle exec spec anymore. I get some dependency error when I try this within my WSL. So hoping, that all tests pass...