Clever Geek Handbook

Logging capabilities on Server2008 / iis7?

I unexpectedly got rid of debugging / figuring out what was wrong with an asp.net app that crashed its ApplicationPool a few days ago. 5 bugs in 5 minutes we fixed took it down. The problem is that it still served as pages and thus returned 503 for some visitors only. We have poor logging in the application and this rarely happens and only with one of the servers in the farm, so it's hard to know what is wrong.

Now for questions. I'm not an administrator and newbie for both IIS7 and Server2008, so I'm just looking around for the capabilities that I have. What I know and have:

  • Log file httperr.
  • Some site-specific logs in wc3 format that are saved to another drive look like access logs?
  • event viewer

There is also the option to tune queries with traceback errors, I understand that this can lead to some performance though?

Am I missing anything that is registered or can be registered? Any general advice on how I can test my servers to ensure that applications are behaving as they should?

I will look into LogParser as it looks like something I need, any advice out there?

EDIT: I'm also interested in the machine health logs. Like cpu-load, memory, etc. Are there any possibilities?

+1


source to share


3 answers


You should check out Tess Ferrandez's " If it's broken, fix it, you need " blog. This is the best resource I know for debugging asp.net applications. Probably all magazines won't help you. Typically, its application code is responsible for crashes.



+1


source


In our web application, I will catch all unhandled exceptions through the HttpApplication error event and register them in the database with all the necessary ancillary data. If this log fails, I resort to EventLog windows. Then I have a service running on a different machine that checks the logs and site periodically, and email me updates on a schedule.



0


source


If you are feeling particularly adventurous, there are ways to generate and analyze IIS crash dumps.

http://support.microsoft.com/kb/892277

Using this, it is possible to detect the call stack at the point of failure.

0


source






More articles:


All Articles