Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: analysis of java application logs Date: Mon, 23 May 2011 22:25:38 +0000 (UTC) Organization: UK Free Software Network Lines: 37 Message-ID: References: NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1306189538 30836 84.45.235.129 (23 May 2011 22:25:38 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Mon, 23 May 2011 22:25:38 +0000 (UTC) User-Agent: Pan/0.133 (House of Butterflies) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4499 On Mon, 23 May 2011 15:02:23 -0400, Lew wrote: > On 05/23/2011 01:16 PM, Daniele Futtorovic wrote: >> Let me emphasize: IMHO debugging logs and logs for analysis are two >> different things and should be kept strictly separated -- possibly >> logged to a different target respectively. > > That last is rather a brilliant idea, to use different targets. > Heretofore I've espoused that logs are primarily an operations tool, not > a debugging tool, although in service of the former they inevitably and > inherently must support the former. The problem I've always seen is > that logging statements are left up to the programmer, and not specified > for the project. > I tend to use at least two logging streams: debugging and operational. I leave debugging statements in production code: its normally off (of course) but can be turned on if needed. Operational debugging includes informational and error messages to be used by sysadmins which are always enabled and should be fairly infrequent as well as performance measurement messages. The latter can be configured on or off. As others have said, the messages need to be designed with both log stream selection and ease of parsing for later analysis in mind. In a C application for a *NIX OS its easiest to send all these messages to the system logger and let it deal with creating separate logs for the various message streams: its then trivial to use 'tail' to present the operational stream to sysadmins. If the application is written in a language that doesn't provide easy access to the system logger or is run on an OS that doesn't have one, I'd include a custom logging process as part of the application. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |