Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4497

Re: analysis of java application logs

Show all headers | View raw

On 11-05-23 04:02 PM, Lew wrote:
> On 05/23/2011 01:16 PM, Daniele Futtorovic wrote:
>> On 23/05/2011 15:11, Lew allegedly wrote:
>>> Ulrich Scholz wrote:
>>>> I'm looking for an approach to the problem of analyzing application
>>>> log files.
>>>>
>>>> I need to analyse Java log files from applications (i.e., not logs of
>>>> web servers). These logs contain Java exceptions, thread dumps, and
>>>> free-form log4j messages issued by log statements inserted by
>>>> programmers during development. Right now, these man-made log entries
>>>> do not have any specific format.
>>>>
>>>> What I'm looking for is a tool and/or strategy that supports in lexing/
>>>> parsing, tagging, and analysing the log entries. Because there is only
>>>> little defined syntax and grammar - and because you might not know
>>>> what you are looking for - the task requires the quick issuing of
>>>> queries against the log data base. Some sort of visualization would be
>>>> nice, too.
>>>>
>>>> Pointers to existing tools and approaches as well as appropriate tools/
>>>> algorithms to develop the required system would be welcome.
>>>
>>> It helps if you have a logging strategy that mandates a consistent
>>> logging format, specific information in particular positions or marked
>>> by particular markup, logging levels and other such so that your
>>> analysis tool isn't faced with a completely open-ended input. What you
>>> describe requires a general text-analysis approach, as you indicate that
>>> you can make no guarantees about the format. Based on that, your best
>>> tool is "less" or equivalent text-file reader.
>>>
>>> What is a tool supposed to do, read your mind?
>>>
>>> It's really hard to extract information from a garbage can where people
>>> just randomly dumped whatever they individually felt like dumping
>>> without regard for operational needs. You can't build a skyscraper on a
>>> bad foundation, and you can't build a good log analysis off a crappy
>>> log.
>>>
>>> Fix the logging system, then the analysis problem will be tractable.
>>
>> I would argue around the same lines.
>>
>> 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.
> 
General agreement with all. I also am coming off one particular project
where part of the work - not a major part, but an important part - was
to improve logging. One of the first things we did was officially
recognize that we had many different clients of logging output. They
wanted different things at different levels at different times with
different storage stipulations.

The solution was pretty simple, and it's dynamic. I don't propose to get
into a logging framework war, but in this case we saw that JUL wouldn't
cut it, but log4j would do the trick. We had to do some arcane app
server-related stuff for JMX and log4j.xml, also integrate exception
handling with various "global" handlers that could also log, and wrap
log4j calls with a plethora of methods that would result in messages
formatted to our liking, but after that the heavy lifting was and is
done: it's now up to the clients - *not* to the developers - to request
what gets logged and in what manner.

Developers of course are clients themselves.

Again, not to get into a logging framework war, but for these purposes
log4j brings a lot to the table. It's common to need logging on specific
Java packages to be at a certain level, for output of that specific
logging to go to a specific target (like its own file) and have its own
storage policy, and for that logging to not be (or be, as the case
demands) to be additive to parent logging. Being able to do this is a
minimum for supporting different clients.

We also added, as part of our log4j method wrappers, an extra field for
all log messages that characterizes a "functional category". This allows
decorating all messages with information as to the identity of a
functional subsystem, and is helpful to post-processing tools like Splunk.

This system has been in production now for about 4 months, and
operational support staff and other clients are very pleased with it.
It's not perfect, because not all the log statements exist in the code
to support every informational requirement (known or unknown), but the
framework is not a problem.

One sidenote: despite doing everything I describe above, you can still
end up with logs that are difficult to interpret, and more log
statements aren't necessarily the answer. This typically happens when
your code itself is a spaghetti tangle. Sometimes to fix a logging
problem you really do need to refactor your logged code.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

analysis of java application logs Ulrich Scholz <d7@thispla.net> - 2011-05-23 00:50 -0700
  Re: analysis of java application logs Robert Klemme <shortcutter@googlemail.com> - 2011-05-23 02:20 -0700
  Re: analysis of java application logs jlp <jlp@jlp.com> - 2011-05-23 11:45 +0200
  Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 09:11 -0400
    Re: analysis of java application logs Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-23 19:16 +0200
      Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 15:02 -0400
        Re: analysis of java application logs Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-23 22:03 +0200
          Re: analysis of java application logs Michael Wojcik <mwojcik@newsguy.com> - 2011-05-26 14:43 -0400
        Re: analysis of java application logs Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-23 18:32 -0300
          Re: analysis of java application logs Ulrich Scholz <d7@thispla.net> - 2011-05-25 06:00 -0700
            Re: analysis of java application logs Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-25 19:04 -0300
        Re: analysis of java application logs Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-23 22:25 +0000
          Re: analysis of java application logs Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-24 12:26 +0100
            Re: analysis of java application logs Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-24 12:29 +0000
              Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-24 08:49 -0400
                Re: analysis of java application logs Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-24 14:37 +0000
                Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-24 12:26 -0400
                Re: analysis of java application logs Jim Gibson <jimsgibson@gmail.com> - 2011-05-24 11:00 -0700
                Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-24 14:35 -0400
                Re: analysis of java application logs Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-25 09:53 +0100
            Re: analysis of java application logs Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-24 19:12 +0200
  Re: analysis of java application logs Patricia Shanahan <pats@acm.org> - 2011-05-23 06:17 -0700
    Re: analysis of java application logs Robert Klemme <shortcutter@googlemail.com> - 2011-05-23 20:33 +0200
      Re: analysis of java application logs Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-23 19:07 +0000
  Re: analysis of java application logs CncShipper <anon@nowhere.com> - 2011-05-23 14:56 +0000
    Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 11:43 -0400
      Re: analysis of java application logs jlp <jlp@jlp.com> - 2011-05-23 18:00 +0200
        Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 12:20 -0400
          Re: analysis of java application logs Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-23 19:06 +0200
            Re: analysis of java application logs Robert Klemme <shortcutter@googlemail.com> - 2011-05-23 20:27 +0200
              Re: analysis of java application logs Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-23 21:02 +0200
              Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 15:06 -0400
                Re: analysis of java application logs Robert Klemme <shortcutter@googlemail.com> - 2011-05-23 22:10 +0200
                Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-23 17:04 -0400
  Re: analysis of java application logs Tom Anderson <twic@urchin.earth.li> - 2011-05-24 15:04 +0100
    Re: analysis of java application logs Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-24 14:50 +0000
      Re: analysis of java application logs Michael Wojcik <mwojcik@newsguy.com> - 2011-05-26 14:58 -0400
      Re: analysis of java application logs Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 16:23 +1200
        Re: analysis of java application logs Lew <noone@lewscanon.com> - 2011-05-30 01:08 -0400

csiph-web