Skip to main content

IIS–Failed Request Tracing

One of the ways to monitor your IIS traffic is through ‘Failed Request Tracing’. This feature allows you to trace the full request pipeline and capture all the details.

Failed-request tracing is designed to buffer the trace events for a request and only flush them to disk if the request "fails," where you provide the definition of "failure". If you want to know why you're getting 404.2 error messages or requests start hanging, failed-request tracing is the way to go.

Installing Failed Request Tracing

Failed Request Tracing is not available out of the box in IIS but could be installed as a part of the ARR(Application Request Routing) feature. ARR can be installed directly from here or through the Web Platform installer when available in IIS.

After the installation is completed, the Failed Request Tracing feature becomes available in IIS. But before you can use it, you need to enable  it.

If Failed Request Tracing is still not available after installing ARR, you can try to enable the Tracing feature by going to Start -> Turn Windows features on or off -> Internet Information Services -> Health and Diagnostics.

Configuring Failed Request Tracing

Let’s first walk through the steps to enable Failed Request Tracing:

  • Open IIS Manager
  • In the Connections pane, expand the machine name, expand Sites, and then click Default Web Site.

  • In the Actions pane, under Configure, click Failed Request Tracing.

  • In the Edit Web Site Failed Request Tracing Settings dialog box, configure the following:

    • Select the Enable check box.

    • You can change the maximum number of trace files if you want to keep more than 50 requests

  • Click OK.

Now we need to configure a failure definition. A failure definition allows us to specify to conditions when a request should be traced.

  • In the Connections pane, expand the machine name, expand Sites, and then click Default Web Site(or the site that you want to have requests traced).

  • Double-click Failed Request Tracing Rules.

  •   In the Actions pane, click Add.

  • In the Add Failed Request Tracing Rule wizard, on the Specify Content to Trace page, select All content (*). Click Next.

  •     On the Define Trace Conditions page, select the Status code(s) check box and enter the status codes you want to to trace.

  • Click Next.

  • On the Select Trace Providers page, under Providers, keep all check boxes selected. Don’t change the other values.

  •     Click Finish.

View the Failed Request messages

  • To view the failed request messages browse to %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1 (or the location that you configured).

  • Double click on a log file in the folder. For every request a new log file is created. Thanks to the available XSLT, the log file is presented in a digestable format:

    Popular posts from this blog

    Azure DevOps/ GitHub emoji

    I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

    Kubernetes–Limit your environmental impact

    Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

    Podman– Command execution failed with exit code 125

    After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...