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 20:42:51 GMT
2016-12-08 21:39 GMT+01:00 Andrey Redko <drreta@gmail.com>:

> We have discussed this issue with Brave guys, pointing out to this specific
> use case (async call). Yes, all tracer are relying heavily on thread
> locals, however the detach / attach techniques are used to carry over the
> parent spans between threads.
>
>
Didn't see it in brave ATM but if handled that's good. Is it a dedicated
ContextProvider as proposed - which allows to control it through standard
@Context injection or something more specific?


> On Thu, Dec 8, 2016 at 12:36 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > 2016-12-08 19:35 GMT+01:00 Andrey Redko <drreta@gmail.com>:
> >
> > > 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.
> > >
> > >
> > Quick correction: bave DOESN'T since it relies on threadlocal which
> doesnt
> > passthrough the value or inherited thread local which leaks in this case.
> >
> >
> > > 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/8c48d4182388b228046586fd6785a2
> f2
> > > >>
> > > >>
> > > >>
> > > >>> 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