How to find kong request to upstream by retry?

1

Hi
I have doubt in retry option. i have configured services and routes. In services, default retries values 5 is configured. how to find kong requesting to upstream with retry? have any log? kindly explain we have problem, when compare the upstream and kong access and error log upstream have more request than kong access log

2

Hi @thiraj89, could you give us more information? What is your log level (the default is notice). Are you running any plugins? Are you running a single kong node or multiple? How many workers per node? Do you have access to the logs in the upstream server, or not? If so, do the logs in the upstream server match the logs in the access log? Are all the requests trustworthy, or is the input open to the world (it might be that web crawlers are clogging the Kong server with requests if that’s the case).

3

Hi @kikito, log level is info. We are running only acl, jwt, request termination and request transformation plugins. We are running single Kong node and moving forwarded to cluster. How to find workers? All requests are trustworthy no crawler request. I have compared both Kong access log and upstream access log we find upstream access log greater than kong access log. so i have doubt in retry option . how to find retry request logs.

4

Some of your listed plugins are a natural source of variance.

  • The ACL plugin can deny access based on role (Some access requests will not make it to upstream)
  • JWT can similarly reject requests based on unauthorized access.
  • Obviously, Request Termination will terminate requests

The three plugins mentioned above will make the access log bigger than the upstream log - because the requests rejected never reach upstream. Have you taken that into account when doing your comparison?

The retries are logged only with the debug loglevel. At that log level they should look like:

setting address (try 1): ip:port
...
setting address (try 2): ip:port

However, notice that these lines only happen on retries. If a request gets successfully passed on to the upstream on the first attempt, it does not produce such logs.

Also notice that older versions of Kong (<= 0.13) did handle this part of the code differently and might not be leaving traces at all on retries. Which version of Kong are you currently using?

6

Thanks @kikito. we are using 0.14.1 version. we will enable the debug log level and checking because our problem is kong access log < upstream access log. it shouldn’t happen right because all trustworthy request. It should be like this kong access log > upstream log. I have doubt in kong making any retry request when proxy not reached we have default retry 5.