SiteServerDetails–Obtaining information about a server node in a web farm—Part 13 of 52

This week I cover a couple ways to obtain information about a specific server in a web farm.  How can you tell which node handled your page request? Often it’s valuable to know which node is currently being served for troubleshooting the load balancer or individual pages.

I posted another non-video blog post this morning that covers this same topic and provides the download link to SiteServerDetails.

This is week 13 of a 52 week series on various web administration related tasks. Past and future videos can be found here.

Today’s video walks through this HTTP Handler and how you can install it on your web farm.  Just now I realized that I forgot to mention how to roll this out on a full web farm with multiple nodes (the target install situation). 

The install won’t break anything, even if you install it while shared configuration is enabled.  Simply run the quick install on each node of the web farm and it will install without any impact to the production environment.

Having problems viewing on your mobile device? Click here instead.

4 Comments

  • There are also some other important information available for administrator. As given in,

    http://bradwilson.typepad.com/blog/2010/03/diagnosing-aspnet-mvc-problems.html

    http://weblogs.asp.net/imranbaloch/archive/2011/03/14/monitoring-asp-net-mvc-application.aspx

    May be you will cover these information in your next videos.

  • Thanks Imran. That's great feedback. You're right, there's some great tools available now for monitoring the application performance. I added the suggestion to my video series agenda. Not sure which items I'll get to or not but it's definitely noted.

  • The problem is that for a load balancer requests to a url and url/siteserverdetails.axd can come from different nodes. I usually use Fiddler and insert host name and IP in an "X-" header using URL Rewrite outbound rules.

    Advantage - no need to install anything because you already have URL Rewrite on your Web Farm nodes. All done by appcmd.
    Disadvantage - a potential slight overhead (never observed) for URL Rewrite processing

    REM Next line is a workaround because URL Rewrite needs something to "rewrite" it can't add a header to Http Response. Adding custom header X-Responding-Host which can be seen in Fiddler and any network monitoring tools for every response

    appcmd set config -section:system.webServer/httpProtocol /+"customHeaders.[name='X-Responding-Host',value='*']" /commit:apphost

    REM create outbound rewrite rule for the server

    appcmd set config -section:rewrite/outboundRules /+"[name='X-Responding-Host',patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost

    REM add condition and action to the rule
    REM None rule syntax for matching response header name, it needs prefix "RESPONSE_" and all dashes replaced with underscore

    appcmd set config -section:rewrite/outboundRules /[name='X-Responding-Host'].conditions.trackAllCaptures:"False" /[name='X-Responding-Host'].match.serverVariable:"RESPONSE_X_Responding_Host" /[name='X-Responding-Host'].match.pattern:"*" /[name='X-Responding-Host'].action.type:"Rewrite" /[name='X-Responding-Host'].action.value:"{SERVER_NAME}/{LOCAL_ADDR}" /commit:apphost


    The above adds the following in applicationHost.config
    in
    under


    and under





  • Hi Mikhail,

    Great comment and install instructions! I think we're on the same wavelength. My next video session covered that same solution: http://weblogs.asp.net/owscott/archive/2011/04/03/url-rewrite-outbound-rules-and-servernamevariable-part-14-of-52.aspx

    I explain an add-on to provide the server name.

    The {SERVER_NAME} variable is the website name and not the actual machinename, unfortunately, otherwise that would be the ideal solution. If you rewrite the {SERVER_NAME} at the local balancer than it could work.

    {LOCAL_ADDR}, on the other hand, should be specific to each node, which avoids the provider that I offered. The provider gives the full machine name, which is a bonus, but {LOCAL_ADDR} can do the trick.

Comments have been disabled for this content.