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/ >
