cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1018768 - in /websites/production/cxf/content: cache/docs.pageCache docs/using-opentracing.html
Date Wed, 27 Sep 2017 02:03:11 GMT
Author: buildbot
Date: Wed Sep 27 02:03:11 2017
New Revision: 1018768

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/using-opentracing.html

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

Modified: websites/production/cxf/content/docs/using-opentracing.html
==============================================================================
--- websites/production/cxf/content/docs/using-opentracing.html (original)
+++ websites/production/cxf/content/docs/using-opentracing.html Wed Sep 27 02:03:11 2017
@@ -33,6 +33,7 @@
 
 <script src='/resources/highlighter/scripts/shCore.js'></script>
 <script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -116,15 +117,15 @@ Apache CXF -- Using OpenTracing
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="UsingOpenTracing-/*&lt;![CDATA[*/div.rbtoc1505391959782{padding:0px;}div.rbtoc1505391959782ul{list-style:disc;margin-left:0px;}div.rbtoc1505391959782li{margin-left:0px;padding-left:0px;}/*]]&gt;*/#UsingOpenTracing-Overview#UsingOpenTracing-OverviewDistributedTr"><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1505391959782 {padding: 0px;}
-div.rbtoc1505391959782 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505391959782 li {margin-left: 0px;padding-left: 0px;}
+<div id="ConfluenceContent"><h1 id="UsingOpenTracing-/*&lt;![CDATA[*/div.rbtoc1506477678693{padding:0px;}div.rbtoc1506477678693ul{list-style:disc;margin-left:0px;}div.rbtoc1506477678693li{margin-left:0px;padding-left:0px;}/*]]&gt;*/#UsingOpenTracing-Overview#UsingOpenTracing-OverviewDistributedTr"><style
type="text/css">/*<![CDATA[*/
+div.rbtoc1506477678693 {padding: 0px;}
+div.rbtoc1506477678693 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1506477678693 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></h1><div class="toc-macro rbtoc1505391959782">
+/*]]>*/</style></h1><div class="toc-macro rbtoc1506477678693">
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingOpenTracing-"></a></li><li><a
shape="rect" href="#UsingOpenTracing-Overview">Overview</a></li><li><a
shape="rect" href="#UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</a></li><li><a shape="rect" href="#UsingOpenTracing-ConfiguringClient">Configuring
Client</a></li><li><a shape="rect" href="#UsingOpenTracing-ConfiguringServer">Configuring
Server</a></li><li><a shape="rect" href="#UsingOpenTracing-DistributedTracingInAction:UsageScenarios">Distributed
Tracing In Action: Usage Scenarios</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#UsingOpenTracing-Example#1:ClientandServerwithdefaultdistributedtracingconfigured">Example
#1: Client and Server with default distributed tracing configured</a></li><li><a
shape="rect" href="#UsingOpenTracing-Example#2:ClientandServerwithnestedtrace">Example
#2: Client and Server with nested trace</a></li><li><a shape="rect" href="#UsingOpenTracing-Example#3:ClientandServertracewithtimeline">Example
#3: Client and Server trace with timeline</a></li><li><a shape="rect"
href="#UsingOpenTracing-Example#4:ClientandServerwithbinaryannotations(key/value)">Example
#4: Client and Server with binary annotations (key/value)</a></li><li><a
shape="rect" href="#UsingOpenTracing-Example#5:ClientandServerwithparalleltrace(involvingthreadpools)">Example
#5: Client and Server with parallel trace (involving thread pools)</a></li><li><a
shape="rect" href="#UsingOpenTracing-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="#UsingOpenTracing-Example#7:ClientandServerwithasynchronousinvocation(client-side)">Example
#7: Client and Server with asynchronous invocation (client-side)</a></li></ul>
-</li><li><a shape="rect" href="#UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed
Tracing with OpenTracing and JAX-WS support</a></li></ul>
+</li><li><a shape="rect" href="#UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed
Tracing with OpenTracing and JAX-WS support</a></li><li><a shape="rect"
href="#UsingOpenTracing-DistributedTracingwithOpenTracingandOSGi">Distributed Tracing with
OpenTracing and OSGi</a></li></ul>
 </div><h1 id="UsingOpenTracing-Overview">Overview</h1><p><a shape="rect"
class="external-link" href="http://opentracing.io/" rel="nofollow">OpenTracing</a>
is a vendor-neutral open standard for distributed tracing. Essentially, for Java-based projects
the specification exists as a set of <a shape="rect" class="external-link" href="https://github.com/opentracing/opentracing-java"
rel="nofollow">Java APIs</a> which any distributed tracing solution is welcome to
implement. There are<a shape="rect" class="external-link" href="http://opentracing.io/documentation/pages/supported-tracers"
rel="nofollow"> quite a few distributed tracing frameworks</a> available which are
compatible with <a shape="rect" class="external-link" href="http://opentracing.io/" rel="nofollow">OpenTracing</a>,
notably <a shape="rect" class="external-link" href="http://zipkin.io/" rel="nofollow">Zipkin</a>
(via community contributions like <a shape="rect" class="external-link" href="https://github.com/openzipkin/brav
 e-opentracing" rel="nofollow">bridge from Brave to OpenTracing</a> ), <a shape="rect"
class="external-link" href="http://lightstep.com/" rel="nofollow">Lightstep</a> and
<a shape="rect" class="external-link" href="https://uber.github.io/jaeger/" rel="nofollow">Jaeger</a>.
Starting from <strong>3.2.1</strong> release, Apache CXF fully supports integration
(through <strong>cxf-integration-tracing-opentracing</strong> module) with any
distributed tracer that provides <a shape="rect" class="external-link" href="http://opentracing.io/"
rel="nofollow">OpenTracing</a>&#160;<a shape="rect" class="external-link"
href="https://github.com/opentracing/opentracing-java" rel="nofollow">Java API</a>
implementation.</p><p>The section <a shape="rect" href="https://cwiki.apache.org/confluence/display/CXF20DOC/Using+Apache+HTrace">dedicated
to Apache HTrace </a>has pretty good introduction into distributed tracing basics however
<a shape="rect" class="external-link" href="http://opentracing.io/" rel="
 nofollow">OpenTracing</a> specification abstracts a lot of things, outlining just
a general APIs to denote the <strong>Span&#160;</strong>lifecycle and injection
points to propagate the context across many distributed components. As such, the intrinsic
details about HTTP headers f.e. becomes an integral part of the distributed tracer of your
choice, out of reach for Apache CXF.</p><h1 id="UsingOpenTracing-DistributedTracinginApacheCXFusingOpenTracing">Distributed
Tracing in Apache CXF using OpenTracing</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. Distributed tracing
is an essential technique to observe the application platform as a whole, breaking the request
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&#160;<a shape="rect" class="external-link" href="http://opentracing.io/" rel="nofollow">OpenTracing</a>&#160;<a
shape="rect" class="external-link" href="https://github.com/opentracing/opentracing-java"
rel="nofollow">Java API</a> <strong class="external-link">0.30.0+</strong>
and provides full-fledged support of JAX-RS 2.x / JAX-WS applications. From high-level prospective,
the JAX-RS integration consists of three main parts:</p><ul><li><strong>TracerContext</strong>
(injectable through <strong>@Context</strong> annotation)</li><li><strong>OpenTracingProvider</strong>
(server-side JAX-RS provider) and <strong>OpenTracingClientProvider</strong> (client-side
JAX-RS provider)</li><li class="external-link"><strong>OpenTracingFeature</strong>
(server-side JAX-RS feature) to simplify the configuration and integration<
 /li></ul><p>Similarly, from high-level perspective,&#160;JAX-WS integration
includes:</p><ul><li><strong>OpenTracingStartInterceptor</strong>
/ <strong>OpenTracingStopInterceptor</strong> / <strong>OpenTracingFeature&#160;</strong><a
shape="rect" href="http://cxf.apache.org/">Apache CXF</a> feature (server-side JAX-WS
support)</li><li><strong>OpenTracingClientStartInterceptor</strong>
/ <strong>OpenTracingClientStopInterceptor</strong> / <strong>OpenTracingClientFeature&#160;</strong><a
shape="rect" href="http://cxf.apache.org/">Apache CXF</a> feature (client-side JAX-WS
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 specific to distributing tracing framework
you have picked and are not configurable at the moment (unless the framework itself has a
way to do that).</p><p>By default, <strong>OpenTracingClientProvider</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>OpenTracingClientProvider</strong> on the client and
<strong>OpenTracingProvider</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) which are, not surprisingly,
specific to distributing tracing framework you have chosen.</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="extern
 al-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="UsingOpenTracing-ConfiguringClient">Configuring Client</h1><p>In this section
and below, all the code snippets are going to be based on <a shape="rect" class="external-link"
href="https://uber.github.io/jaeger/" rel="nofollow">Jaeger</a> distributed tracing
framework (<strong>release 0.20.6+</strong>), although everything we are going
to discuss is equally applicable to any other existing alternatives. Essentially, the only
dependency <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a> integration
relies on is the <strong>Tracer</strong> instance.</p><p>There are
a couple of ways the JAX-RS client could be configured, depending on the client implementation.
<a shape="rect" href="http://cxf.apache.o
 rg/">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
Tracer tracer = new Configuration("web-client", 
         new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or any other Sampler
*/
@@ -321,7 +322,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 service name <strong>tracer-<span
class="label label-default service-filter-label service-tag-filtered">client</span></strong>)
and consequent invocation of the service on the server side (service name<strong> tracer-<span
class="label label-default service-filter-label">server</span></strong>) is
going to generate the following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui" rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image"

 height="250" src="using-opentracing.data/image2017-9-10%2015:0:49.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect" class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui" rel="nofollow">Zipkin
UI</a> frontend:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:58:53.png"></span></p><h1
id="UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed Tracing
with OpenTracing 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&#160;<a shape="rect" class="external-link" href="http://opentracing.io/"
rel="nofollow">OpenTracing</a>&#160;<a shape="rect" cla
 ss="external-link" href="https://github.com/opentracing/opentracing-java" rel="nofollow">Java
API</a>  directly (the JAX-WS integration is going to be enhanced in the future). Essentially,
from the server-side prospective the in/out interceptors, <strong>OpenTracingStartInterceptor</strong>
and <strong><strong>OpenTracing</strong>StopInterceptor </strong>respectively,
should be configured as part of interceptor chains, either manually or using <strong><strong>OpenTracing</strong>Feature</strong>.
For example:</p><div class="code panel pdl" style="border-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 service name <strong>tracer-<span
class="label label-default service-filter-label service-tag-filtered">client</span></strong>)
and consequent invocation of the service on the server side (service name<strong> tracer-<span
class="label label-default service-filter-label">server</span></strong>) is
going to generate the following sample traces (taken from <a shape="rect" class="external-link"
href="https://github.com/uber/jaeger-ui" rel="nofollow">Jaeger UI</a>):</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image"

 height="250" src="using-opentracing.data/image2017-9-10%2015:0:49.png"></span></p><p>The
same trace will be looking pretty similar using traditional <a shape="rect" class="external-link"
href="https://github.com/openzipkin/zipkin/tree/master/zipkin-ui" rel="nofollow">Zipkin
UI</a> frontend:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image" height="250"
src="using-opentracing.data/image2017-9-10%2014:58:53.png"></span></p><h1
id="UsingOpenTracing-DistributedTracingwithOpenTracingandJAX-WSsupport">Distributed Tracing
with OpenTracing 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&#160;<a shape="rect" class="external-link" href="http://opentracing.io/"
rel="nofollow">OpenTracing</a>&#160;<a shape="rect" cla
 ss="external-link" href="https://github.com/opentracing/opentracing-java" rel="nofollow">Java
API</a> directly (the JAX-WS integration is going to be enhanced in the future). Essentially,
from the server-side prospective the in/out interceptors, <strong>OpenTracingStartInterceptor</strong>
and <strong><strong>OpenTracing</strong>StopInterceptor </strong>respectively,
should be configured as part of interceptor chains, either manually or using <strong><strong>OpenTracing</strong>Feature</strong>.
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
Tracer tracer = new Configuration("tracer", 
         new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or any other Sampler
*/
         new Configuration.ReporterConfiguration(new HttpSender("http://localhost:14268/api/traces"))
/* or any other Sender */
@@ -345,7 +346,70 @@ sf.getFeatures().add(new OpenTracingClie
 sf.create();
 
 </pre>
-</div></div><p>As it was mentioned before, you may use <strong>GlobalTracer</strong>
utility class to pass the tracer around so, for example, any JAX-WS service will be able to
retrieve the current tracer by invoking <strong>GlobalTracer.get()</strong> method.</p></div>
+</div></div><p>As it was mentioned before, you may use <strong>GlobalTracer</strong>
utility class to pass the tracer around so, for example, any JAX-WS service will be able to
retrieve the current tracer by invoking <strong>GlobalTracer.get()</strong> method.</p><h1
id="UsingOpenTracing-DistributedTracingwithOpenTracingandOSGi">Distributed Tracing with
OpenTracing and OSGi</h1><p class="external-link">Most of the distributed tracers
compatible with <a shape="rect" class="external-link" href="http://opentracing.io/" rel="nofollow">OpenTracing</a>
API could be deployed into <strong>OSGi</strong> container and as such, the integration
is fully available for <a shape="rect" href="http://cxf.apache.org/">Apache CXF</a>
services running inside the container. For a complete example please take a look on <a
shape="rect" class="external-link" href="https://github.com/apache/cxf/master/distribution/src/main/release/samples/jax_rs_tracing_opentracing_osgi/README.txt"
rel="nofollow">jax_rs_tra
 cing_opentracing_osgi</a> sample project, but here is the typical <strong>OSGi</strong>&#160;
Blueprint snippet in case of <a shape="rect" class="external-link" href="https://uber.github.io/jaeger/"
rel="nofollow">Jaeger</a>.</p><p class="external-link">&#160;</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;?xml
version="1.0" encoding="UTF-8"?&gt;
+&lt;blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xmlns:cxf="http://cxf.apache.org/blueprint/core"
+       xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
+
+       xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
+                           http://cxf.apache.org/blueprint/core http://cxf.apache.org/schemas/blueprint/core.xsd
+                           http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd"&gt;
+
+    &lt;bean id="tracingFeature" class="org.apache.cxf.tracing.opentracing.jaxrs.OpenTracingFeature"&gt;
+        &lt;argument index="0"&gt;
+            &lt;bean factory-ref="builder" factory-method="build" /&gt;
+        &lt;/argument&gt;
+    &lt;/bean&gt;
+    
+    &lt;bean id="metrics" class="com.uber.jaeger.metrics.Metrics"&gt;
+        &lt;argument index="0"&gt;
+            &lt;bean class="com.uber.jaeger.metrics.StatsFactoryImpl"&gt;
+                &lt;argument index="0"&gt;
+                    &lt;bean class="com.uber.jaeger.metrics.NullStatsReporter" /&gt;
+                &lt;/argument&gt;
+            &lt;/bean&gt;
+        &lt;/argument&gt;
+    &lt;/bean&gt;
+    
+    &lt;bean id="builder" class="com.uber.jaeger.Tracer.Builder"&gt;
+        &lt;argument index="0" value="cxf-server" /&gt;
+        &lt;argument index="1"&gt;
+            &lt;bean class="com.uber.jaeger.reporters.RemoteReporter"&gt;
+                &lt;argument index="0" ref="sender" /&gt;
+                &lt;argument index="1" value="1000"/&gt;
+                &lt;argument index="2" value="100"/&gt;
+                &lt;argument index="3" ref="metrics"/&gt;
+            &lt;/bean&gt;
+        &lt;/argument&gt;
+        &lt;argument index="2"&gt;
+            &lt;bean class="com.uber.jaeger.samplers.ConstSampler"&gt;
+                &lt;argument index="0" value="true" /&gt;
+            &lt;/bean&gt;
+        &lt;/argument&gt;
+    &lt;/bean&gt;
+    
+    &lt;bean id="sender" class="com.uber.jaeger.senders.HttpSender"&gt;
+        &lt;argument index="0" value="http://localhost:14268/api/traces" /&gt;
+    &lt;/bean&gt;
+    
+    &lt;cxf:bus&gt;
+        &lt;cxf:features&gt;
+            &lt;cxf:logging /&gt;
+        &lt;/cxf:features&gt;
+    &lt;/cxf:bus&gt;
+
+    &lt;jaxrs:server id="catalogServer" address="/"&gt;
+        &lt;jaxrs:serviceBeans&gt;
+            ...
+        &lt;/jaxrs:serviceBeans&gt;
+        &lt;jaxrs:providers&gt;
+            &lt;ref component-id="tracingFeature" /&gt;
+        &lt;/jaxrs:providers&gt;
+    &lt;/jaxrs:server&gt;
+&lt;/blueprint&gt;</pre>
+</div></div><p>&#160;</p><p>&#160;</p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message