Best Practices For Creating a Log Writer for errors

Question

Hey S.O Guys

I have recently been doing some work that has been quite in depth, i was wondering what you think is better for logging. Is it better to.

A. Every time i want to write to my log, open the file, write to it then close it straight away so it there is no real chance of losing information in the case of a critical failure or crash.

B. Save periodically, maybe after every major section has been finished meaning i can narrow downs where the errors are.

Any other suggestions?? I don't want to be opening and saving all day with the large volume of text i need to record, but i don't want to lose my granularity of the information. I am writing in C++, sorry for not mentioning it prior.

Answer 1

I recommend the Log for C++ (log4cpp) that have good tools.

Answer 2

To my knowledge, it's fairly common (mandated?) for a stream flush to be the equivalent to saving.

That is, when you say:

file.flush();

Everything waiting to be written is written. Note that std::endl; also calls flush. So, leave it open and just flush after a dump of information.

Answer 3

On Unix systems, you have something called syslog (which is incidentally both a library call, together with openlog and closelog, and a service). In Windows I believe there's the Event log, don't know the API for that one though.

Anyway, since syslog (and the event log in windows) is logged to through IPC (sometimes even remotely over the network), the process is decoupled and won't be affected by your program crashing. That way you'll also dump the responsibility of saving the file to the syslog service. Note that this includes stuff like logrotation and compression of logfiles, as well as giving you the chance to use standardized tools for evaluating said logfiles (e.g. IDS).

Now, that said, the SYSTEM crashing (power failure, or whatever) is a totally different story, I don't know if that's your concern though, if you'd care to elaborate a little bit on what kind of system you're working on, it might be easier to suggest something more fitting.

Answer 4

The best solution is to use an existing library for that. There are many good, well tested and popular libraries out there. They usually give you all the versatility you need and save you the headache of managing files. Moreover they allow you to save your logs to various targets and not necessarily files. I used Google Log Library and ACE:

• glog
• ACE

ACE is a big library and logging is only a small part of it, so if you need only the logging, maybe it's not a good option. Anyway, don't try to implement logging yourself, save the effort for something more useful; unless, of course, you have a specific interest in logging engines.

Answer 5

A. Every time i want to write to my log, open the file, write to it then close it straight away so it there is no real chance of losing information in the case of a critical failure or crash.

B. Save periodically, maybe after every major section has been finished meaning i can narrow downs where the errors are.

Any other suggestions??

Just rack your brain a little longer -- you'll come up with dozens of other ideas. The problem is writing a logger can be made as complex as you want to -- loggers can become full-fledged pieces of software by themselves.

Here's an article I quite liked on the design of logger classes. Take a look.

If you are not willing to/don't have the bandwidth to support the creation of a new module for logging, go for an existing library as others have already suggested.

How do you choose the right library? The thing that you really ought to worry about is what sort of logs do you want and the stage of development you are in. Sort your messages and see if the library supports classifying them in a clear and consistent manner. Do you need multiple sinks for your messages? Does your library support that? If your code is in production you will have to worry a bit more. Do you need a transactional log system? Do you need atomicity of operations (and hence logs)? Do you need the ability to rollback messages?

Hope this helps.