Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: analysis of java application logs Date: Mon, 23 May 2011 22:03:03 +0200 Organization: A noiseless patient Spider Lines: 36 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 23 May 2011 20:03:02 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="cJU7nYzGCfw0pKQCnryarg"; logging-data="23707"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LIfVTRmHXawfdYM41uCwl" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:afB1e+ofIYtB45y9mYb+5TsLkKc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4490 On 23/05/2011 21:02, Lew allegedly wrote: > On 05/23/2011 01:16 PM, Daniele Futtorovic wrote: >> I've been faced a while ago with a situation where some orthogonal >> organisational unit wanted to exploit my logs. I told them to GTFO. >> >> My logs are my logs. I put in it what I consider necessary. I often >> improve them as I step through the code. I might change the message, fix >> the level, &c. I don't want to have them set in stone. Neither do I >> generally have enough confidence in them to allow them to be used for >> analysis. >> >> "The solution, then, is simple", I told them, "spec out the exact >> messages and arguments you want, and the exact situations you want them >> logged in, and I'll add them for you. But leave me my precious debugging >> logs." >> >> 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'd call it (what I described): audit logging. I don't know if the meaning of that term normally extends beyond databases, but I don't see why it shouldn't. -- DF. An escaped convict once said to me: "Alcatraz is the place to be"