Re: Logging problem
Novice wrote:
Arved Sandstrom wrote:
Novice wrote:
[ SNIP ]
It would be very helpful if someone could explain what would happen
in a real-world production situation where a long-running batch
program or a constantly-running online program started writing error
messages to the log. What will operators do to be able to read the
log? I'm guessing they force it to close early and then start a new
file or they have a tool that will read the log file correctly even
without the final </log> tag.
As mentioned, "tail" or "tail -f".
Or vi or emacs.
Or "less".
Or just about anything.
In a real-world production situation odds are you're getting errors
logged all the time. There are a whole bunch of errors that will
happen, sometimes frequently, sometimes a few times a day, sometimes
once a month, but you know they _will_ happen. So routine errors get
logged all the time.
I'm a little surprised by that. I would have thought actual errors would=
get acted on fairly quickly, particulary anything categorized as SEVERE.=
"Acted on quickly" means that it happened.
And he said "routine errors", not "SEVERE".
Have you looked at any real system's logs?
You should.
(I'll use the java.util.logging levels for these remarks.) I could see
that something that is categorized as WARNING may take longer to fix,
especially if WARNING is used for messages that indicate the program is=
able to continue using some kind of alternate strategy; if the alternate=
Not necessarily.
strategy is perfectly reasonable and doesn't skew the result, there's no=
great harm in leaving the problem unsolved. But if we assume that a
Way wrong. There's always harm in leaving a WARNING unresolved. Otherwise i=
t'd be reported at a lower level.
SEVERE error is a show-stopper, wouldn't that get dealt with right away?
It has to happen first, then it can be dealt with. Otherwise there's nothin=
g with which to deal.
As for how do ops support folks read ongoing stuff? Well, surely you
must have used 'tail',
I haven't worked on Unix/Linux in a while but I have used 'tail' ;-)
Frankly, I don't recall if it works on open files but from you've said,=
apparently it does.
"man tail"
GIYF.
If it didn't work on open files, "tail -f" would be pretty useless, now wou=
ldn't it?
or perhaps opened up a decent programming text
editor on a file that's being currently written to, or even just
looked at console output. Apart from some buffering going on (none,
That "console output" one should already be way familiar to you.
line or block), which really only determines if you see your stuff
immediately, very quickly or just quickly, fact is that what you're
logging shows up in your log file rapidly, and then you can read it -
there's no need to close the file.
Perfect. Existing tools that will read the file while still being written=
are what I was hoping for ;-)
Basic OS knowledge here. Nothing outr=E9 about reading a file while it's be=
ing written.
Programmers need to know more than the basics of OSes, let alone have gaps =
in the basics.
As Arne mentioned, a file will get closed when the log file is rolled
over for size and/or time, or because the entire application stopped.
But that's a different matter.
Indeed.
I've worked with several app servers that routinely log some files as
XML; I can't say it's ever occurred to me to take a peek at the XML as
text and see what state it's in during ongoing writing. These are
server logs, not application logs, so I don't usually have reason to.
I'm with Arne on not using XML logs yourself. There's no need for it.
Out in the wide world users of logs will thank you for not using XML.
You and Arne and Patricia have convinced me. XML isn't the way to go
after all, especially if it necessitates changing the way things get done=
- such as when logs get closed - or writing new tools to be able to read=
incomplete files just to be able to read XML logs. That means I can
remove the code that closes the handler from my program which strikes me=
as a a good thing ;-)
Well, this little mishap with the XML logs has been a good thing overall=
in that it's steered me away from a problematic approach and back towards=
something that follows established practice.
Thanks to everyone who contributed to the thread.
--
Lew