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 <[email protected]>:
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 <[email protected]>:
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 <[email protected]
wrote:
2016-12-08 9:10 GMT+01:00 Christian Schneider <[email protected]>:
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/
