Monitoring Requests and Responses

If the Cluster Diagnosis page does not report any errors that are related to the problems you have observed, the next step is to verify that the Virtual Traffic Manager is correctly managing your traffic – reading requests on behalf of the back-end servers, and returning their responses back to the remote client.

You might find the suggestions in Generating Test Requests useful when attempting to reproduce any problems.

To view connection activity on your Virtual Traffic Manager, click Activity > Connections in the Virtual Traffic Manager Admin UI. The Connections page gives a report of all ongoing and recently completed connections that the Virtual Traffic Manager has managed. Unfolding the Key section gives you details about the information shown.

You can see which Virtual Traffic Manager is currently handling the connection and the back-end node involved; the current state of the connection; and the virtual server, rule and pool currently involved with the connection. You can also see the retry count, idle times and byte counts for the connection.

To keep the data up to date, click the refresh button in your Internet browser. You can also download the data as a .tsv file.

One common error is that the back-end servers issue self-referential responses. For example, suppose that the Virtual Traffic Manager is managing traffic to “www.example.com”, and the back-end servers are named “server1.example.com” and “server2.example.com”. One of the servers issues a response containing a link or redirect to “server1.example.com”. The client would subsequently try to contact the back-end server directly, bypassing the Virtual Traffic Manager and causing problems. Other protocols which embed DNS names or IP addresses in the response are also prone to this type of problem.

You can increase the size of the Connections report using the System>Global Settings page; look in the “Logging” section for the recent_conns key.

You can use the Request Logging facility of a virtual server to log many aspects of a transaction. This is very useful for long-term testing, if errors are intermittent or hard to replicate. Refer to Request Logging for configuration instructions.

if you have complicated TrafficScript logic, you can store debugging information for the connection, and log it in the request log. Use the connection.data.set() function to store the specific data for the connection in a TrafficScript rule, and then log that data in the request log with the %d macro.

You can use a TrafficScript rule to log information about the transactions managed by your virtual server.

TrafficScript functions can retrieve information about every part of a request. Functions such as http.getHeader() and http.cookie() give information about HTTP requests; functions such as ssl.getSessionID() provide details about SSL traffic. For other protocols, you can use the connection.getData() function to return a specified number of bytes of a request.

You can use the log.info() function to write details of the incoming requests to the Virtual Traffic Manager’s event log file, to pinpoint any problems that are occurring with incoming traffic, or you can use the event.emit() function and configure an appropriate Event Handler to give you more control over where debugging messages are recorded.

See the “TrafficScript Reference” for details about available TrafficScript functions.

ATTENTION Take care when logging such information: if you do this for every incoming request, the log file grows rapidly.

The TrafficScript function counter.increment() is used to count how many times a specific event occurred. For more information, please refer to Activity > Current Activity.