Component for logging timestamps - Need guidance from Gurus

[Chumma Dede]

Hi,

I need to code a DLL in .NET which logs the response times for our asp.net
multi-tier application. The problem is we need to log the timestamps at
multiple stages in a process lifecycle roundtrip without too much overhead.

We have two webservers which are load balanced and the back end tiers
include Biztalk and several remoting components all of which should ideally
use this same dll for logging timestamps in a central location in the
network. We have AICs in Biztalk where we can insert the component.

So my question is, Is there some readymade component already out there for
this? Maybe an Microsoft application block?
If not, are there any guidelines to follow when building such a dll?

.. Should I log the timestamps in a database table, or is it better to log in
text files?
.. The class should be a static class so it does not have to be instantiated.
.. Make the call to the 'logger' asynchronous. Or should I always call it in
a new thread?
.. Any other considerations?

Our website is a high-volume, highly available, 24/7 environment so this
should have the least bit of overhead to the main web application.

Looking forward to any suggestions/comments.

Thanks!
Chumma Dede

 

[Scott Allen]

I'd suggest you take a look at a couple open source logging
components: Enterprise Library [1] (includes a logging /
instrumentation block) and log4net [2].

I did an article on OdeToCode highlighting some areas you'll want to
consider during design [3]. Ideally, any logging framework will be
configurable enough to use different destinations, depending on your
need. For instance, it's nice to log response times into a database
for day to day operational monitoring, but the day might also come
when it would be great to change a web.config setting and see verbose
tracing information for troublshooting written to a log file on disk.


[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp

[2] http://logging.apache.org/log4net/

[3] http://odetocode.com/Articles/294.aspx


HTH,

 

[Chumma Dede]

Thanks alot!! I will look into the links you gave me.

I'd suggest you take a look at a couple open source logging
components: Enterprise Library [1] (includes a logging /
instrumentation block) and log4net [2].

I did an article on OdeToCode highlighting some areas you'll want to
consider during design [3]. Ideally, any logging framework will be
configurable enough to use different destinations, depending on your
need. For instance, it's nice to log response times into a database
for day to day operational monitoring, but the day might also come
when it would be great to change a web.config setting and see verbose
tracing information for troublshooting written to a log file on disk.


[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp

[2] http://logging.apache.org/log4net/

[3] http://odetocode.com/Articles/294.aspx


HTH,

--
Scott
http://www.OdeToCode.com/blogs/scott/

Hi,

I need to code a DLL in .NET which logs the response times for our asp.net
multi-tier application. The problem is we need to log the timestamps at
multiple stages in a process lifecycle roundtrip without too much overhead.

We have two webservers which are load balanced and the back end tiers
include Biztalk and several remoting components all of which should ideally
use this same dll for logging timestamps in a central location in the
network. We have AICs in Biztalk where we can insert the component.

So my question is, Is there some readymade component already out there for
this? Maybe an Microsoft application block?
If not, are there any guidelines to follow when building such a dll?

. Should I log the timestamps in a database table, or is it better to log in
text files?
. The class should be a static class so it does not have to be instantiated.
. Make the call to the 'logger' asynchronous. Or should I always call it in
a new thread?
. Any other considerations?

Our website is a high-volume, highly available, 24/7 environment so this
should have the least bit of overhead to the main web application.

Looking forward to any suggestions/comments.

Thanks!
Chumma Dede