I have been using (and loving) App Insights a lot recently and one of the things that have really impressed me is the capability and power of the queries when analysing usage patterns. One thing that caught me out however, was counting the number of requests when the sampling was active – in my case when the site was getting a lot of traffic during load testing.

Creating a simple chart showing number of requests per minute over the last hour using:

1 requests
2 | where timestamp > ago(1h)
3 | summarize count() by bin(timestamp, 1m) 
4 | render timechart
5 

1 requests
2 | where timestamp > ago(1h)
3 | summarize count() by bin(timestamp, 1m) 
4 | render timechart

Was showing far less than anticipated after my load tests?

Turns out (if you actually read the docs) this is directly called out:

https://docs.microsoft.com/en-us/azure/application-insights/app-insights-analytics-reference#count

So remember to use the sum(itemCount) approach:

1 requests
2 | where timestamp > ago(1h)
3 | summarize sum(itemCount) by bin(timestamp, 1m) 
4 | render timechart

Fairly significant difference!

1 requests
2 | where timestamp > ago(1h)
3 | summarize count() by bin(timestamp, 1m) 
4 | render timechart
5 

We have all seen code bases that are hard to read and follow, long methods, repeated code, loads of parameters and all the other smells that literally keep us awake at night (or is that just me?)!

The larger and more complex your system gets, a non-existent or difficult to read architectural view of the system can be as bad for maintainability as a difficult to read code base. The larger your system gets (and the more people you have working on it), you will likely increase maintainability by putting attention into abstract architectural views. These views will give a point of reference allowing the team to see what they are building into, easily assess the impact of change - and perhaps more importantly support the architectural re-factoring that is often neglected.

What form this view takes (beyond the obvious boxes and lines) is very dependent upon the nature of the system. For example with very large systems with complex interactions then I find views showing the dynamic behaviour of the 'deliverables' (or the independently versioned components) gives a high enough abstract view - enough to see the dependencies across important scenarios. Often I use UML collaboration or communication diagrams, for easy explanation of the meaning, but anything that the team can understand will do.

With smaller systems you may need to go below the deliverable to see interactions between sub components. Regardless of the approach I find the best way is, just like your code, to iterate it. Ensure it is valuable to the team and proving useful. Reflect often and if you find questions not getting answered by the abstract views adjust them.

This is not a new article, and blatantly steals from two other extremely helpful sources on this topic namely

https://www.troyhunt.com/shhh-dont-let-your-response-headers/ and

https://www.saotn.org/remove-iis-server-version-http-response-header/. The reason for this article is to update the references slightly as I found a few changes during a recent ASP.NET MVC deployment to an Azure App Service.

Starting with the simplest first the X-AspNetMvc-Version header can be removed by adding a line to Global.asax.

MvcHandler.DisableMvcResponseHeader = true; 

This is pretty clear and is obviously specific to ASP.NET MVC, but it can also be removed using changes to web.config to remove custom headers – this is the approach required to remove the X-Powered-By header.

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <remove name="X-Powered-By"/>
            <!-- can also remove the MVC version header using this approach -->
            <!-- <remove name="X-AspNetMvc-Version"/> -->
        </customHeaders>
    </httpProtocol>
</system.webServer>

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <remove name="X-Powered-By"/>
            <!-- can also remove the MVC version header using this approach -->
            <!-- <remove name="X-AspNetMvc-Version"/> -->
        </customHeaders>
    </httpProtocol>
</system.webServer>

The X-AspNet-Version header can also be removed by amending config, just unset the system.web httpRuntime enableVersionHeader attribute.

<system.web>
    <httpRuntime enableVersionHeader="false" />
</system.web>

Removing the Server header in Azure App Services is apparently very easy now. The long story is that in IIS 10 an attribute was added to config to allow removal of server header. Now the version of IIS reported by Azure at the time of publishing is 8, however, the removeServerHeader attribute does actually work? Sources indicate that Azure is running a custom version of IIS that is not in line with any OS version.

So cutting to the chase to remove the Server header in Azure App Services you just need to amend web.config to set the removeServerHeader attribute.

<system.webServer>
    <security>
        <requestFiltering removeServerHeader="true">
        </requestFiltering>
    </security>
</system.webServer>

The existing approaches still work of course, the most often used one was to blank out the Server header using a rewrite rule.

<system.webServer>
    <rewrite>
        <outboundRules>
            <rule name="Blank Server header">
                <match serverVariable="RESPONSE_Server" pattern=".+" />
                <action type="Rewrite" value=""/>
            </rule>
        </outboundRules>
    </rewrite>
</system.webServer>