2015-01-13 16:25 GMT-03:00 Atlas <erde@chello.at>:
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?
But that's what developement cycles and peer-review suppose to provide, a feedback system where you reach consensus through subjective modeling.
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.
Agree
In an object-oriented system, I am interested about the information flow / messages between objects.
While you may log objects information flows, I have seen people often use specialized tracers and samplers.
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.
Agree, but maybe that's a requirement for software re-engineering or code analysis which doesn't apply to whole domains of applications.
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.
Sure, why one shouldn't include all the necessary information? Unless you're instrumenting legacy system or auditing... Cheers, Hernán