views:

16051

answers:

30

Hi,

My team is about to start a new enterprise wide ASP.NET development project, quite possibly the largest undertaken by my department so far and the largest project that I've ever worked on. I'm looking for a good logging solution for the system. There are two questions I have if anyone knows the answer.

Firstly what logging tools are currently available and widely used?

Secondly, for an ASP.NET (probably MVC) enterprise applicaiton, which tool is most appropriate based on your experience?

So far I've used Log4Net almost exclusively for all my previous projects, it's a fantastic tool, however I would like to see if there is anything I've not used out there before I start a project of this magnitude or if there is any reason I would not want to use Log4Net for a project of this size.

Thanks Daniel

A: 

Edit: I copied this from another one of my answers on the same topic. I've substantially changed the original answer because I'm tired of all the down-votes and can't delete the answer since it's the accepted answer.

ELMAH is particularly nice if you're using ASP.NET. One of my favorite features about ELMAH is not having to build the UI to view logged exceptions; ELMAH provides a handler that will report your exceptions. However, I've never used it for logging anything other than exceptions.

log4net, and Microsoft's EntLib are some other ideas that come to mind. These provide a lot more functionality than what you may need if all you really need is just exception logging.

Also, you may consider performance counters if what you're really trying to do is measure your application. Again, the benefit of using performance counters is that after publishing the data, you won't have to worry about build the UI to view/query the data.

Esteban Araya
Hands down? I'm kind of surprised this got marked as the *answer*. Can someone please elaborate on what is good / better about Enterprise Library's logging?
Winston Fassett
I'm also concerned that this was marked as the answer.
sontek
No need to be concerned. My final solution went ahead with the enterprise library for a few reasons, firstly we were using a few other features of the library, secondly I liked the implementation and thirdly it was powerful enough for our needs.
Odd
The answer wasn't elaborate, but it made the suggestion that assisted me in finding the correct solution. I have elaborated as to why here: http://oddiandeveloper.blogspot.com/2008/09/microsoft-enterprise-library-1-logging.html
Odd
I think the problem that people are eluding to is the definitive nature of the response with absolutely no discussion as to why. IMO the "answer" to this type of question should be a well-rounded discussion of the alternatives out there, along with the relative merits of each. Remember that this is not just for you, but also for other people who may ask this question in the future.
akmad
Enterprise Library is a reasonable choice if you're using other parts of it already. If logging was all you wanted though, I think log4net is faster than its Enterprise Library counterpart.
Scott A. Lawrence
I'd agree with akmad normally except it seems any time you have anything approaching a 'discussion' on here you need to beware the bandwagon of evangelists busting a nut to mark your post as subjective and close the question accordingly.
FerretallicA
I'm really surprised at how many people dislike the EntLib logging framework. I personally prefer log4net, but honestly, is EntLib *that* bad?
code4life
There are two different concepts at play here and they're often tenuous. Accepted answer is what the author ended up choosing (e.g. in their real world implementation). Most amount of votes is what the community generally (even theoretically) thinks is best. These often compete, but not always. Some questions are specific to a need, some to a theory.
John K
I think the downvoting is a bit harsh here. This guy didn't mark his answer and the right one, the question asker did!
badbod99
+93  A: 

I don't see any reason not to use Log4Net for a large application. It scales extremely well. Search for other questions about logging, there have been several about how much detail to log and what tools to use. Personally, I've used Log4Net for projects with hundreds of classes and thousands of lines of code and never had an issue.

If you are familiar with it and it works, look no further.

Geoff
I use log4net and find it works well, however it is a little tiresome to set up for new projects, and if misconfigured just sits there silently rather than hinting at what might be wrong.
Richard Ev
Tiresome to set up for new projects? Add a reference, add a line in Main or Global, copy-paste into app.config, that's it....
Justice
@Richard E- it usually hints as to what is wrong if you have a Console window running...
RichardOD
@Richard E - Given a choice between sitting silently and causing the actual application to fail, I think the log4net team made the right choice for how log4net behaves at run-time. Configuration could be easier though.
Scott A. Lawrence
I used log4Net for .NET 1.1, but i don't have good experience, in-fact whenever we deploy an update it stopped working, anyway i haven't used it afterwords. I have been using Enterprise Library with DB as back end for quite a long time and it seems to be a reasonable choice
BT
+21  A: 

The problem with the Enterprise Library is that it's extremely bloated if you're only using logging.

I suggest using Log4Net with a custom wrapper, so you're not tethered to that specific framework if you have a business need to change at a later date.

Ian P
Instead of a custom wrapper, consider using Common.Logging (see my answer)
Matt Howells
Surely a major benefit of Log4Net is its appender architecture, which allows you create new output destinations. That is, log4net can handle change under the API, rather than forcing a wrapper over it.
Simon Gibbs
And IMO log4net is bloated compared to Trace.
FuleSnabel
+5  A: 

Can't vote up, but +1 for Log4Net, and NLog seems good too.

http://www.nlog-project.org/

goodwill
A: 

Depending on what you're logging, Health Monitoring in ASP.NET is worth looking into for logging instrumentation info and extending it is fairly straightforward in most situations.

Bullines
+14  A: 

If you are looking for a simple non-bloat solution (the download is only about 100K and the actual dll about 40K), I've successfully used BitFactory on a number of projects.

It's small, configurable, reliable and free!

nzpcmad
Doesn't look free anymore: http://dotnetlog.theobjectguy.com/Download.aspx :(
program247365
+1 It's not free anymore, but it's really cheap :)
Mark Seemann
+2  A: 

I think that simple Windows event log or trace logging is often overlooked. For SQL-Server type transaction logs, there's System.IO.Log.

Mark Cidade
Unless you have a mechanism for dragging your log events out of the event log I would avoid using it as a primarly logging repository. Log files are a lot easier to sift through.
Richard Ev
The Windows Event Viewer is as good as any other log viewer I've come across or built.
Mark Cidade
+1  A: 

i can vouch for log4net.. we use it in all of our .net applications (which are large multi-tiered enterprise scale apps)..

SmartyP
+2  A: 

Log4Net, because it just works. And it's extremely configurable. The Enterprise Library is constantly shifting. the Log4 stuff is pretty mature/stable. Who knows when Microsoft will drop the Enterprise Library.

No Thanks!

Giorgio Galante
+60  A: 

A lot of people underestimate the power of built in Debug.WriteLine and Trace.WriteLine. With those you can actually define different locations to output (i.e text file, xml, or Console.Out) and you don't have to rely on any external dependencies.

The point of Trace.WriteLine and Debug.WriteLine is to give you the ability to monitor certain areas of your code when debugging or tracing but avoid cluttering your screen or hard drive with useless output when you aren’t. When most people stumble upon Trace/Debug they think it should “Just work”–without any setup–this isn’t the case.

Another great benefits of using Trace/Debug instead of the old Console.WriteLine is you can define exactly where to log to in your app config or with environment variables, so sometimes you might want direct output to the Console but other times you might want to log to a file.

To get your output from Trace/Debug you first need to define either DEBUG or TRACE in your preprocessor directives.

You can do this in code by placing:

#define TRACE

in your code or by defining it in Visual Studio.

after you have your preprocessor directives setup, you have to define where to log to. You can do this by defining it in your app config:

<configuration>
  <system.diagnostics>
    <trace autoflush="false" indentsize="4">
      <listeners>
        <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="TextWriterOutput.log" />
        <remove name="Default" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

and then you can start your logging with System.Diagnostics.Trace.WriteLine(”Hello World”).

To learn more about Trace/Debug check out:the docs here.

sontek
I use a text writer trace listener for debugging log4net, and it doesn't scale at all well. It will break your app once the log file grows over a few 100mb.
Simon Gibbs
Note: If you build from within Visual Studio, the default Debug and Release configurations both define TRACE by default. See the project Properties editor.
gWiz
100mb log file sounds like you're replacing it for breakpoints or IIS logging @Simon
Chris S
log4net uses this facility to report errors such as broken database connections. The app was reporting bad client messages as warnings so that operations could work with the customers to fix issues.
Simon Gibbs
Looks like you can build your own TraceListener also, SQLite version would be useful for larger logs.
badbod99
Maybe not applicable for OP but Trace has one killer feature: It's built-in into .NET which means no extra dependencies. Why is dependencies a problem you might ask? Well in my workday we are asked to integate alot of external projects that use a lot of dependencies. These dependencies often conflict creating huge issues during deployment. GAC is heralded as the solution but sometimes that doesn't work because these dependencies are not strong named, or strong named the wrong way. Also GAC requires admin to install.So when people add a dependency for something that's built-in I gnash my teeth.
FuleSnabel
+2  A: 

I've used Log4Net, and it's fine, but I've always felt that it is a tad overkill. My usual approach is to implement a Logger class with methods like Error, Warning, Info and Debug which simply write to the Event Log using the standard .NET framework classes for that. I then set up an external monitoring tool, which will monitor the Event Log for specific types of messages and send emails or write to a database or whatever. The benefit is that you don't have to worry about a third party dependency, the code is really simple and you can find a cheap tool to do almost anything you want with it once it's been logged. I currently use PA Server Monitor, which is one of the best pieces of monitoring software I've seen in a while.

jeremcc
Agree that Log4Net is overkill. It is not hard to write your own logging classes.
darasd
@codeflunky - Does your approach really save that much work over configuring log4net to configure SmtpAppender and EventLogAppender?
Scott A. Lawrence
+7  A: 

I'd recommend NLog, it's as powerfull as Log4Net but with easier configuration. (IMO)

Graeme Bradbury
+20  A: 

You could use Common.Logging. This provides a lightweight logging wrapper so that you can trivially change the underlying logging mechanism later if you need to. Since you are already familiar with log4Net, I'd recommend using it as the underlying logger.

Matt Howells
you got my vote! Common.Logging rocks :-)
gef
As you just pointed it out to me, +1.
RichardOD
A: 

ViewonLog is useful. The good thing about this logging tool is the customizable logging policy, you can change the logging policy in run-time very easily (in the UI).

A: 

I like log4net - it has good performance and is very flexible. More recently I've been using the logging in the MS Patterns and Practices Enterprise Libray 3.1 and 4.0 - the main reason being is the integration with the exception handling block and the policy injection - which brings with it elements of aspect orientated programming - I can add a LogCallHandlerAttribute to a method and have the entry and exit to the method automatically logged complete with the parameter values without writing a single line of code - add to this the other call handlers for exception handling and validation (from the validation block ) and you get a great productivity boost. the downside is that the entlib can be a pain to configure with lots of cruft to do in the app/web.config but they do supply a pretty nice configuration editor.

Richard
+11  A: 

One of the best kept secrets in the .NET Framework is the End to End Tracing capability. It's mostly associated with WCF but it works across client and server tiers. Check out Scott Hanselman's podcast for a good overview.

http://www.hanselminutes.com/default.aspx?showID=68

Rob Windsor
A: 

+10001 on log4net.

The appender model to pipe logging into multiple "sinks" as well as better buffering, ease of setup, the ability to output in the same format as java compoenents which might lie in your stack has made log4net my go to logging for the last 5+ years. Enterprise lib is heavy handed and has deployment headaches in writing to the event log by default.

As Ron Popeil sats, "set it and forget it!"

+4  A: 

I don't have the reputation score yet to vote an answer up or down so i'll re-iterate what most have been saying here.

Log4Net is a brilliant solution for logging - you can write your own extenders if you want behavior that's not currently supported.

We've implemented it on an enterprise sized project and it's working a treat - very little bloat as it does exactly what you want it to do - logging - no frills, no fancy stuff, just logging.

So another ++ for Log4Net

Brian H. Madsen
+6  A: 

The code for Log4Net may be larger than the code for your entire project. It is bloatware! Try this if you want something that is easy to use and as flexible as you'll ever need.

+3  A: 

This guy has an interesting take on logging frameworks.

+6  A: 

Another logging question! Well, as I've said already, we've been using The Object Guy's Logging Framework for years. It is in several of our production applications. It is easy to use and easy to extend. You can't go wrong with it.

S. Mills
A: 

What I haven't found yet in the posts is a clear distinction between tracing and logging. Think about e.g. why does almost every logging framework has an rolling(!) appender and tracing doesn't? IMHO tracing should be off in production environments and only turned on to trace things when something bad or not expected happens. Logging on the other hand is always on because I log only exceptions or code blocks with outputs of high interest and store the information. I would send the logging informations over the wire to a central point like a database where an application-admin has easy access to it to decide further steps taken or store them in the event log where the admin can also later collect them. I would also send an Email when logging exceptions or not so common states of the application like "almost" timeouts occur. Tracing on the other hand can go to a local textfile because an experienced technician immediatly tries to find out what happens in the application.

I use System.Diagnostics.Trace for tracing and log4net for loggin. Both weaved in with PostSharp

Shabbazz
+1  A: 

Hi, For asp.net projects I find that a combination of:

  • Trace.axd
  • Log4net - logging.apache.org/log4net/index.html
  • ELMAH - code.google.com/p/elmah/
  • PostSharp - www.postsharp.org/

Works great. Log4Net for the main logging engine. ELMAH for it's kick-ass auto logging and emailing. I use PostSharp to modify the details about the program flow for the namespaces that I am interested in knowing about, like if you want to be able to trace logic flow and spit out return and input values.

The combination of these allows me to garner as much detail as I want. Which really helps when trying to debug a problem.

Cheers, Lance

Lanceomagnifico
+3  A: 

haven't found a great one yet. Log4net is about 75% ok, but : -- it's not asynchronous, so you tie up cycles waiting for logs to write -- it really, reeeeaally sucks if you're using multi-threaded apps. It's more or less non-threadsafe. -- I'm having all kinds of issues running it on 64 bit and -- it's a pain to debug (not impossible, but I spend more time messing with log4net now than I do with business code).

I really don't understand why MS doesn't come out with one as part of .Net

Kevin
A: 

Try GIBRALTAR. Not only does it provide a non-blocking, threadsafe logging framework, it also includes a web service to collect logs and an analysis tool with extensive filtering and graphing capabilities.

Gibraltar combines benefits of ELMAH, log4net and perfmon and takes it to the next level.

Like ELMAH, Gibraltar reports errors and supports email notifications. Unlike ELMAH which only supports ASP.NET, Gibraltar works with any .NET application (services, WinForms, WPF, etc). It also includes all the events leading up to each error and can directly integrate with multiple defect tracking systems.

Like log4net, Gibraltar provides trace logging. In fact, Gibraltar can work with log4net and other logging frameworks. Unlike log4net, Gibraltar also gets the logs to your team from all the computers your application runs on and provides tools to analyze all that data.

Like Perfmon, Gibraltar collects and graphs Windows Performance Counters. Unlike perfmon, Gibraltar collects key metrics continuously in a compressed format and makes it easy to track application-specific metrics. In fact, you can log all calls to key methods including parameters and return values by simply tagging those methods with an attribute.

Gibraltar offers a free 30-day trial and deep discounts for multi-user license bundles. It's not free, but it is actively supported by a passionate, experienced team that really knows and cares about logging and application monitoring. Chat with us if you have questions.

Jay Cincotta
is Gibraltar free ?
ram
According to their website Single License is USD495 (http://www.gibraltarsoftware.com/Buy/Default.aspx) so its not a free solution, but the question doesn't indicate must be free so still valid choice.
Jafin
Yes, a single license is $495USD, but multi-user bundles quickly bring the per-developer cost down to about half that. And the data collection component is freely redistributable. You can monitor dozens of applications on thousands of computers at no additional cost.
Jay Cincotta
A: 

For those who are using log4net, I've made a simple console to display and filter the logs by configuring receivers (the same way you configure appenders).

I mainly use it with the .NET Remoting appender/receiver, both localy and remotely ; a lot of users are using it with the UDP appender/receiver also.

It's an open source tool developed in .NET, available on CodePlex: http://log2console.codeplex.com/

Statyk7
A: 

I am working on the trouble shooting of a huge application which did not use log4net. Then I came to know about log4PostSharp. Using this we can inject log4Net code without writing any code. Have a look into this. This might be quiet useful.

http://code.google.com/p/postsharp-user-plugins/wiki/Log4PostSharp

Amitabh
+1  A: 

I have been using Enterprise Library for quite some time now and all our projects used the same DB to log the information, it is easy to configure using editor. We have been using Email and Database as two trace listeners. All the critical bugs are directly emailed to us while rest of the stuff including all the auditing data goes to a centralized DB.

Whenever there is some issue, we have pre defined reports that runs on top of enterprise library database to pull out any reason. so i would suggest using Enterprise Library!

BT
A: 

I've been using NLog for a while now and for swear by it for simple projects.

It's follows the KISS mantra very well and for me that is a big plus. I think stuff like Log4Net, while great and not necessarily bloatware, is like a nerdy implementation of logging and as a result it tends to be used in apps that are themselves complicated or nerdy (or both lol).

I was actually writing a helper library to wrap the Debug and Trace classes that ship with the .NET Framework until I came across NLog, it does everything Log4Net does but with less fuss (I hate all the overly complicated config you have to do for Log4Net to get the thing to work).

For big projects however I do recommend the likes of Log4net as you get a whole raft of enterprise specific features that NLog doesn't have (and shouldn't as it sits perfectly well for the bedroom coder/lone developer).

Adios,

T

Kermit
@Kermit I would be curious to know some of the enterprise specific features that log4net has that NLog doesn't that would cause you to recommend log4net for big projects over NLog. My company is currently evaluating logging platforms and is looking at log4net and NLog, among others. Just from looking (I don't have any production experience with either platform), it isn't obvious that there are many significant differences between log4net and NLog. Thanks
wageoghe
+1  A: 

You might also want to take a look at our (commercial) .NET logging tool SmartInspect. The big difference compared to the available open source tools is that we ship a powerful monitor and log analysis tool with SmartInspect. If you have log files that exceed a few thousand entries, having a great log analysis tool is a big time-saver (especially if you work with multi-threaded, distributed or web applications).

SmartInspect also comes with log protocols and options not found in other tools and can be configured with just one line of code.

Dennis G.