What do you do with it? How? Etc. (I’ve just started reading into High Scalability.)
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What do you do with it? How? Etc. (I’ve just started reading into High Scalability.)
This depends in part on the platform you’re using. For instance, if you’re using ASP.NET, then the built-in ASP.NET Health Monitoring already logs uncaught exceptions for you – there’s nothing left for you to do.
I agree that the important points in the lifetime of your site should be made note of. I disagree that traditional text logging is the way to do it. Any logging that is the equivalent of what we used to do with “printf” statements is no better than those “printf” statements. We can do better than that today.
In particular (in the .NET environment), performance counters will often prove to be more useful than logging. Depending on the Operations environment, using WMI may be more appropriate. And in any case, it may be much better to “log” structured data than to log text that then needs to be parsed or else read by a human. “Logging” the context of a problem to an XML column in a database allows sophisticated queries to be performed later to better characterize what’s been going on.
It may also be important that the logging is fast enough to use in Production (to some extent). On platforms that support it, .NET allows you to log using ETW, the same code used by device drivers to log. If it’s fast enough for them, chances are it’s fast enough for your web site.