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 13:24:08 GMT
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.

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message