logstash icon indicating copy to clipboard operation
logstash copied to clipboard

Set HTTP status code based on status in health report API

Open henrikno opened this issue 9 months ago • 7 comments

The health report https://github.com/elastic/logstash/issues/16056 is a great addition. However load balancers typically can only hit HTTP(s) and check for their status code, and does not parse their body. They often send a HEAD request. So it's not possible to use it directly from a load balancer. E.g. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html

The way Elasticsearch solves it is by having a ?wait_for_status=green parameter. If the status isn't the expected one, it returns a 5xx status. https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html

henrikno avatar Mar 31 '25 16:03 henrikno

Thank you for the issue, and for providing the context for how Elasticsearch handles it with the extra flag. That is something we can likely mirror in a future iteration of the Logstash endpoint.

yaauie avatar Oct 13 '25 20:10 yaauie

Some notes so far: The documentation shows that unavailable and unknown are possible values for the health status in Elasticsearch. However, the ES server enum for ClusterHealthStatus shows only green, yellow, and red as valid values. I tracked this discrepancy down to this change, more specifically, this comment. With that said, the wait_for_status query parameter for the logstash health report should only support green, yellow, and red as values.

This is where the logic for executing the health request in the server code is.

estolfo avatar Oct 20 '25 14:10 estolfo

Question: The linked feature addition to Logstash is a health report. Elasticsearch also has a health report but the query param wait_for_status is for the health status endpoint, not the health report. So the question is, is this task to add a new endpoint to logstash that provides the health status and that supports the wait_for_status query param? The issue description requests the query param as an addition to the health report, but it doesn't seem to make sense there for a number of reasons.

estolfo avatar Oct 21 '25 14:10 estolfo

You're right that this isn't a 1:1 mapping between the requested functionality and the prior-art in Elasticsearch.

It looks like ES doesn't have an individual-node equivalent, and the meaning of a whole ES cluster being healthy is significantly different than the need here.

yaauie avatar Oct 21 '25 16:10 yaauie

Update: we'll add the wait_for_status query param to the root endpoint.

estolfo avatar Oct 27 '25 09:10 estolfo

The goal is to have an endpoint a Load balancer can hit to check if Logstash is healthy enough to service requests. If it's not healthy, it should return a 5xx status code on the endpoint so that it gets removed from the load balancer. It should only check the health of the instance. Could also be used as a readiness probe in k8s.

henrikno avatar Nov 12 '25 20:11 henrikno

Hi @henrikno, the implementation matches exactly what Elasticsearch does with the wait_for_status and timeout query params. Can you please review the description of the behavior in the PR and let me know if it satisfies the use case?

estolfo avatar Nov 25 '25 10:11 estolfo