[Hawkular-dev] Business transaction support with opentracing API

[Gary Brown]

You're not wrong :)

Only reason for discussing 2 is if we feel that it is going to be important to support business transaction capabilities above zipkin clients in the future.

At the moment zipkin has a good following, but these guys are also driving the opentracing initiative, so I'm hoping this suggests there will be a move away from the proprietary zipkin client libs towards opentracing anyway. But too early to tell.

Regards
Gary

----- Original Message -----
> I may miss the obvious, sorry in this case, but it looks like option 1 only
> has advantages and option 2 drawbacks. I'm sure it's not true.
> 
> 2016-09-14 11:26 GMT+02:00 Gary Brown < gbrown at redhat.com > :
> 
> 
> Hi
> 
> The current release of Hawkular APM has introduced support for zipkin
> clients, so that existing zipkin instrumented applications can now report
> their span data to the APM server and have it represented in the UI.
> 
> Further work is being done in this release to ensure that it works well with
> polyglot examples, including the Red Hat helloworld MSA example.
> 
> This means that in a JVM only environment it is possible to use the
> non-instrusive byteman approach to instrument the applications, but if
> wanting to monitor a polyglot environment, then we also can now support
> zipkin instrumented clients.
> 
> However this means that for those zipkin instrumented applications, it will
> not be possible to take advantage of the "business transaction" capabilities
> that are available with the non-instrusive instrumentation approach, as
> shown here: https://vimeo.com/167739840
> 
> Looking ahead, we are also investigating providing support for the
> opentracing API ( http://opentracing.io/ ) - which will provide end users
> with the ability to more easily switch between backend application tracing
> solutions.
> 
> The purpose of this email is to look at the possible approaches that could be
> used to introduce business transaction support for opentracing and
> potentially zipkin.
> 
> 1) Only support as part of our own opentracing providers
> 
> The opentracing API provides the means to record 'log' events against the
> spans being reported:
> https://github.com/opentracing/opentracing-java/blob/master/opentracing-api/src/main/java/io/opentracing/Span.java#L75
> 
> As shown in this javascript example:
> 
> http.request(opts, function (res) {
> res.setEncoding('utf8');
> res.on('error', function (err) {
> span.logEvent('request_error', err);
> span.finish();
> });
> res.on('data', function (chunk) {
> span.logEvent('data_received', chunk);
> });
> res.on('end', function(err) {
> span.logEvent('request_end', err);
> span.finish();
> });
> }).end();
> 
> the log event can be used to record data - in this case from the response.
> 
> Our opentracing provider could use this mechanism to process request or
> response data and extract relevant business properties.
> 
> The benefit of this approach is that the API used by the application is
> 'standard' - they just need to ensure the relevant business data is supplied
> as log events, and then define a business transaction config to process that
> data to extract the relevant information.
> 
> 2) Provide additional module used by application above the zipkin/opentracing
> API
> 
> This would require the application to deal with a Hawkular-APM specific
> client library to preprocess their business messages and then associate
> relevant properties with the zipkin/opentracing spans.
> 
> This approach obviously does not provide a standard API to the application
> for this aspect, and as it can only deal with the spans, is potentially
> limited in the actions it can perform - i.e. possibly only extract business
> properties and representing them as tags (in opentracing) or binary
> annotations (in zipkin).
> 
> 
> My current preference is option 1 as it encapsulates all of the functionality
> in our own opentracing providers (one per language supported), and gives us
> a bit more flexibility in terms of what the business txn config actions can
> perform.
> 
> Any feedback/suggestions welcome.
> 
> 
> Regards
> Gary
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>