Overview
Failed Request Tracing Rules is a powerful tool for troubleshooting request-processing failures in IIS 7.0. This topic leads the reader through the steps to enable Failed Request Tracing Rules to debug failures and trace steps in Application Request Routing. For more information about Failed Request Tracing Rules, refer to this article.
Goal
To configure Failed Request Tracing Rules and to understand what to look for when troubleshooting Application Request Routing.
Prerequisites
This walkthrough requires the following prerequisites:
- IIS 7.0 on Windows 2008 (any SKU).
- Microsoft URL Rewriter Customer Technical Preview (CTP) 1.
- Microsoft Application Request Routing CTP1.
- Minimum 2 content servers with ASP.NET installed.
If URL Rewriter CTP1 or Application Request Routing CTP1 has not been installed, it is available for download at:
- URL Rewriter x86
- URL Rewriter x64
- Application Request Routing x86
- Application Request Routing x64
Another prerequisite is that the reader has gone through the other walkthroughs found at <add link> and has configured Application Request Routing. The Application Request Routing should be in a working order before proceeding with this walkthrough.
Step 1 – Configure Failed Request Tracing Rules
In this step, the Failed Request Tracing Rules are defined for Application Request Routing.
To configure Failed Request Tracing Rules via UI:
1. Launch IIS Manager (inetmgr).
2. Select the Default Web Site:
3. In Actions pane, under Configure, select Failed Request Tracing…:
4. In Edit Web Site Failed Request Tracing Settings dialog, check Enable checkbox:
5. Click OK to save changes.
6. Select the Default Web Site.
7. Locate Failed Request Tracing Rules icon and double click on the icon.
8. Under Actions, click on Add…:
Select All content (*) and click Next.
9. Select Status code(s): and enter 200-399:
Click Next. Above configuration has created a Failed Request Tracing Rule that when the status code falls between 200 and 399, traces will be written.
10. Deselect ASP, ASPNET and ISAPI Extension. After selection WWW Server, deselect everything under Areas:, except for Rewrite and RequestRouting. Since Application Request Routing relies on the URL Rewrite Module to inspect the incoming requests, it would be recommended to enable the traces for both Application Request Routing (RequestRouting) and URL Rewrite Module (Rewrite):
For additional information on URL Rewrite Module traces, refer to http://learn.iis.net/page.aspx/467/using-failed-request-tracing-to-trace-rewrite-rules/.
11. Click Finish.
Step 2 – Analyze Failed Request Tracing Logs
In this step, we will send requests to Application Request Routing and analyze Failed Request Tracing logs.
To view Failed Request Tracing logs:
1. Navigate to a directory where the Failed Request Tracing logs are written. By default, the location is %SystemDrive%\inetpub\Logs\FailedReqLogFiles\.
2. Change directory to the folder that matches the Default Web Site. By default, this is W3SVC1. If you are unsure, select the Default Web Site in inetmgr and select Advanced Settings… under Actions. The value of the ID indicates the corresponding folder. (ie. ID 1 corresponds to W3SVC1).
3. If there are any xml files, remove them by typing:
del *.xml
4. Send a request to Application Request Routing. If Application Request Routing is functioning correctly, it would result in a 200 response which falls within the 200 to 399 range that was specified in step 1. Therefore, the logs are written to the location above.
5. List the files in the directory to confirm that new xml files are written.
6. Open the xml file. Click on Request Details. Select Complete Request Trace and click on Expand All. Below is an example of a Failed Request Tracing log for Application Request Routing:
7. Pay closer attention to the following sections:
- GENERAL_REQUEST_HEADERS:
- Headers: Shows the HTTP header as the Application Request Routing has received.
- ARR_REQUEST_ROUTED:
- WebFarm: Indicates the name of the server group where the request is routed to.
- Server: Indicates the destination server where the request is routed to.
- Algorithm: Indicates which load balance algorithm is used.
- RoutingReason: Indicates the decision behind why the server is selected.
- ARR_SERVER_STATS:
- State: Availability of the destination server.
- TotalRequests: Runtime statistic on how many requests have been sent to this server.
- CurrentRequests: Runtime statistic on the concurrent number of HTTP requests to this server.
- BytesSent: Runtime statistic on how much data in KB have been sent to this server.
- BytesReceived: Runtime statistic on how much data in KB have been received from this server.
- ResponseTime: Runtime statistic on the responsiveness in ms of this server.
- GENERAL_RESPONSE_HEADERS
- Headers: Shows the response HTTP header from the destination server.
- GENERAL_RESPONSE_ENTITY_BUFFER
- Buffer: Shows the response entity from the destination server.
- The followings have been added with the timestamps to indicate the start and the end times of corresponding events to profile the performance of Application Request Routing:
- ARR_REQUEST_HEADERS_START
- ARR_REQUEST_HEADERS_END
- ARR_RESPOSE_HEADERS_START
- ARR_RESPONSE_HEADERS_END
- ARR_RESPONSE_ENTITY_START
- ARR_RESPONSE_ENTITY_END
- ARR_RESPONSE_ENTITY_START
- ARR_RESPONSE_ENTITY_END
Summary
You have now successfully configured Failed Request Tracing Rules for Application Request Routing. Failed Request Tracing Rules can be used to troubleshoot and debug Application Request Routing as well as understanding the routing decisions, including load balance algorithms, that it has made in selecting the destination server for a given request.
Related Content
Comments