cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1005950 - in /websites/production/cxf/content: cache/docs.pageCache docs/using-apache-htrace.html docs/using-openzipkin-brave.html
Date Tue, 31 Jan 2017 01:47:06 GMT
Author: buildbot
Date: Tue Jan 31 01:47:06 2017
New Revision: 1005950

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/using-apache-htrace.html
    websites/production/cxf/content/docs/using-openzipkin-brave.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/using-apache-htrace.html
==============================================================================
--- websites/production/cxf/content/docs/using-apache-htrace.html (original)
+++ websites/production/cxf/content/docs/using-apache-htrace.html Tue Jan 31 01:47:06 2017
@@ -117,19 +117,19 @@ Apache CXF -- Using Apache HTrace
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1485816393306 {padding: 0px;}
-div.rbtoc1485816393306 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1485816393306 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1485827192918 {padding: 0px;}
+div.rbtoc1485827192918 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1485827192918 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1485816393306">
+/*]]>*/</style></p><div class="toc-macro rbtoc1485827192918">
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingApacheHTrace-Overview">Overview</a></li><li><a
shape="rect" href="#UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing
in Nutshell</a></li><li><a shape="rect" href="#UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
Tracing in Apache CXF using Apache HTrace</a></li><li><a shape="rect"
href="#UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring Client</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingApacheHTrace-Configuringtracingheadernames">Configuring
tracing header names</a></li></ul>
 </li><li><a shape="rect" href="#UsingApacheHTrace-ConfiguringServerconfigure.server">Configuring
Server</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingApacheHTrace-Configuringtracingheadernames.1">Configuring
tracing header names</a></li></ul>
 </li><li><a shape="rect" href="#UsingApacheHTrace-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingApacheHTrace-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</a></li><li><a
shape="rect" href="#UsingApacheHTrace-Example#2:ClientandServerwithnestedtrace">Example
#2: Client and Server with nested trace</a></li><li><a shape="rect" href="#UsingApacheHTrace-Example#3:ClientandServertracewithtimeline">Example
#3: Client and Server trace with timeline</a></li><li><a shape="rect"
href="#UsingApacheHTrace-Example#4:ClientandServerwithannotatedtrace(key/value)">Example
#4: Client and Server with annotated trace (key/value)</a></li><li><a
shape="rect" href="#UsingApacheHTrace-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread pools)</a></li><li><a
shape="rect" href="#UsingApacheHTrace-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Exampl
 e #6: Client and Server with asynchronous JAX-RS service (server-side)</a></li><li><a
shape="rect" href="#UsingApacheHTrace-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
-</li><li><a shape="rect" href="#UsingApacheHTrace-DistributedTracingandJAX-WSsupport">Distributed
Tracing and JAX-WS support</a></li><li><a shape="rect" href="#UsingApacheHTrace-FutureWork">Future
Work</a></li></ul>
-</div><h1 id="UsingApacheHTrace-Overview">Overview</h1><p><a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
is a tracing framework intended for use with distributed systems written in java. Since version
<strong>3.1.3</strong>, Apache CXF fully supports integration with <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>,
both on client side and server side. This section gives a complete overview on how distributed
tracing support is supported in JAX-RS applications built on top of Apache CXF.</p><h1
id="UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing in Nutshell</h1><p>Distributed
tracing, first described by Google in <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper became increasingly important topic these days. With 
 microservices (aka SOA) gaining more and more adoption, the typical applications are built
using dozens or even hundreds of small, distributed pieces. The end-to-end traceability of
the requests (or any kind of work performed on user's behalf) is hard task to accomplish,
particularly taking into account asyncronous or/and concurrent invocations. <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
is inspired by <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper and essentially is a full-fledged distributed tracing framework.</p><p>Distributed
tracing is additional instrumentation layer on top of new or existing applications. In terms
of distributed tracing, <strong>span</strong> represents a basic unit of work.
For example, executing database query is a <strong>span</strong>. <strong>Spans</strong>

 are identified by a unique 128-bit ID. <strong>Spans</strong> also have other
data, such as <strong>descriptions</strong>, <strong>timelines</strong>,<strong>
key-value annotations</strong>, the <strong>ID</strong> of the <strong>span</strong>
that caused them (parent), and <strong>process/tracer</strong> ID&#8217;s
(normally IP address and process name). Spans are started and stopped, and they keep track
of their timing information. Once <strong>span</strong> is created, it should
be stopped at some point in the future. In turn, <strong>trace</strong> is a set
of spans forming a tree-like structure. For example, if you are running a JAX-RS service,
a trace might be formed by a <strong>PUT</strong> request and downstream work.</p><p>From
implementation prospective, and in context of Java applications, <strong>spans</strong>
are attached to their threads (in general, thread which created the <strong>span</strong>
should close it). However it is possible to transfer <strong>spans</str
 ong> from thread to thread in order to model a complex execution flows. It is also possible
to have many <strong>spans</strong> in the same thread, as long as they are properly
created and closed. In the next sections we are going to see the examples of that.</p><p>Another
two important concepts in context of distributed tracing are <strong>span receivers</strong>
and <strong>samplers</strong>. Essentially, all spans (including start/stop time,
key/value annotations, timelines, ..) should be persisted (or collected) somewhere. <strong>Span
receiver</strong> is a collector within a process that is the destination of <strong>spans</strong>
when a trace is running (it could be a console, local file, data store, ...). <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
provides span receivers for <a shape="rect" class="external-link" href="http://hbase.apache.org">Apache
HBase</a>, <a shape="rect" class="external-link" href="https
 ://flume.apache.org/">Apache Flume</a> and <a shape="rect" class="external-link"
href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>. From other side, <strong>samplers</strong>
allow to control the frequency of the tracing (all the time, never, probability driven, ...).
Using the <strong>sampler</strong> is the way to minimize tracing overhead (or
just amount of traces) by limiting them to particular conditions.</p><h1 id="UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
Tracing in Apache CXF using Apache HTrace</h1><p><a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> is a very popular framework for building services and web APIs. No doubts, it
is going to play even more important role in context of microservices architecture letting
developers to quickly build and deploy individual JAX-RS/JAX-WS services. As it was just mentioned
before, distributed tracing is an essential technique to monitor the application as whole,
breaking the req
 uest to individual service traces as it goes through and crosses the boundaries of threads,
processes and machines.</p><p>The current integration of distributed tracing in
<a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> supports <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
(<strong>4.x+</strong> release branch) only in JAX-RS 2.x applications. From high-level
prospective, it consists of three main parts:</p><ul style="list-style-type: square;"><li><strong>TracerContext</strong>
(injectable through <strong>@Context</strong> annotation)</li><li><strong>HTraceProvider</strong>
(server-side JAX-RS provider) and <strong>HTraceClientProvider</strong> (client-side
JAX-RS provider)</li><li><strong>HTraceFeature</strong> (server-side
<a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> feature to simplify
<a shape="rect" class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache
HTrace
 </a> configuration and integration)</li></ul><p><a shape="rect"
href="http://cxf.apache.org/">Apache CXF</a> uses HTTP headers to hand off tracing
context from the client to the service and from the service to service. Those headers are
used internally by <strong>HTraceProvider</strong> and <strong>HTraceClientProvider</strong>,
but are configurable. The default header names are declared in the TracerHeaders class:</p><ul
style="list-style-type: square;"><li><strong>X-Span-Id</strong>: contains
a current span ID</li></ul><p>By default, <strong>HTraceProvider</strong>
will try to pass the currently active <strong>span</strong> through HTTP headers
on each service invocation. If there is no active spans, the new span will be created and
passed through HTTP headers on per-invocation basis. Essentially, just registering the <strong>HTraceProvider</strong>
on the client and <strong>HTraceClientProvider</strong> on the server is enough
to have tracing context to be properly passed everywh
 ere. The only configuration part which is necessary are <strong>span receiver(s)</strong>
and <strong>sampler</strong>(s).</p><p>It is also worth to mention
the way <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> attaches
the description to <strong>spans</strong>. With regards to the client integration,
the description becomes a full URL being invoked prefixed by HTTP method, for example: <strong>GET
</strong><a shape="rect" class="external-link" href="http://localhost:8282/books"
rel="nofollow"><strong>http://localhost:8282</strong>/books</a>. On the
server side integration, the description becomes a relation JAX-RS resource path prefixed
by HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1
id="UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring Client <span class="confluence-anchor-link"
id="UsingApacheHTrace-configure.client"></span></h1><p>There are a couple
of ways the JAX-RS client could be configured, depending on the client impleme
 ntation. <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> provides
its own <strong>WebClient</strong> which could be configured just like that (in
future versions, there would be a simpler ways to do that using client specific features):</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+</li><li><a shape="rect" href="#UsingApacheHTrace-DistributedTracingApacheHTraceandJAX-WSsupport">Distributed
Tracing Apache HTrace and JAX-WS support</a></li><li><a shape="rect"
href="#UsingApacheHTrace-FutureWork">Future Work</a></li></ul>
+</div><h1 id="UsingApacheHTrace-Overview">Overview</h1><p><a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
is a tracing framework intended for use with distributed systems written in java. Since version
<strong>3.1.3</strong>, Apache CXF fully supports integration with <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>,
both on client side and server side. This section gives a complete overview on how distributed
tracing support is supported in JAX-RS applications built on top of Apache CXF.</p><h1
id="UsingApacheHTrace-DistributedTracinginNutshell">Distributed Tracing in Nutshell</h1><p>Distributed
tracing, first described by Google in <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper became increasingly important topic these days. With 
 microservices (aka SOA) gaining more and more adoption, the typical applications are built
using dozens or even hundreds of small, distributed pieces. The end-to-end traceability of
the requests (or any kind of work performed on user's behalf) is hard task to accomplish,
particularly taking into account asyncronous or/and concurrent invocations. <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
is inspired by <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper and essentially is a full-fledged distributed tracing framework.</p><p>Distributed
tracing is additional instrumentation layer on top of new or existing applications. In terms
of distributed tracing, <strong>span</strong> represents a basic unit of work.
For example, executing database query is a <strong>span</strong>. <strong>Spans</strong>

 are identified by a unique 128-bit ID. <strong>Spans</strong> also have other
data, such as <strong>descriptions</strong>, <strong>timelines</strong>,<strong>
key-value annotations</strong>, the <strong>ID</strong> of the <strong>span</strong>
that caused them (parent), and <strong>process/tracer</strong> ID&#8217;s
(normally IP address and process name). Spans are started and stopped, and they keep track
of their timing information. Once <strong>span</strong> is created, it should
be stopped at some point in the future. In turn, <strong>trace</strong> is a set
of spans forming a tree-like structure. For example, if you are running a JAX-RS service,
a trace might be formed by a <strong>PUT</strong> request and downstream work.</p><p>From
implementation perspective, and in context of Java applications, <strong>spans</strong>
are attached to their threads (in general, thread which created the <strong>span</strong>
should close it). However it is possible to transfer <strong>spans</str
 ong> from thread to thread in order to model a complex execution flows. It is also possible
to have many <strong>spans</strong> in the same thread, as long as they are properly
created and closed. In the next sections we are going to see the examples of that.</p><p>Another
two important concepts in context of distributed tracing are <strong>span receivers</strong>
and <strong>samplers</strong>. Essentially, all spans (including start/stop time,
key/value annotations, timelines, ..) should be persisted (or collected) somewhere. <strong>Span
receiver</strong> is a collector within a process that is the destination of <strong>spans</strong>
when a trace is running (it could be a console, local file, data store, ...). <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
provides span receivers for <a shape="rect" class="external-link" href="http://hbase.apache.org">Apache
HBase</a>, <a shape="rect" class="external-link" href="https
 ://flume.apache.org/">Apache Flume</a> and <a shape="rect" class="external-link"
href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>. From other side, <strong>samplers</strong>
allow to control the frequency of the tracing (all the time, never, probability driven, ...).
Using the <strong>sampler</strong> is the way to minimize tracing overhead (or
just amount of traces) by limiting them to particular conditions.</p><h1 id="UsingApacheHTrace-DistributedTracinginApacheCXFusingApacheHTrace">Distributed
Tracing in Apache CXF using Apache HTrace</h1><p><a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> is a very popular framework for building services and web APIs. No doubts, it
is going to play even more important role in context of microservices architecture letting
developers to quickly build and deploy individual JAX-RS/JAX-WS services. As it was just mentioned
before, distributed tracing is an essential technique to monitor the application as whole,
breaking the req
 uest to individual service traces as it goes through and crosses the boundaries of threads,
processes and machines.</p><p>The current integration of distributed tracing in
<a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> supports <a shape="rect"
class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a>
(<strong>4.x+</strong> release branch) only in JAX-RS 2.x applications. From high-level
prospective, it consists of three main parts:</p><ul style="list-style-type: square;"><li><strong>TracerContext</strong>
(injectable through <strong>@Context</strong> annotation)</li><li><strong>HTraceProvider</strong>
(server-side JAX-RS provider) and <strong>HTraceClientProvider</strong> (client-side
JAX-RS provider)</li><li><strong>HTraceFeature</strong> (server-side
<a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> feature to simplify
<a shape="rect" class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache
HTrace
 </a> configuration and integration)</li></ul><p><a shape="rect"
href="http://cxf.apache.org/">Apache CXF</a> uses HTTP headers to hand off tracing
context from the client to the service and from the service to service. Those headers are
used internally by <strong>HTraceProvider</strong> and <strong>HTraceClientProvider</strong>,
but are configurable. The default header names are declared in the TracerHeaders class:</p><ul
style="list-style-type: square;"><li><strong>X-Span-Id</strong>: contains
a current span ID</li></ul><p>By default, <strong>HTraceProvider</strong>
will try to pass the currently active <strong>span</strong> through HTTP headers
on each service invocation. If there is no active spans, the new span will be created and
passed through HTTP headers on per-invocation basis. Essentially, just registering the <strong>HTraceClientProvider</strong>
on the client and&#160;<strong>HTraceProvider</strong> on the server is enough
to have tracing context to be properly passed ev
 erywhere. The only configuration part which is necessary are <strong>span receiver(s)</strong>
and <strong>sampler</strong>(s).</p><p>It is also worth to mention
the way <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> attaches
the description to <strong>spans</strong>. With regards to the client integration,
the description becomes a full URL being invoked prefixed by HTTP method, for example: <strong>GET
</strong><a shape="rect" class="external-link" href="http://localhost:8282/books"
rel="nofollow"><strong>http://localhost:8282</strong>/books</a>. On the
server side integration, the description becomes a relative JAX-RS resource path prefixed
by HTTP method, f.e.: <strong>GET books, POST book/123</strong></p><h1
id="UsingApacheHTrace-ConfiguringClientconfigure.client">Configuring Client <span class="confluence-anchor-link"
id="UsingApacheHTrace-configure.client"></span></h1><p>There are a couple
of ways the JAX-RS client could be configured, depending on the client im
 plementation. <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> provides
its own <strong>WebClient</strong> which could be configured just like that (in
future versions, there would be a simpler ways to do that using client specific features):</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">final
Map&lt;String, String&gt; properties = new HashMap&lt;String, String&gt;();
 properties.put(Tracer.SPAN_RECEIVER_CLASSES_KEY, ...);
 properties.put(Tracer.SAMPLER_CLASSES_KEY, ...);
@@ -338,7 +338,7 @@ public Collection&lt;Book&gt; getBooks()
     .accept(MediaType.APPLICATION_JSON)
     .async()
     .get();</pre>
-</div></div><p>In this respect, there is no difference from the caller
prospective however a bit more work is going under the hood to transfer the active tracing
span from JAX-RS client request filter to client response filter as in general those are executed
in different threads (similarly to server-side asynchronous JAX-RS resource invocation). The
actual invocation of the request by the client (with process name <strong><span class="label
label-default service-filter-label service-tag-filtered">jaxrsclient/192.168.0.100</span></strong>)
and consequent invocation of the service on the server side (process name<strong> <span
class="label label-default service-filter-label">jaxrsserver/192.168.0.100</span></strong>)
is going to generate the following sample traces:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="250"
src="using-apache-htrace.data/image2015-9-16%2021:9:56.png"></span></p><h1
id="Using
 ApacheHTrace-DistributedTracingandJAX-WSsupport">Distributed Tracing and JAX-WS support</h1><p>Distributed
tracing in the <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> is
build primarily around JAX-RS 2.x implementation. However, JAX-WS is also supported but it
requires to write some boiler-plate code and use <a shape="rect" class="external-link"
href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a> API directly
(the JAX-WS integration is going to be enhanced in the nearest future). Essentially, from
the server-side prospective the in/out interceptors,&#160;<strong>HTraceStartInterceptor</strong>
and&#160;<strong>HTraceStopInterceptor </strong>respectively, should be configured
as part of interceptor chains. The <strong>span</strong> receiver should be configured
manually though, using <a shape="rect" class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache
HTrace</a> API, for example:</p><div class="code panel pdl" style="bor
 der-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>In this respect, there is no difference from the caller
prospective however a bit more work is going under the hood to transfer the active tracing
span from JAX-RS client request filter to client response filter as in general those are executed
in different threads (similarly to server-side asynchronous JAX-RS resource invocation). The
actual invocation of the request by the client (with process name <strong><span class="label
label-default service-filter-label service-tag-filtered">jaxrsclient/192.168.0.100</span></strong>)
and consequent invocation of the service on the server side (process name<strong> <span
class="label label-default service-filter-label">jaxrsserver/192.168.0.100</span></strong>)
is going to generate the following sample traces:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="250"
src="using-apache-htrace.data/image2015-9-16%2021:9:56.png"></span></p><h1
id="Using
 ApacheHTrace-DistributedTracingApacheHTraceandJAX-WSsupport">Distributed Tracing Apache
HTrace and JAX-WS support</h1><p>Distributed tracing in the <a shape="rect"
href="http://cxf.apache.org/">Apache CXF</a> is build primarily around JAX-RS 2.x
implementation. However, JAX-WS is also supported but it requires to write some boiler-plate
code and use <a shape="rect" class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache
HTrace</a> API directly (the JAX-WS integration is going to be enhanced in the nearest
future). Essentially, from the server-side prospective the in/out interceptors,&#160;<strong>HTraceStartInterceptor</strong>
and&#160;<strong>HTraceStopInterceptor </strong>respectively, should be configured
as part of interceptor chains. The <strong>span</strong> receiver should be configured
manually though, using <a shape="rect" class="external-link" href="http://htrace.incubator.apache.org/index.html">Apache
HTrace</a> API, for example:</p><div class="
 code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">final
Map&lt;String, String&gt; properties = new HashMap&lt;String, String&gt;();
 final HTraceConfiguration conf = HTraceConfiguration.fromMap(properties);
 Trace.addReceiver(new StandardOutSpanReceiver(conf));

Modified: websites/production/cxf/content/docs/using-openzipkin-brave.html
==============================================================================
--- websites/production/cxf/content/docs/using-openzipkin-brave.html (original)
+++ websites/production/cxf/content/docs/using-openzipkin-brave.html Tue Jan 31 01:47:06 2017
@@ -108,13 +108,15 @@ Apache CXF -- Using OpenZipkin Brave
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1485823591885 {padding: 0px;}
-div.rbtoc1485823591885 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1485823591885 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1485827193833 {padding: 0px;}
+div.rbtoc1485827193833 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1485827193833 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1485823591885">
-<ul class="toc-indentation"><li><a shape="rect" href="#UsingOpenZipkinBrave-Overview">Overview</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
Tracing in Apache CXF using OpenZipkin Brave</a></li></ul>
-</div><h1 id="UsingOpenZipkinBrave-Overview">Overview</h1><p><a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a> is a distributed tracing implementation compatible with <a shape="rect"
class="external-link" href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>
backend services, written in Java. For quite a while <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> offers
a dedicated module to integrate with Apache CXF framework, namely <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave/tree/master/brave-cxf3" rel="nofollow">brave-cxf3</a>.
However, lately the discussion <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave/issues/313"
rel="nofollow">had been initiated</a> to make this integration a part of Apache CXF
codebase so the CXF team is going to be responsible for maintaining it. As such, 
 it is going to be available in upcoming <strong>3.2.0</strong> release under
<strong>cxf-integration-tracing-brave</strong> module, with both client side and
server side supported. This section gives a complete overview on how distributed tracing using&#160;<a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a> could be integrated into JAX-RS / JAX-WS applications built on top of Apache
CXF.</p><p><a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> is inspired by the&#160;<a shape="rect"
class="external-link" href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>
and <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper and is a full-fledged distributed tracing framework. The section <a shape="rect"
href="using-apache-htrace.html
 ">dedicated to Apache HTrace </a>has pretty good introduction into distributed tracing
basics. However, there are a few key differences between <a shape="rect" class="external-link"
href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a> and <a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a>. In <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">Brave</a> every <strong>Span</strong> is associated with
128 or 64-bit long <strong>Trace ID</strong>, which logically groups the <strong>spans</strong>
related to the same distributed unit of work. Within the process <strong>span</strong>s
are collected by <strong>reporters</strong> (it could be a console, local file,
data store, ...). <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> provides span reporters for <a shape="rect"
class="external-link" h
 ref="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a> and <strong>java.util.logging</strong>
loggers.</p><p>Under the hood <strong>spans</strong> are attached
to their threads (in general, thread which created the <strong>span</strong> should
close it), the same technique employed by other distributed tracing implementations. However,
what is unique is that <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> distinguishes three different types of tracers:</p><ul
style="list-style-type: square;"><li>server tracer (<strong>com.github.kristofa.brave.ServerTracer</strong>)</li><li>client
tracer (<strong>com.github.kristofa.brave.ClientTracer</strong>)</li><li>local
tracer (<strong>com.github.kristofa.brave</strong>.<strong>LocalTracer</strong>)</li></ul><p><a
shape="rect" href="http://cxf.apache.org/">Apache CXF</a> integration uses <strong>client
tracer</strong> to instantiate spans on client side (providers and inter
 ceptors) to demarcate send / receive cycle, <strong>server tracer</strong> on
the server side (providers and interceptors) to demarcate receive / send cycle, while using
<strong>local tracer</strong> for any spans instantiated within a process.</p><h1
id="UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
Tracing in Apache CXF using OpenZipkin Brave</h1></div>
+/*]]>*/</style></p><div class="toc-macro rbtoc1485827193833">
+<ul class="toc-indentation"><li><a shape="rect" href="#UsingOpenZipkinBrave-Overview">Overview</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
Tracing in Apache CXF using OpenZipkin Brave</a></li><li><a shape="rect"
href="#UsingOpenZipkinBrave-ConfiguringClient">Configuring Client</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-ConfiguringServer">Configuring Server</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</a>
+<ul class="toc-indentation"><li><a shape="rect" href="#UsingOpenZipkinBrave-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-Example#2:ClientandServerwithnestedtrace">Example
#2: Client and Server with nested trace</a></li><li><a shape="rect" href="#UsingOpenZipkinBrave-Example#3:ClientandServertracewithannotations">Example
#3: Client and Server trace with annotations</a></li><li><a shape="rect"
href="#UsingOpenZipkinBrave-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread pools)</a></li><li><a
shape="rect" href="#UsingOpenZipkinBrave-Example#6:ClientandServerwithasynchronousJAX-
 RSservice(server-side)">Example #6: Client and Server with asynchronous JAX-RS service
(server-side)</a></li><li><a shape="rect" href="#UsingOpenZipkinBrave-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
+</li><li><a shape="rect" href="#UsingOpenZipkinBrave-DistributedTracingwithOpenZipkinBraveandJAX-WSsupport">Distributed
Tracing with OpenZipkin Brave and JAX-WS support</a></li><li><a shape="rect"
href="#UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating from brave-cxf3</a></li></ul>
+</div><h1 id="UsingOpenZipkinBrave-Overview">Overview</h1><p><a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a> is a distributed tracing implementation compatible with <a shape="rect"
class="external-link" href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>
backend services, written in Java. For quite a while <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> offers
a dedicated module to integrate with Apache CXF framework, namely <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave/tree/master/brave-cxf3" rel="nofollow">brave-cxf3</a>.
However, lately the discussion <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave/issues/313"
rel="nofollow">had been initiated</a> to make this integration a part of Apache CXF
codebase so the CXF team is going to be responsible for maintaining it. As such, 
 it is going to be available in upcoming <strong>3.2.0</strong> release under
<strong>cxf-integration-tracing-brave</strong> module, with both client side and
server side supported. This section gives a complete overview on how distributed tracing using&#160;<a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a> could be integrated into JAX-RS / JAX-WS applications built on top of Apache
CXF.</p><p><a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> is inspired by the&#160;<a shape="rect"
class="external-link" href="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a>
and <a shape="rect" class="external-link" href="http://research.google.com/pubs/pub36356.html"
rel="nofollow">Dapper, a Large-Scale Distributed Systems Tracing Infrastructure</a>
paper and is a full-fledged distributed tracing framework. The section <a shape="rect"
href="using-apache-htrace.html
 ">dedicated to Apache HTrace </a>has pretty good introduction into distributed tracing
basics. However, there are a few key differences between <a shape="rect" class="external-link"
href="http://htrace.incubator.apache.org/index.html">Apache HTrace</a> and <a
shape="rect" class="external-link" href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin
Brave</a>. In <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">Brave</a> every <strong>Span</strong> is associated with
128 or 64-bit long <strong>Trace ID</strong>, which logically groups the <strong>spans</strong>
related to the same distributed unit of work. Within the process <strong>span</strong>s
are collected by <strong>reporters</strong> (it could be a console, local file,
data store, ...). <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> provides span reporters for <a shape="rect"
class="external-link" h
 ref="http://zipkin.io/" rel="nofollow">Twitter Zipkin</a> and <strong>java.util.logging</strong>
loggers.</p><p>Under the hood <strong>spans</strong> are attached
to their threads (in general, thread which created the <strong>span</strong> should
close it), the same technique employed by other distributed tracing implementations. However,
what is unique is that <a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> distinguishes three different types of tracers:</p><ul
style="list-style-type: square;"><li>server tracer (<strong>com.github.kristofa.brave.ServerTracer</strong>)</li><li>client
tracer (<strong>com.github.kristofa.brave.ClientTracer</strong>)</li><li>local
tracer (<strong>com.github.kristofa.brave</strong>.<strong>LocalTracer</strong>)</li></ul><p><a
shape="rect" href="http://cxf.apache.org/">Apache CXF</a> integration uses <strong>client
tracer</strong> to instantiate spans on client side (providers and inter
 ceptors) to demarcate send / receive cycle, <strong>server tracer</strong> on
the server side (providers and interceptors) to demarcate receive / send cycle, while using
<strong>local tracer</strong> for any spans instantiated within a process.</p><h1
id="UsingOpenZipkinBrave-DistributedTracinginApacheCXFusingOpenZipkinBrave">Distributed
Tracing in Apache CXF using OpenZipkin Brave</h1><p>The current integration of
distributed tracing in <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a>
supports&#160;<a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> (<strong>3.16+</strong> release branch)
in JAX-RS 2.x+ and JAX-WS applications, including the applications deploying in <a shape="rect"
class="external-link" href="https://www.osgi.org/" rel="nofollow">OSGi</a> containers.
From high-level perspective,&#160;JAX-RS 2.x+ integration consists of three main parts:</p><ul><li><strong>TracerContext</strong>
(injectabl
 e through <strong>@Context</strong> annotation)</li><li><strong>BraveProvider</strong>
(server-side JAX-RS provider) and <strong>BraveClientProvider</strong> (client-side
JAX-RS provider)</li><li><strong>BraveFeature</strong> (server-side&#160;JAX-RS
feature to simplify&#160;<a shape="rect" class="external-link" href="https://github.com/openzipkin/brave"
rel="nofollow">OpenZipkin Brave</a> configuration and integration)</li></ul><p>Similarly,
from high-level perspective,&#160;JAX-WS integration includes:</p><ul style="list-style-type:
square;"><li><strong>BraveStartInterceptor</strong> / <strong>BraveStopInterceptor</strong>
/ <strong>BraveFeature&#160;</strong><a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> feature (server-side JAX-WS support)</li><li><strong>BraveClientStartInterceptor</strong>
/ <strong>BraveClientStopInterceptor</strong> / <strong>BraveClientFeature&#160;</strong><a
shape="rect" href="http://cxf.apache.org/">Apache CXF</a> feature (client-side JAX-W
 S support)</li></ul><p><a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> uses HTTP headers to hand off tracing context from the client to the service
and from the service to service. Those headers are used internally by <a shape="rect" class="external-link"
href="https://github.com/openzipkin/brave" rel="nofollow">OpenZipkin Brave</a> and
are not configurable at the moment. The header names are declared in the&#160;<strong>BraveHttpHeaders</strong>
class and at the moment include:</p><ul style="list-style-type: square;"><li><strong>X-B3-TraceId</strong>:
128 or 64-bit trace ID</li><li><strong>X-B3-SpanId</strong>: 64-bit
span ID</li><li><strong>X-B3-ParentSpanId</strong>: 64-bit parent
span ID</li><li><p><strong>X-B3-Sampled</strong>: "1" means
report this span to the tracing system, "0" means do not</p></li></ul><p>By
default, <strong>BraveClientProvider</strong> will try to pass the currently active
<strong>span</strong> through HTTP headers on each service invocation. 
 If there is no active spans, the new span will be created and passed through HTTP headers
on per-invocation basis. Essentially, for JAX-RS applications just registering <strong>BraveClientProvider</strong>
on the client and <strong>BraveProvider</strong> on the server is enough to have
tracing context to be properly passed everywhere. The only configuration part which is necessary
are <strong>span reports(s)</strong> and <strong>sampler</strong>(s).</p><p>It
is also worth to mention the way <a shape="rect" href="http://cxf.apache.org/">Apache
CXF</a> attaches the description to <strong>spans</strong>. With regards
to the client integration, the description becomes a full URL being invoked prefixed by HTTP
method, for example: <strong>GET </strong><a shape="rect" class="external-link"
href="http://localhost:8282/books" rel="nofollow"><strong>http://localhost:8282</strong>/books</a>.
On the server side integration, the description becomes a relative JAX-RS resource path prefixed
by HT
 TP method, f.e.: <strong>GET books, POST book/123</strong></p><h1 id="UsingOpenZipkinBrave-ConfiguringClient">Configuring
Client</h1><p>// TODO</p><h1 id="UsingOpenZipkinBrave-ConfiguringServer">Configuring
Server</h1><p>// TODO</p><h1 id="UsingOpenZipkinBrave-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</h1><h2 id="UsingOpenZipkinBrave-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</h2><h2 id="UsingOpenZipkinBrave-Example#2:ClientandServerwithnestedtrace">Example
#2: Client and Server with nested trace</h2><h2 id="UsingOpenZipkinBrave-Example#3:ClientandServertracewithannotations">Example
#3: Client and Server trace with annotations</h2><h2 id="UsingOpenZipkinBrave-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</h2><h2 id="UsingOpenZipkinBrave-Example#5:ClientandServerw
 ithparalleltrace(involvingthreadpools)">Example #5: Client and Server with parallel trace
(involving thread pools)</h2><h2 id="UsingOpenZipkinBrave-Example#6:ClientandServerwithasynchronousJAX-RSservice(server-side)">Example
#6: Client and Server with asynchronous JAX-RS service (server-side)</h2><h2 id="UsingOpenZipkinBrave-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</h2><h1 id="UsingOpenZipkinBrave-DistributedTracingwithOpenZipkinBraveandJAX-WSsupport">Distributed
Tracing with OpenZipkin Brave and JAX-WS support</h1><p>// TODO</p><h1
id="UsingOpenZipkinBrave-Migratingfrombrave-cxf3">Migrating from brave-cxf3</h1><p>//
TODO</p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message