Last update: Sep 27, 2018
200status when the backend returns a
2017/01/19 - 10:31:27 | 200 | 1.134431ms | ::1 | POST /users
By default, the gateway will always send an HTTP status 200 if the backend returns a 200 or a 201. You can inject your own HTTPStatusHandler implementation if you need a different behavior. Check this issue comment for more details.
500status when the backend returns anything but
2017/01/19 - 10:31:37 | 500 | 1.007191ms | ::1 | POST /users_ko
By default, the gateway will always send an HTTP status 500 if the backend returns any status above 400. You can inject your own HTTPStatusHandler implementation if you need a different behavior. Check this issue comment for more details.
503errors in the logs
2016/11/13 - 18:01:18 | 200 | 5.352143ms | ::1 | GET /frontpage 2016/11/13 - 18:01:18 | 503 | 5.662µs | ::1 | GET /frontpage 2016/11/13 - 18:01:18 | 503 | 5.662µs | ::1 | GET /frontpage
max_rate setting defines the maximum number of requests allowed in a single second to an endpoint or backend. When this number is reached, subsequent connections are rejected with a
503 error. This limitation is optional and is usually set to avoid hammering your own backends and compromising their stability.
max_rate number or disable it (
max_rate = 0). This setting can be set globally for all the endpoints,
or overridden individually per endpoint.
Remember: failing fast is always better than overloading your infrastructure and degrading the quality of your entire services.
The main reasons for having responses are:
timeoutvariable. This variable is usually written in a magnitude of milliseconds.
See the solutions below.
When there is a timeout you’ll see the
context deadline exceeded in the log, and it means only one thing: KrakenD couldn’t get the info on time (because of a network problem, or backend slowliness).
Error #01: context deadline exceeded
Whenever possible add caching layers in your backends, scale the infrastructure, etc. so backends answer on time. Increasing the
timeout variable should be always your last option. If your backends are not able to respond in a short time think that when you increment the timeout what you really do is to block connections waiting for the backend. The memory consumption will increase and the number of connections you can
open is finite. In a gateway, your focus should be freeing the connections as soon as possible.
2000ms are not recommended.
There are other times when KrakenD simply cannot reach the host due to a networking issue.
Make sure your backend sources return valid Json/Xml/… data. Try any online service to check the validity and format
of the returned content. If the response of your API is a collection, e.g: response comes inside brackets
, then make sure to mark the option
Treat the response as a collection, not an object. in the form.
The following names cannot be used as endpoint names as they are reserved:
/__debug /__stats /__health
If you think you have find a security problem, please report us the vulnerability
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.