4:26 a.m.
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-a...
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
4:35 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:41 a.m.
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(a)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-a...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:48 a.m.
On 09/14/2016 11:41 AM, Gary Brown wrote:
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.
Is it possible/feasible to provide something in the format of Hibernate?
Like, support for standards whenever possible, but "proprietary"
extensions are available and play nice with the standard-compliant API.
- Juca.
5 a.m.
If we decided option 2 (i.e. business txn support also above zipkin) then that would have
to be the approach.
I suppose the compromise would be, for opentracing we incorporate it within the provider -
but enable the 'business txn processing' module to also be used directly by zipkin
instrumented application.
Regards
Gary
----- Original Message -----
On 09/14/2016 11:41 AM, Gary Brown wrote:
> 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.
Is it possible/feasible to provide something in the format of Hibernate?
Like, support for standards whenever possible, but "proprietary"
extensions are available and play nice with the standard-compliant API.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3029
days inactive
3029
days old
4 comments
3 participants
participants (3)
-
Gary Brown -
Juraci Paixão Kröhling -
Thomas Segismont