Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!news.davenulle.org!noc.nerim.net!nerim.net!proxad.net!feeder1-2.proxad.net!193.252.117.184.MISMATCH!feeder.news.orange.fr!not-for-mail Date: Mon, 23 May 2011 18:00:20 +0200 From: jlp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: analysis of java application logs References: <8AuCp.7606$Mk4.5295@unlimited.newshosting.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Lines: 22 Message-ID: <4dda8490$0$14657$ba4acef3@reader.news.orange.fr> Organization: les newsgroups par Orange NNTP-Posting-Date: 23 May 2011 18:00:16 CEST NNTP-Posting-Host: 86.217.228.79 X-Trace: 1306166416 reader.news.orange.fr 14657 86.217.228.79:8427 X-Complaints-To: abuse@orange.fr Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4465 Le 23/05/2011 17:43, Lew a écrit : [SNIP] > You have made an important and useful point. Covering for a bad log > format is a freeform-text parsing problem, inherently difficult and > heuristic and probably never perfect. I wonder if your effort would have > been better spent converting to a log format that is parser-friendly, as > the OP should do. > I agree with you, Lee, it is what i did with my own tool. Native logs are converted in CSV files. But some logs are not simple to convert : - java exceptions - java threads dumps ( different for every JVM : Sun/Oracle, JRockit, IBM ...) - java heap dump summary ( same remark) - verbose GC logs (same remark) - multi-lines log enregistrement (xml logs ...) Others are more simple : - acces logs that are Common Log Format ( CLF) or CLF extended compliant ( Apache, Tomcat, IIS, WebLogic, Websphere ...) - Log4J