3

I've worked different kind of applications both having centralized and decentralized logging mechanisms.

I feel centralized logging mechanism is good to see the proper flow of code and timing of executions while debugging problems. Most of the implementations will have small fixed file size for easily narrowing down the problem. But if the number of components is too high within the system I feel the log directory will get exhausted with huge number of files. Is it a good idea to employ decentralized (module-wise) logging mechanisms in such situations? What are the pros and cons of the same?

Improve this question
2
  • 1
    What do you mean by decentralized logging? That modules use their own logging mechanism, or save their logs in different locations? You can have a central logging mechanism that modules hook into but still log to the same file.
    – fejd
    Jul 26, 2011 at 14:33
  • Try an external service such as datadoghq.com
    – Job
    Jul 26, 2011 at 20:28

2 Answers 2

Reset to default
2

A logging solution must be designed to make it as easy as possible to find the source of issues, while at the same time providing the depth needed to isolate and track hard to find bugs.

Logging to a single file makes it fairly easy to get an understanding of the entire system, but can easily be overwhelmed with too much detail. Modularized logging reduces the amount of noise, as you can investigate each module independently, but makes it harder to get an understanding of the complete system. These are two trades offs.

In addition the level of your logging has an effect as well. If you are only logging at the WARNING, ERROR or FATAL level a single log is much easier to understand, while if you are logging at DEBUG level, modularized logging may make more sense as the amount of detail a DEBUG level log can generate can be overwhelming.

To me though it sounds like you may have run into the limits of file based logging, perhaps you would be better of logging to a database. You don't mention what logging framework you are using (log4j, log4net), but many frameworks allow you to go beyond file based logging. The benefit of logging to a database is that you are able to use SQL queries to isolate the information in a much more granular way then by looking in individual files.

Additionally you may wish to look at logging visualization tools for your particular framework. Rather then simply opening up a file in notepad, some tools can allow you to easily filter and get a better understanding of any issues.

As for best practices I think its clear, for small amounts of logging start of with a single file. As that file becomes overwhelming move to a modularized system, and when that is no longer sufficient move to a database sink.

Improve this answer
2
  • Thank you for the detailed reply. Querying from DB is quite easy. But most of the time the logs are helpful while we deploy to customers. Communicating with the dev team mostly requires a file. So if we adopt the DB based logging, then we will have to make some handy tools to pull the information out from DB.
    – sarat
    Jul 27, 2011 at 7:54
  • 1
    Some logging frame works support SQL Lite. If you use this, there would be no difference between having a client send you a log file compared to having a client send you the SQL Lite Database file. Your point is well made though, setting up a log sink for SQL server or Oracle on a client site may not be possible, and sending data to you will be much harder.
    – Robert Anton Reese
    Jul 27, 2011 at 8:22
3

Currently a decentralized logging has bit me in the backside, as the number of logs grew up, complexity of errors increased and suddenly when a fault happens you get a flood that only 2 people on this planet can interprete and read - and this is a device to be sold to customers who have no clue about it.

So, aggregate the logs and use some Event Correlator to get the essence out of them. With too many logs all over the system you will know every smallest detail but you will completely lose the big image.

Improve this answer
2
  • The additional overhead we are going to face with single file logging is the performance hit on synchronizing the file access between multiple modules. Sometimes, the logging must have a wait.
    – sarat
    Jul 27, 2011 at 7:55
  • @sarat: yes, logs are queued/cached in RAM as they arrive and dumped to disk in sequence as the write speed allows. Additionally (few) events that may result in a crash are written immediately to a separate file, so if a crash prevents writing the log cache, we still get a clue what happened.
    – SF.
    Jul 27, 2011 at 8:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.