This article illustrates how to configure and customize the health monitoring system of ASP.NET.
Custom errors and early error-logging effort
In the beginning, webs were just "webs", webs of interconnected links to static HTML pages. Now webs resemble more of communities bustling with activities, with members of different roles, media in all forms and shapes, etc. As a web site grows more complex, the opportunities for errors and exceptions multiply. As it attracts more users, it becomes a bigger target of malicious attacks. Now it has become a must for a website to have a systematic approach to log web events, monitor the ebbs and flows of user activities, locate traffic bottlenecks, and handle exceptions and errors gracefully.
For ASP pages, programmers generally do not have many choices but sprinkle response.write statements to check the inner working mechanism of a segment of code.
With ASP .NET 1.x, programmers are equipped with a set of tools for tracing and error handling. And it became a standard to configure custom error pages whenever an error occurs. Errors are part of programming life, however it is not acceptable to have an application crash and throw at users' face an ugly yellow page filled with obtuse non-English words. It could also be dangerous, if critical technical details are exposed to "evil" eyes.
To use custom error pages, we use the customerErrors section in the web.config (For .asp pages, the way to do it is going to the IIS administration console to specify the path for different custom error pages for different error codes, however if you do not have access to the IIS, it would not be an option).