tags:

views:

53

answers:

2

I have several .net applications (~100) that I am responsible for overseeing. Some of them have logging to database others have logging to event viewer and others to flat files. Several logging frameworks such as log4net, enterprise library as well as several in-house legacy logging frameworks no one knows how work exactly.

My systems are mainly webservices and smartclients.

I need a way to consolidate the logging from all these systems and different loggers to some unit that provides me with an overview of what is going on. I stumbled upon l4ndash which looks promising but I can't shake the feeling that l4ndash is built to provide overview for one single application. Can anyone elaborate on that? As I have so many systems is it possible to use anything else already out there?

Anything helps.

A: 

The first thing I would suggest is to create a centralized logging system (regardless of what tool you use or if you write custom code). Then with something centralized (preferably a deployable assembly) you can start to point your applications at it. The key here is that if you want to change out your logger is that you only go to one place to manage all of your applications. I suggest that you build this using an abstraction layer within all of your applications that works purely off of interfaces. Then use something like StructureMap at the application level so that you can swap things in and out on a per application basis if need be. I would also use something like StructureMap at the logger level as well so that you can make global swaps at that level too.

For any web style app I suggest using ELMAH as a general logger. I also always have log4net in place monitoring things.

Andrew Siemer
Can you clarify? Are you saying I should make all my applications use the same logging framework such as log4net? When you say i should create a centralized logging system I wonder if there is some standard solution that i can use that works out of the box.
Fadeproof
You can use Enterprise Application Blocks from Microsoft...though I frequently find them to be a bit bloated. Created a central repository either via database or preferably MSMQ would be best. Then clear the queue and process the logged messages as you see fit. But yes, a centralized logging wrapper that all applications can use is best. If not that then a centralized reporting queue that can be notified of log messages...via different frameworks woudl be the next best thing.
Andrew Siemer
A: 

You could log to a central Message Queue.

Thomas Danecker