HTTP 204 returned from /ping endpoint is unsuitable for Google Kubernetes Cloud healthcheck

[noodle-rubrik]

Feature Request

The "/ping" endpoint of influxdb_listener should have an option to return HTTP status code 200

Proposal:

Google Cloud does not allow you to configure the behavior of its health checks, other than the endpoint, it requires a 200 response. This means that the "/ping" endpoint, which seems intended for this sort of use case, can't be used on this cloud provider. The return code should be changed to 200, either by default, or by adding a param to the endpoint, as suggested in a similar issue for influxdb itself.
[1] influxdata/influxdb#9772

Current behavior:

Calling the "/ping" endpoint returns 204. Using "/ping" as your Google HTTP(s) Load Balancer backend's health check fails in a (to me) surprising way. As a workaround, "/query" can be used to return the correct status code, but this is more obtuse, and the behavior of an empty query might change in the future, or consume more resources than a simple ping.

Desired behavior:

If "/ping" can't be configured to return 200 by default, then configuring "/ping?statusCode=200" as the health check should return 200, as proposed in the linked influxdb issue. If that proposal is not accepted, then both implementations of "/ping" should have the same API to request a different status code, so that influxdb_listener is as similar to influxdb as possible.

Use case: [Why is this important (helps with prioritizing requests)]

We are deploying telegraf to GCP as a proxy to forward traffic from a second telegraf instance to influxdb. The influxdb_listener plugin is definitely the right tool for this use case, and we can put this telegraf instance behind an endpoint of our load balancer, as long as we have a health check that returns 200 OK.

[noodle-rubrik]

Maybe this should be a separate issue, but I also am running into problems when trying to use the basic authentication options, since there's no option to send those with Google's healthchecks. I don't think that /ping needs to be protected by this authentication, does it? Removing the call to AuthenticateIfSet for /ping would also help when running telegraf influxdb_listener on GKE.

This one has a better workaround though, by adding a second [[inputs.influxdb_listener]] without authentication, only accessible internally.

[glinton]

I'm surprised you can't configure the GCP Load balancers to see a 204 as "up". I personally think you are right, that the /ping endpoint doesn't need to be behind authentication, but if that's the case, we should strip out any server identification from the response.

[danielnelson]

Since this is the influxdb_listener, we should mirror whatever InfluxDB does for compatibility. I'm not sure, but I would assume that means /ping is subject to authentication.

https://github.com/influxdata/influxdb/blob/v1.6.4/services/httpd/handler.go#L809

[glinton]

It looks like /ping isn't behind authentication in influxdb v1.6.4, but I agree that influxdb_listener should mirror influx's api. if it changes to allow a different response code, let us know so we can make that change here too

[danielnelson]

Here is what will be, I assume, in 1.7:
https://github.com/influxdata/influxdb/blob/2f49e00f7f3801a506304c3b6d8165b2f4039f3d/services/httpd/handler.go#L851-L862

Looks like the return code is switched if the verbose flag is set, we can add this once it goes into release candidates.

[tanuj83]

which version this fix would be available?