That's right, Sergey, we have done some work around span manipulation in case of async calls. The brave-cxf supports that as well but in any case things may get a bit more complicated. I agree with you.
On Thu, Dec 8, 2016 at 10:32 AM, Sergey Beryozkin <[email protected]> wrote: > Hi Romain > > At least for CXF hTrace I know Andriy did some context switching to keep > the track of the spans/etc. The span is detached, etc, I wonder how does it > work under the hood > > Sergey > > On 08/12/16 14:34, Romain Manni-Bucau wrote: > >> 2016-12-08 15:14 GMT+01:00 Sergey Beryozkin <[email protected]>: >> >> Hi Romain >>> >>> Light-weight tracing (capturing few headers. etc) can be done with basic >>> custom features/interceptors, do you reckon there's a scope for shipping >>> something in CXF ? >>> >>> Yes >>> >> >> >> I suppose adding few basic interceptors to rt/management can work >>> >>> >> Yes, >> >> only trick is to support @Suspended case, see >> https://gist.github.com/rmannibucau/8c48d4182388b228046586fd6785a2f2 >> >> >> >>> Cheers, Sergey >>> >>> On 08/12/16 13:29, Romain Manni-Bucau wrote: >>> >>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> -- >>> Sergey Beryozkin >>> >>> Talend Community Coders >>> http://coders.talend.com/ >>> >>> >> >
