Error responses not passed through about exporter_exporter

[candlerb]

Hmm, maybe this is a bad example. The fact that both exporter_exporter and snmp_exporter use a module query-string argument is confusing.

EDIT: raised separately as #23

[candlerb]

The point about error responses still stands. You can demonstrate it by missing a mandatory query string arg on snmp_exporter:

# curl -v localhost:9999/proxy?module=snmp
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9999 (#0)
> GET /proxy?module=snmp HTTP/1.1
> Host: localhost:9999
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Sat, 19 Oct 2019 09:41:44 GMT
< Content-Length: 103
<
An error has occurred while serving metrics:

text format parsing error in line 1: invalid metric name
* Connection #0 to host localhost left intact

In this case, tcpdump shows that the response from snmp_exporter was:

HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Sat, 19 Oct 2019 09:43:05 GMT
Content-Length: 37

'target' parameter must be specified

[tcolgate]

Thanks for the report. We should be able to handle this better.

[tcolgate]

I've added support for reporting an error. Unfortunately, some of the internals mean that we cannot simply reforwarded all errors. As it stands, we should now at least report there is an error and not just report a parsing failure. Hopefully this helps a bit.

[candlerb]

Great, thanks for that.

[candlerb]

Aside: since at that point resp.Body has not been touched, presumably it would be possible to read (say) the first 1024 bytes and include it in the error message?

[tcolgate]

The problem is that it's promhttp.handler that calls the gatherer, so it's that that passes back the response. I could put a chunk of the Body in the error I give back to the promhttp handler, but that would be even uglier output than what we currently do.