As a devops I want a standardized application health check url
Create a health endpoint that can provide the status of the application. Suggest we follow this draft ietf draft recommendation
THIS HAS BEEN EDITED TO MATCH THE IMPLEMENTED SOLUTION
All is OK
service(s) in WARN state
Partially working service here
services(s) in ERROR state
Look for service on another node
Node not available, try again later
Node not available, try another node
Node not running, try another node
columns refer to JSON response. Examples JSON repsonses:
HTTP Status: 200
HTTP Status: 200
HTTP Status: 503
You can choose what range your ingest load balancer excepts as OK, eg 200 to 206
After some (inconclusive) discussion here https://github.com/inadarei/rfc-healthcheck/issues/57 I've decided to simplify the http return code to 200 pass|warn and 503 fail and let the json response provide the details
I've brought up the issue that the spec is not clear how the health status relates to the http status codes. ie 1:1, 1:n. It has got distracted by the use of 300 codes but I'm hoping to get some kind of clarity.
@James I strongly dislike making status codes configurable. External systems will assume different configurations making it difficult to use them in combination.
@lars, unless you define your own meaning to unused status code, yes they are always going to have twisted meaning. 404 NOT FOUND is again not quite true as the node is there but it unavailable. I wonder if it's worth making this configurable as everyone has a different opinion on the code numbers.
Instead, can I ask you all to consider whether have multiple responses per status (pass, warn, fail) is 1) sensible, 2) useful 3) conformant to the draft or should there just be three?