2016-12-08 14:24 GMT+01:00 Andrey Redko <[email protected]>: > Right, it looks like really light version of tracing, which essentially > allows to figure out which service/host is the problem. I am not sure how > useful it could be in practice, and there is a large overlap with logging > in this case. > > - light: sure - overlap with logging: no. Of course it ends up in a log (or aggregator or even other kind of storage) but the point is not "where to put it" but "where to take the data from". Whatever logging system you use you will never get the full tracing if you dont handle it and the point of the code is just to maintain the value and make it available for logging or other (a request header works well there) - how useful: if you have zipkin it is useless, if you have anything else (including an aggregator) it saves time and allows some auto-analysis to be in place saving time for not that rare but easy errors
Personally I see it as a kind of level 0 of analysis but surprisingly if you compare the light vs powerful solutions, the light solves a lot of cases in a simpler manner (Pareto?). > On Thu, Dec 8, 2016 at 2:13 AM, Romain Manni-Bucau <[email protected]> > wrote: > > > 2016-12-08 9:10 GMT+01:00 Christian Schneider <[email protected]>: > > > > > The new logging support in rt/features/logging already creates exchange > > id > > > and message id. It also allows to send the message id over the wire. > > > I have already fed the data into elastic search. There I was able to > > > correlate request to reply and request sent out from the client to > > request > > > received on the server. > > > > > > Would that already work? > > > > > > See http://cxf.apache.org/docs/message-logging.html > > > > > > > > It is closer to zipkin I think. The point of the previous solution is to > > "pre-stack" (pre-compute) the data to have an immediate reading of it vs > > requiring to rely on an aggregator to exploit it. It is generally added > to > > the access log and allows to associate immediately a request to its > origin > > (if you start getting a bunch of 500 or 401 and have a pipeline of > 3 > hops > > it makes the diagnostic very efficient compared to going to your > aggregator > > in general). Makes sense? > > > > > > > > > Christian > > > > > > On 08.12.2016 08:58, Romain Manni-Bucau wrote: > > > > > >> Hello guys, > > >> > > >> would it make sense to have a lighter tracker in cxf? idea is just to > > have > > >> a header accumulator but not all the data zipkin requires. I often saw > > it > > >> used in companies to track the data path but often it is self > contained > > >> and > > >> only contains the host list. In term of delivery it would be a jaxrs > > >> client/server provider (or interceptor) to handle the header and soap > > >> equivalent probably. Wdyt? > > >> > > >> (to make it clear client1 would send Cxf-Tracking: host1, if received > on > > >> host2 the program does another request it will send Cxf-Tracking: > > >> host1,host2 etc...) > > >> > > >> > > >> > > > > > > -- > > > Christian Schneider > > > http://www.liquid-reality.de > > > > > > Open Source Architect > > > http://www.talend.com > > > > > > > > >
