Document updated on May 2, 2021
If you place a balancer in front of KrakenD, such as an ELB, you can check KrakenD health using a TCP port check. If, on the other hand, you need an HTTP endpoint in systems like Kubernetes, use the internal endpoint /__health
.
/__health
endpointThe health endpoint, or the ping endpoint, works without any specific configuration as KrakenD automatically adds it.
For instance, see the simplest possible krakend.json
:
$cat krakend.json
{ "version: 2 }
Start this server and query the /__health
endpoint. You’ll have a 200
response code from KrakenD with the following content:
$curl http://localhost:8080/__health
{"status":"OK"}
If, for any reason, you don’t want to use the /__health
endpoint and its content and want to have your custom response, the simplest solution is to use stub data to alter the response.
A custom health configuration could look like this:
{
"version": 2,
"port": 8080,
"endpoints": [
{
"endpoint": "/health",
"extra_config": {
"github.com/devopsfaith/krakend/proxy": {
"static": {
"data": {
"custom": "response",
"foo": "bar"
},
"strategy": "always"
}
}
},
"backend": [
{
"url_pattern": "/__health",
"host": [
"http://localhost:8080"
]
}
]
}
]
}
In this configuration, KrakenD connects to itself, but instead of returning the content of the internal health endpoint, it sets the data
defined in the static structure. Notice that the listening port
in the configuration and the host
match your deployed KrakenD.
The response content of this custom /health
endpoint is:
$curl http://localhost:8080/health
{"custom": "response","foo": "bar"}
The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.