Tracing versus Logging and how does log4net fit in

问题:

I am wondering about what the difference between logging and tracing is.

Is the difference basically that tracing is more detailed log giving developers a tool to debug applications at runtime?

I have been experimenting with log4net and doing logging. Now I am wondering if I should be doing tracing as well and if I could/should use log4net for that purpose. Should I be doing tracing with log4net and is there some trace level for log4net loggers? Should I use a different log level for debug and trace purposes or is it ok to use the same? Can you give a simple example on how I would do logging and tracing for a simple method?

Edit: Despite a few helpful answers below I am still unsure how I should be doing tracing versus logging.

I have the following method in my Business layer and I want to add logging/tracing to it. I am wondering how to do it efficiently. Is the following method acceptable in terms of logging/tracing? Should the log messages be of type Info instead of Debug? Are the Debug messages I am logging considered trace? How would you change it?

IEnumerable<Car> GetCars()
{
   try
   {
      logger.Debug("Getting cars");
      IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter);
      logger.Debug("Got total of " + cars.Count + " cars"); 
   } catch (Exception e) {
      logger.Error("Error when getting cars", e);
      throw new Exception("Unexpected error when getting cars");
   }
}

回答1:

Logging is the generic term for recording information - tracing is the specific form of logging used to debug.

In .NET the System.Diagnostics.Trace and System.Diagnostics.Debug objects allow simple logging to a number of "event listeners" that you can configure in app.config. You can also use TraceSwitches to configure and filter (between errors and info levels, for instance).

private void TestMethod(string x)
{
    if(x.Length> 10)
    {
        Trace.Write("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

In ASP.NET, there is a special version of Trace (System.Web.TraceContext) will writes to the bottom of the ASP page or Trace.axd. In ASP.NET 2+, there is also a fuller logging framework called Health Monitoring.

Log4Net is a richer and more flexible way of tracing or logging than the in-built Trace, or even ASP Health Monitoring. Like Diagnostics.Trace you configure event listeners ("appenders") in config. For simple tracing, the use is simple like the inbuilt Trace. The decision to use Log4Net is whether you have more complicated requirements.

private void TestMethod(string x)
{
    Log.Info("String length is " + x.Length);
    if(x.Length> 10)
    {
        Log.Error("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

回答2:

IMO...

Logging should not be designed for development debugging (but it inevitably gets used that way)
Logging should be designed for operational monitoring and trouble-shooting -- this is its raison d’être.

Tracing should be designed for development debugging & performance tuning. If available in the field, it can be use for really low-level operational trouble-shooting, but that is not its main purpose

Given this, the most successful approaches I've seen (and designed/implemented) in the past do not combine the two together. Better to keep the two tools separate, each doing one job as well as possible.

回答3:

log4net is well suited for both. We differentiate between logging that's useful for post-release diagnostics and "tracing" for development purposes by using the DEBUG logging level. Specifically, developers log their tracing output (things that are only of interest during development) using Debug(). Our development configuration sets the Level to DEBUG:

<root>
        <level value="DEBUG" />
        ...
</root>

Before the product is released, the level is changed to "INFO":

<level value="INFO" />

This removes all DEBUG output from the release logging but keeps INFO/WARN/ERROR.

There are other log4net tools, like filters, hierarchical (by namespace) logging, multiple targets, etc., by we've found the above simple method quite effective.

回答4:

Logging is not Tracing. These two should be different libraries with different performance characteristics. In fact I have written one tracing library by myself with the unique property that it can trace automatically the exception when the method with tracing enabled is left with an exception. Besides this it is possible to resolve in an elegant way the problem to trigger exceptions in specific places in your code.

回答5:

I'd say yes. Logging is the only way to determine what happened in the past - if a customer calls and says something didn't happen as expected, without a log all you can do is shrug and try and reproduce the error. Sometimes that is impossible (depending on the complexity of the software and the reliance on customer data).

There is also the question of logging for auditing, a log file can be written containing information on what the user is doing - so you can use that to narrow down the possibilities to debug a problem, or even to verify the user's claims (if you get a report that the system is broken, xyz didn't happen, you can look in the logs to find out the operator failed to start the process, or didn't click the right option to make it work)

Then there's logging for reporting, which is what most people think logging is for.

If you can tailor the log output then put everything in logs and reduce or increase the amount of data that gets written. If you can change the output level dynamically then that's perfect.

You can use any means of writing logs, subject to performance issues. I find appending to a text file is the best, most portable, easiest to view, and (very importantly) easiest to retrieve when you need it.

回答6:

logging != debugging

Sometimes keeping log files is necessary to solve issues with the client, they prove what happened on the server side.

回答7:

Also, consider what information is logged or traced. This is especially true for senstive information.

For example, while it may be generally OK to log an error stating

"User 'X' attempted to access but was rejected because of a wrong password",

it is not OK to log an error stating

"User 'X' attempted to access but was rejected because the password 'secret' is not correct."

It might be acceptable to write such senstive information to a trace file (and warn the customer/user about that fact by "some means" before you ask him to enable trace for extended troubleshooting in production). However for logging, I always have it as a policy that such senstive information is never to be written (i.e. levels INFO and above in log4net speak).

This must be enforced and checked by code reviews, of course.