Access Logger

Creating and Debugging Filters with Access Logger

Using the Access Logger

The access logger has two properties. One is for recording specific payloads to create routes, filters, and operations on your payloads to be secured. The second property is recording traffic, status codes, and showing you what requests are being made through VGS to and from your server.

Enabling the record function will record traffic for 1 hour. During this time, you can introspect on traffic and fine-tune your configurations.

Viewing Payloads

To view the requests that were captured, after you've clicked record and sent data through, click 'Load New Requests' if it hasn't populated. Recorded requests will show a little database icon to the left.

Once you click an entry a pop-up showing you all the details of the payload (Headers and Body, Request and Response) will be viewable.

Within this view, we have more context around the request, including headers, body, origin, etc.

Right now, you can see the Request Body with the original value being rewritten to the alias.

From here, we can select the payload we want to operate on and generate filters and a route for and get the following options to operate on our data. Redact/Reveal, Storage, and Format.

Debugging

If an error occurs while sending data, the access logs are an extremely useful tool. Here we have a 405 Method not allowed error.

Clicking on the item with the error status code reveals the full error message response and enables us to inspect the Request that caused the error.

In this case, this particular endpoint only allows for HEAD, OPTIONS, and POST. Our request caused an error because it was a GET to a /post route.

Our access logs show the body of the payloads and the response messages. It is also useful for making sure headers, endpoints, paths, etc., align with the filters set up.

While setting up filters, you may need some insights into whether filters' conditions and operations are matched in requests - pay attention to the Match Information section of the General tab.

Access Logs

The additional functionality of the Access Logs is that in the Live environment and Sandbox environment, you will see the most recent requests that traveled through VGS, their status codes, and the time of the action. This is useful for seeing which of your requests finished with good status codes and those that have failed. These are distinct from the other requests that are recorded by their lack of the database icon.

Request pin/unpin mechanism

To enhance the debugging experience for our internal and external users, we have added and expanded the existing functionality of Access Logs and implemented a pin/unpin mechanism.

Access Logs help to debug issues with route configuration; however, their lifetime is short: 24h for logs, 1h for a log with the payload. From now on, there is a possibility to save the needed requests and reproduce the issue/test scenario without fear of losing the context.

Pin/Unpin mechanism allows:

• Pin a request with or without the payload

• Unpin a request from the table

• Filter by pinned-only requests

Pin Request restrictions:

• Pin Request works on the Sandbox environment only, as the Live payload contains sensitive data

• A maximum of 50 requests can be pinned at the same time

• Pinned requests are kept for 90 days or until they are unpinned

Download logs

For performing a more detailed analysis of your requests and applying more advanced filtering, use the download logs feature.

Downloaded logs restrictions:

• Last 24 hours

• Last 10,000 requests

• Payloads can’t be downloaded

Data format: JSON

Tips

• A 407 error, an authentication error, will prevent you from seeing an upstream response in your Access Logs because the request will terminate at our authentication check before going through our service.

• A 504 response will not produce an error code in the logger. Instead, this means that our service was unable to connect to the destination on the outbound connection (e.g., no status code was returned)

• If you see a request and no response, it may mean that your request didn’t complete its route through the tunnel to its destination.

• If you don’t see anything on the Access Logs page (and logging is enabled), you’re not hitting the VGS service.

• The Access Logs also allow you to see what inbound data your server will receive and what outbound data third parties will see.

If you have any questions, comments, or feedback on this guide, contact us on our site chat or at [email protected]