----- Original Message -----
> On 02/13/2012 02:28 PM, Ayal Baron wrote:
> >
> ...
> >>> is that it (ab)uses an http header for carrying FlowID,
> >> Yes, it certainly does appear to overload it.  I would be nice to
> >> have
> >> something formal given to it by engine, but I can appreciate the
> >> difficulty implementing such a scheme.
> >
> > Technically I disagree, this is a cross cutting concern which has
> > nothing to do with any specific call hence it should be passed as
> > a header, that is actually rather elegant.
> >
> > To the specific matter at hand though. what would really be nice is
> > solving the real problem properly, and not contaminating the API
> > and the log with things which have marginal benefit if at all.
> going back to the 'grep' issue.
> vdsm logs are verbose. they are multi-threaded as well.
> I think this should be more than just about finding the entry point
> of
> the flow, then identifying for this specific log format how to trace
> it,
> which would require writing a log analyzer with plugins for each
> component.
> having all lines which are relevant to a flow with a flowid logged in
> them would make it much easier to get all (or most) of relevant parts
> of
> the flow (most, since something orthogonal to the flow may have
> happened
> affecting it, like loss of network)
I'm sorry but what you're proposing is to make the log even more difficult to 
read for absolutely NO reason.
I haven't seen 1 good reason to add more to the log.
What we should be focusing on is:
1. adding the relevant data that is needed to the engine log so that most of 
the time users wouldn't need to go the host
2. reducing the verbosity of the vdsm log and increasing readability (the flow 
ID does exactly the opposite).

As opposed to most people here who are thinking that this sounds like a good 
idea, I actually have debugged at least dozens of issues in engine and vdsm and 
can assure you that not once would this have been beneficial to me.
What was mostly missing in the engine logs was understanding what thread in 
engine called what operation in vdsm and what vdsm's response was.  In 3.0 my 
understanding is that engine fixed this so this entire feature will be counter 
productive (will make logs less readable and harder to decipher, adds 
complexity to the API and adds complexity to users of the rest API).
All cross hosts issues stem from *different* flows, so this would not help in 
this case and single host issues are easily traceable today (and you *never* 
need to follow an entire flow, it's entirely redundant and inefficient).

I'm more than willing to show this on any set of logs by the way and would be 
happy to be proven wrong.

More often than not by the way, the issue is that inside a specific call (i.e. 
1 verb, not a flow) people are not proficient in finding the offending line 
(which is why I wrote the 'how to read the vdsm log' wiki).
vdsm-devel mailing list

Reply via email to