Re: The usefulness of application logging
apm35@student.open.ac.uk wrote:
kanze wrote:
apm35@student.open.ac.uk wrote:
I use logging as a diagnostic trace aid during development.
But I leave the logging code in when I deploy to production.
Even if the problem is reproduceable on the production machine,
it may depend on the environment, and not be reproduceable on
your machine. So you want to be able to turn on full logging on
the production machine, in order to find the problem.
Basically, I'd say that if you won't be able to get at the logs
from deployed programs, use classical asserts and logging which
can be compiled out. Anytime you can get at log files from
deployed code, however, it would be foolish to not take
advantage of this. Unless the profilers says otherwise, of
course:-).
Thanks James. This is very similar to the view I hold. How
pleasant it is to find agreement.
I suspect that you'll find agreement from anyone who has worked
on large projects where there was access to the deployed
programs. In all of the projects I've worked on, I've never had
to argue for, or even suggest logging. It has always been
assumed by everyone involved that there would be some logging.
It seems to be pretty much of an established engineering
principle.
I would add that whilst I leave the logging in the production
version there is a way to turn it off and it is off by
default. Where this can't easily be done (e.g the logger isn't
good enough) then I arrange is so that the logging is still
present in the development version (a compile-time switch
makes the logging calls no-ops for production) then I try to
find the problem in development. If it only occurs in
production where no light can be shed then, ahem, I am in
trouble.... :-(
In all of the larger projects I've been involved in, logging has
been configured by means of a multi-line file, where each line
specifies the subsystems and the logging levels concerned, and
where to log to: a file, syslog, email... There has also been a
means of triggering the reconfiguration dynamically, without
stopping the system.
Designing such a system isn't that hard, but it could be
overkill for smaller projects. All systems I've worked on,
however, have had multi-level logs, with a configurable log
level, and at least minimum logging active at all times. (But
all of the projects I've worked on have either been in house, or
for a single client with whom we had a priviledged
relationship---enough so that we could modify the configuration
files on his systems. Also, the projects have had very strict
quality requirements: contractual penalties for downtime, etc.)
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]