fvh> I would be happy if we had the choice, just as if you httpd would give
fvh> you the configurable output options that allow me to decide what to
fvh> log and what not (Hi roy:-), it would be ok with me is there were an
fvh> option te record the time in local or in gmt. everyadmin that decides
fvh> not log in GMT will no that the analyzer might run into problems, just
fvh> as if he decided not to log the name of the remote user, or whatever.
fvh> Tha's were the configurable output options are for, isn't it...
fvh> you can use them and create human readable output that contains all
fvh> the things you are interested in (and nothing more) (you can use
fvh> grep as you analyzer tool) or you don't use them and have some general
fvh> purpose analyzer read the log for you and produce out put in human
fvh> readable form (which might be local time!)
I agree with the need for choice. I've dealt with monitoring system
logs and sometimes these were read by humans and sometimes by
analyzers. The former prefer to see information in string form in
local time, whereas statistics were better handled by using an epoch
timestamp (especially around the daylight savings switchovers). The
solution I used was to have the first field be the Unix timestamp in
UTC, and to record the pretty human-readable stuff after it.
Sure it's possible to go from the string format back to a timestamp,
but it's not a pretty conversion and most Unixes don't have routines
to do this. There's no need to do the conversion if the administrator
can choose to have a time stamp (for whatever zone) as well as any
additionally formatting information.
If the analyzers require a fixed format, I would hope it's one which
is easily created via preprocessing (awk, sed) of the log file.
michael