cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave
Date Thu, 08 Dec 2016 14:34:18 GMT
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