To Log Or To Not Log?

I'm now building a program that is a eBook manager, reader, organizer and publisher, that is also a eBook transfer(to eReaders like Kindle), but I was developing it and a question have poped-up on my mind: "Log or not?"

Then I started to think about logging. As many programs log actions, I started to seek for they and see how they log things, then I want to know:

• It's good to log actions or things that happend in programs(like errors)?
• In my case, it's good to log things?
  • What I need to log?
• What is the best wa开发者_Python百科y to log things(text files, databases...)?
• There is any tool to logging for Lazarus?

It's essential. Log

1. all errors with related data (method args etc.). Otherwise you're going to have a range of bug-related behaviours that you can't analyse.
2. key entry and exit points (what's your program doing? Should it be calling these methods at this point?)
3. possible time consuming methods/operations (entry and exit), so you can measure what's going on and know what your program is doing/where it is.
4. where you're loading configurations from, if applicable. This means you can tell how your program is configuring itself (which config is it using?)

If you get this right, you may find you spend less and less time in the debugger.

I would err on logging more rather than little, and removing or filtering if/when this becomes a problem (as noted below, logging Gbs per day is probably counterproductive). I've worked on numerous systems where it's been decreed that logging will be turned down or removed post development, and this never occurs, since it's so useful. Some people object to logging on the basis that it affects performance. If this is the case, remove it when it's known to be a problem, not before.

You should be able to find suitable frameworks for logging (e.g. log4c for C, log4j for Java) for your particular platform that allow appropriate filtering and destination selection. That means you can log to files (and restrict log sizes), databases, remote monitors etc. and change this decision on the fly (via a configuration file or command-line arguments). The right framework should require very little initially other than your inserting appropriate logging statements. You shouldn't have to write much in the way of file management or other log management code.

Here's a useful blog entry on this subject, with further guidelines.

Logging is essential and useful. Why? For tracing purposes. As long as you develop on a local machine, you can quickly debug, set breakpoints and figure out where things go wrong. Once you then deploy in production your customer will phone you, telling that he didn't see what he expected to (an error message appeared somewhere). Trust me, you will have a hard time figuring out what happened if you don't have logs.

Hmm...Brian's answer just popped in saying basically where I wanted to continue :)

Anyway, you may consider also some Aspect Oriented techniques. They're pretty suited for logging purposes and you keep your code clean. May be an option for your project.

Regarding the type of logging: I usually work just fine with plain text files (with a certain max size), unless you have to keep track about all of your user's activities (legal reasons, whatever). In such a case a DB log would probably be more appropriate.

In the first phases of component development log everything. Usually I do all of my development on the console that way I can see all of my logic being output line by line if need be. As you move forward logging errors is always a must and logging values after complex data manipulation can be helpful as well. Think of military disasters due to rounding floats off to soon.

I recommend logging to a flat file over the database.

Definetly log errors to flat files consistently formatted so that you can retreive them from your customer and read them into excel or a db for analysis if needed.

This is a very general question... For starters, I'd say you should have several logging levels. On the trace level, log everything you have in mind. On the errors level, have only sever errors logged. Make it possible to choose logging level on runtime, though the selection should not be available for end users. Also, have in mind that if you make your logs available to people other than you (your support team, for example), make sure your messages are human readable and not something only you can understand.

There are a lot of logging infrastructures, look around to see what fits your development environment. It might be easier to use a well tested infrastructure than invent something of your own.

• It's good to log actions or things that happend in programs(like errors)?

Yes, you always need to have a way to find our whats wrong. You should also classify them, so you can later turn off logging for a certain class of log messages (e.g. while developing you want to have debug messages; after you shipped your app, you only care for errors and warnings).

• In my case, it's good to log things?

see above.

      o What I need to log?

• Every Error (app/function does not work)
• Every Warning (app/function still work, but it is worth keeping a record of it)
• Information (something nice to have)
• Debug (stuff that only a developer cares about)

With ever class you should also log relevant data.

• What is the best way to log things(text files, databases...)?

I prefer files, since they are easy to read and can be shared easily with others. But as long as you can access the logs the medium is the smaller problem.

I would recommend to use a logging framework, since logging is an essential part of your app and way to many people already came up with pretty good solutions. This way you don't invent the wheel over and over again and you have more time developing your app.

Logging is always essential, because there may be errors that occur in production and information needs to be output about what happened.

Apart from errors, however, whether you log key entry and exit points, possible time consuming methods/operations etc. is dependent on the applicatoin and environment. If you don't have performance analysis built into your system, then you either need to log, or be able to turn on detailed logging, in order to track down performance issues.

Similarly, if you don't have real-time debugging tools, you need to log, or be able to turn on logging, for key entry/exit points.

If the system is handling millions of transactions, each with millions of operations, then you don't want to have this level of logging on all the time on every subsystem/process, otherwise your application quickly fills up all available diskspace - that's an issue.

For small, simple systems, it is probably sufficient to have a general default level of logging for production, and a debug level for tracking down problems.

Logging during development doesn't really matter--do it if it helps; stop doing it when it stops helping.

Good logs become important during production. List the kinds of problems you'll run into and log the information you need to solve those problems. Will you be sued for copyright infringement? Then log what you need to defend yourself. Will people report bugs with their readers and ask for help? Then log what you need to answer the questions and minimize your support costs.

It's easy to log too much (useless) information. If you don't need it, don't log it. Will servers fail? Will networks fail? Will you run out of storage? Yes, and you can log to help diagnose those problems, but that's mainly a job for monitoring, not logging.

Syslog provides pretty good management and centralized control. There are many logging frameworks that work about the same--it's really personal preference which one you use. I use a structured, searchable log format on top of syslog. All ad hoc development logging is removed before going live.