hernanmd wrote
> That depends in what you want to interpret. A log entry format is
> something
> you invent for your system. For log analysis you don't usually write a
> parser, you can just grep over
> the output to see why things didn't worked.
> Or you may use one of the tools for output analysis.

Provided that the parts of the system *I* am interested in have been
enriched with logging code. And provided the log messages are informative --
and that's a highly subjective matter.
Also, different users and developers might have different opinions as to
which parts of the system to instrument.
(Of course, I could use an aspect weaver to do instrumentation, but that's a
rather indirect way to address the problem)


hernanmd wrote
> Exactly, you define the meaning of INFO for your system. There should not
> be just one conception of INFO.

I might define what INFO means for my system from *my *point of view, but
there might be many other different viewpoints. How can these be
incorporated, if the decisions what and how to log and how are determined by
someone else?

hernanmd wrote
> The point is isn't just me. I haven't seen any intensive computation
> software which creates log objects for self-exploration. And if you find
> one, I could cite 100 of them which does "String logging", and they just
> work, and people using it is not stupid, they know they have limitations,
> it happens that they prioritize other requirements.

They should prioritize other requirements, yes. There should be no need to
write (much) logging code.

In an object-oriented system, I am interested
about the information flow / messages between objects.

With hierarchical
decomposition, I can zoom in and out, see the messages and their effects,
which in my opinion, is a more holistic perspective on system analysis.

With grep, I would have to reconstruct this information (caller graph, state
changes etc.) from the logs or use a tool which only works if the log
messages follow a specific format (and these formats might change).

Of course, I am not saying that string messages are useless and cannot be
informative, but they cover only one aspect of the problem.


hernanmd wrote
> I see. In the end we (still) read Strings, whatever conceptualization is
> above them.

This rests on the assumption that the string and/or strings from related log
messages carry enough information (and additional context) to infer the
concepts.