Add HTTP health check #520
Conversation
Load balancers and service discovery mechanisms sometimes provide an HTTP health check feature. We can auto-detect such an HTTP request being made to the Thrift port and return a good enough response to pass the health check. For convenience we can also print a little debugging information, so that if you curl a port you can see what service is running there.
|
Is that a standard thing that Thrift servers provide? I don't think I've seen this before. |
|
Yeah it's not standard, though neither is SSL auto-detection as far as I know. An alternative would be to run a separate health check listener on a different port. It wouldn't be equivalent though, because the thrift listener might be having problems (like not accepting connections fast enough) while the health check listener stays up. Another alternative would be to provide a TCP health check, for instance by echoing bytes, but it doesn't seem more standard, and a little less handy in terms of being able to curl a port. A third alternative would be to just rely on the proxy checking if a TCP connection can be opened on the thrift port. No extra functionality to add here, but again it's not quite as good a health check, and a little less handy. |
|
My opinion is that this functionality should be provided by the application. It's in the best position to know the most useful kind of health response (content-wise) to return over which port(s)/protocol(s). |
Load balancers and service discovery mechanisms sometimes provide an HTTP
health check feature. We can auto-detect such an HTTP request being made to the
Thrift port and return a good enough response to pass the health check.
For convenience we can also print a little debugging information, so that if
you curl a port you can see what service is running there.