Failed Request Tracing is a debugging tool provided by IIS to troubleshoot problems such as 500 errors or slow page loading. 1. First install the module through "Add Roles and Functions"; 2. Enable the tracking function in IIS Manager; 3. Configure tracking rules, such as triggering by status code or execution time; 4. The logs are stored in inetpub\logs\FailedReqLogFiles by default; 5. Use the Failed Request Tracing Viewer to view XML logs and analyze the problems of each stage of the request; 6. It is recommended to enable, close and clean the logs on demand in a timely manner, and combine other logs to improve the inspection efficiency.

When your website is running on IIS, a seemingly unavailable error suddenly appears, such as a 500 error or a slow page load, you need a more granular way to troubleshoot the problem. Failed Request Tracing is a very practical debugging tool provided by IIS. It allows you to see every step the request goes through within IIS and helps you locate what is wrong with it.

Turn on the Failed Request Tracing function

To use this feature, you must first make sure it is enabled on the server. Failed Request Tracing for IIS is not a module installed by default and needs to be installed manually through "Add Roles and Features".

• Open Server Manager on Windows Server
• Go to "Add Roles and Features"
• Find "IIS" -> "Web Server" -> "Diagnostics" section
• Check "Failed Request Tracing"

After installation, you also need to enable the tracking function in the specific site or application pool. Enter IIS Manager, select the corresponding site, double-click "Failed Request Tracing Rules", and then click "Enable" on the right.

Note: Log files will be generated after turning on. These files are stored by default in inetpub\logs\FailedReqLogFiles in the site directory. You can modify the path as needed, but it is recommended to keep the default settings for easy search.

Configure tracking rules

Turning on tracking is not enough, you also need to configure tracking rules to tell IIS under which circumstances will the request details be recorded. A common practice is to track specific status codes, such as 500, 404, or requests that have been executed for too long.

In the Failed Request Tracing Rules interface, you can add new rules:

• Select the type of request to track (all content, specific status code, or time range)
• Set trigger conditions, such as the response status code is greater than or equal to 500, or the execution time exceeds 3 seconds.
• Specify the level of event to be recorded, it is usually recommended to select "Verbose" to capture more details

For example, if you find that an API interface occasionally returns 500 errors but is difficult to reproduce, you can set up a rule to track all 500 errors requests. Once an exception occurs, IIS will automatically generate a detailed XML log file, recording the entire process from receiving the request to final output.

View and analyze logs

The generated log is in XML format. Although the structure is clear, it is not very friendly to read directly. Fortunately, IIS provides a graphical viewing tool - Failed Request Tracing Viewer , which can be opened directly in the IIS Manager.

The opening method is as follows:

• Return to the site's "Failed Request Tracing Rules" interface
• Click "View Log Files" on the right
• Select the corresponding log entry and double-click to open it

In this interface, you will see every module, processing stage, and time-consuming process that the request passes. Focus on entries with status "Warning" or "Error", which are often the source of the problem.

Sometimes you will find that a certain request is stuck in the ExecuteRequestHandler stage, which means there is a problem with the specific content handler; if it fails in AuthenticateRequest stage, it may involve permission configuration issues.

Tips and precautions

• Don't turn on all requests for a long time : because it will generate a large number of logs, affect performance, and even occupy disk space.
• Enable rules on demand : Only temporarily enable specific rules when troubleshooting problems, and close them in time after the problem is solved.
• Regularly clean logs : Avoid log accumulation causing server resources to be tight.
• Combined with other logs, analysis : such as IIS logs and Windows Event Logs, can locate problems faster.

Basically that's it. Mastering the usage of Failed Request Tracing is equivalent to giving your IIS debugging toolbox a handy knife. If you encounter difficult and complicated diseases, you won’t be helpless.

The above is the detailed content of Configuring Tracing and Debugging Using Failed Request Tracing in IIS. For more information, please follow other related articles on the PHP Chinese website!