2015-01-13 16:25 GMT-03:00 Atlas <e...@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
