Which Events Should I Monitor?






Which Events Should I Monitor?

Every application is different, but design documents such as threat models[2] and performance models[3] can help you determine what to monitor. If you don't have the time to build these types of models, then at least take the time to identify key scenarios and determine which events should be logged on a normal basis. Do your best to ensure your application is configured by default to log these events.

[2] The Microsoft patterns & practices Web site has some excellent guidance on threat modeling at http://msdn.microsoft.com/library/en-us/dnpag2/html/tmwa.asp, or you can search for "Threat Modeling Web Applications."

[3] See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt02.asp to learn more about performance modeling. This is actually Chapter 2 of a book called, Improving .NET Application Performance and Scalability by Microsoft Press.

Don't just consider the built-in Web events. You should also determine what data must be available for monitoring, even if ASP.NET doesn't provide built-in support for monitoring that data. Build custom Web events to cover these cases. When something goes wrong, the first thing a good administrator is going to do is crank up the level of monitoring in order to diagnose the problem. Verbose data need not be logged on a regular basis, but if it helps rapidly diagnose problems when your application is running, it could save lots of money over time.

One last thing to consider is that administrators often use monitoring tools to help determine when an application needs to be scaled up in some way. Consider instrumentation that assists in this planning process, including custom performance counters.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows