revisiting a few topics from an old post, I was reminded today about some of the things that can make or break a project, that some thought at the start can alleviate much suffering.
Things your logging system needs to do:
- be dynamic - you must be able to change logging levels on the fly without stopping any processes
- be granular - you need to be able to segregate the severity of the log messages, so that you can eliminate detail as necessary (more on this below)
- be muxable - you need to be able to route log messages to multiple different sinks - syslog, files, another server, etc
- have a strong locality to the messages - know where they come from - process. thread. date. time. function, etc.
- be compact - have your configuration be in one place, a file or a DB
- be dynamic, unless absolutely impossible - you want to be able to change config on a running process.
- be contained in one function, so that if you trigger a reconfig, only one call needs to be made.
- be configuration-driven - you don't want to require a rebuild to enable a feature.
- use the Factory pattern, and feature flags to drive it - so you can have one code stream.
- have a single code interface to determine if something is in use - do not have an "enabled" function and a "licensed" function and an environment variable to set things.
One logging idea that I have not yet fully fleshed out is a class-based logging - where every class has a logging flag that can be set so that you can log everything that instances of a given class does.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
