Set HTTP status code based on status in health report API
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
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.
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.
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.
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.
Update: we'll add the wait_for_status query param to the root endpoint.
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.
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?