The other day I decided to add some really simple health monitoring to my .NET website. That is, if an error occured while someone was browsing the site, then I'd be notified about it and could fix any recurring problems.
I followed a great post by Mads Kristensen which simply involves creating a Web.config file like so:
<?xml
version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings/>
<system.web>
<compilation debug="false" />
<trace enabled="true" localOnly="false" />
<healthMonitoring enabled="true">
<providers>
<add name="EmailProvider"
type="System.Web.Management.SimpleMailWebEventProvider"
from="you@domain.com"
to="you@domain.com"
subjectPrefix="Error:
"
buffer="true"
bufferMode="Notification" />
</providers>
<rules>
<add provider="EmailProvider" name="All
App Events" eventName="All
Errors" />
</rules>
</healthMonitoring>
</system.web>
<system.net>
<mailSettings>
<smtp from="you@domain.com">
<network
host="smtp.domain.com" />
</smtp>
</mailSettings>
</system.net>
</configuration>
If you're adding to an existing Web.config, the bits you need are highlighted. The areas are pretty much self explanatory. First you enable tracing, then you specify the health monitoring provder that you want to use. In my case, I used the email provider, which allows you to specify the email addresses you want to send to and from, along with a prefix for the email subject line. There's an MSDN page on the trace element which gives you all the different values for these settings. For example, you may want to restrict the number of error emails that are sent to you within a minute, so that you're not getting spammed. Then finally, the mail settings is just for providing your SMTP server settings.
Anyway, the point of this post wasn't to regugitate Mads' post, but rather to point out that I had implemented this health monitoring myself, and that it was very easy to set up. However, I soon started getting some odd error emails.
These often related to the elements on my site which would not be directly accessed by a user such as the Webresource.axd file and even C# code files. It turns out that the culprit is actually the Google spider, which attempts to access these files, but because they are restricted by .NET, an error is generated. The best solution so far seems to be the use of robots.txt to exclude spiders from accessing these files.
