cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Redko <drr...@gmail.com>
Subject Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave
Date Thu, 08 Dec 2016 18:35:17 GMT
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 <sberyozkin@gmail.com>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message