cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave
Date Thu, 08 Dec 2016 16:32:02 GMT
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 <sberyozkin@gmail.com>:
>
>> 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 <drreta@gmail.com>:
>>>
>>> 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 <rmannibucau@gmail.com
>>>>>
>>>> wrote:
>>>>
>>>> 2016-12-08 9:10 GMT+01:00 Christian Schneider <chris@die-schneider.net>:
>>>>>
>>>>> 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/
>>
>


Mime
View raw message