Ensuring your API requests are correctly routed through Tyk Gateway is essential for maintaining smooth operations. In this guide, we'll share some practical methods to help you verify if your requests are being proxied successfully. We'll cover the following:
- Checking analytics fields: Discover what to look for in the analytics data to determine if Tyk handled your requests.
- Analyzing gateway logs: Gateway logs are like a logbook for Tyk, keeping track of everything that happened with the request. We'll show you how to use them to see if the request made it through the gateway.
- Observability through Otel: (coming soon)
By the end of this guide, you'll be a pro at verifying if your API gateway is working as expected and troubleshoot any problems that arise
Checking analytics fields
Let's take a look at the analytics data. There are some clues here that can tell you if Tyk was involved:
Request Time/Latency: A positive RequestTime orlatency
value in the analytics record is a good indicator, suggesting Tyk has forwarded your request upstream successfully. Typically you should see a value greater than zero as shown belowResponse Headers: By default the gateway does not include the request and response payloads in the analytics record to avoid logging sensitive info and optimise the transaction size. However, you could enable detailed logging and inspect the raw response headers for the presence of the x-generator key. Please note that the header isn't present when 404s are logged. To track/troubleshoot 404 responses, enable track_404_logs on the gateway.
Analyzing gateway logs
Another approach to confirming your request's passage through the gateway involves examining the gateway logs. These logs document your request's journey through Tyk, with various checkpoints along the way. Enable debug mode for logging, and you'll see timestamps and logs for several middleware points throughout the execution order of the request cycle including the "proxy/final stage".
time="May 09 11:49:35" level=debug msg=Started api_id=257ca2c7e55a4d90797d5d414df8ca97
api_name="<api-name>" mw=ReverseProxy org_id=<org-id> ts=1715255375875254400
time="May 09 11:49:36" level=debug msg=Finished api_id=257ca2c7e55a4d90797d5d414df8ca97
api_name="<api-name>" mw=ReverseProxy ns=237537200 org_id=<org-id>
The log snippet above shows that the start and finished time of the proxy request, along with the API involved and the time in nano seconds it took for the request to successfully make it to the upstream and back.
Comments
0 comments
Please sign in to leave a comment.