On Mon, Feb 13, 2012 at 12:06:46PM -0500, Ayal Baron wrote: > > > ----- 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.
When I debug an Engine-related issue, I tend to find a silly API call in Vdsm. Then I have to start correlating this to Engine logs. This step can be made quicker and less error-prone by logging FlowID both Engine and Vdsm. To me, this is the 1 good reason for logging FlowID on API entry in Vdsm. However, I find adding FlowID to each and every log line a bit excessive. Our log is too cluttered as it is. Logging FlowID whenever a new thread is spawned makes more sense 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 email@example.com https://fedorahosted.org/mailman/listinfo/vdsm-devel