Optionally ignore `202` response codes

[jakelandis]

This output is used by X-Pack monitoring to send monitoring data to the ES monitoring bulk api. The monitoring bulk api endpoint (note this is different then the standard bulk api), can return a 202 HTTP status code if monitoring is not currently enabled in ES - X-Pack.

We currently treat a 202 as an error, but this error was getting masked by incorrect exception handling that is fixed with: #749

We should treat LS monitoring X-Pack enabled, but monitoring disabled in ES -X-Pack as a normal state, not an exceptional state. Specifically we should handle a 202 HTTP response code as a success and optionally log a debug message so that the traffic (if monitored) has a reasonable explanation.

Further, when we receive a 202 we should not try to upack the response for additional status codes (like we do for the normal bulk api responses).

Sending or not sending the monitoring data based on the ES X-Pack monitoring state is outside the scope of this issue.

[jsvd]

We currently treat a 202 as an error, but this error was getting masked by incorrect exception handling that is fixed with: #749

my thought here is to add a accept_http_codes => [200] option and for xpack we can use accept_http_codes => [200, 202]

Further, when we receive a 202 we should not try to upack the response for additional status codes (like we do for the normal bulk api responses).

what is the reason for this additional requirement?

[jsvd]

as a side note, libbeat currently has the same behaviour as this plugin, in that any non 200 response is considered an error

[andrewvc]

@jsvd I'm not sure if we get additional status codes in a 202. Since we're throwing away the data, I assumed me might have an empty body. I haven't checked though. Worth looking into.