...
Spans
Give me all root spans
Give me all spans that belong to following trace
Give me a parent of a span
Give me children of a span
Invocations
What span I belong to
What remote calls I make
Give me all spans that are in the same trace as I am
Give me all available invocations that are in the same trace as I am
...
- opentracing.io spans are not perfect fit for inspectIT, as are missing information on which agent the span was created, what's the method id or sensor id. Thus, opentracing.io like spans are transformed to the ones that extend the MethodSensorData class in inspectIT and span context is transformed to the SpanIdent instances. These inspectIT-like spans are not available in the SDK project, but only in the inspectIT shared projects.
- opentracing.io allows the concrete implementation to define what are relation between spans making the call on one JVM and receiving the call on the other JVM. Many libraries chose to have same identification ids for both span calling (client) and its called span (server). We decided to have normal child-parent relationships (server span is child or client span), as it can occur that one call is making more spans on the receiving end (for example internally forwarded HTTP request).
- opentracing.io does not force implementation to provide sampling rate for tracing frequency. For now inspectIT does not have any sampler and is tracing every single request. In future this must change in order to decrease the amount of captured data on the agents.
- developed tracer is thread context aware, this means that it remembers the order of created spans per thread. Thus when new span is created by default it parent will be the latest created and not finished span by that thread.
Remote sensors
In oder to make design flexible and support easy addition of support for the new remote communication frameworks on the agent we developed set of remote sensors. Here following rules apply:
...
With this design approach it's easy to add, for example, the implementation for a new HTTP client framework. The only thing needed is basically implementation of the HttpRequest that corresponds to that specific framework and does the actual information reading, headers setting, etc. Everything else is already available via the ClientInterceptor and HttpRequestAdapter/HttpResponseAdapter.
Flow example
| View file | ||||
|---|---|---|---|---|
|
Link: http://prezi.com/kuvkl0vddepu/?utm_campaign=share&utm_medium=copy
Implementation
SDK project
To support implementation of the opentracing.io new project has been created: inspectit.agent.java.sdk. This project has only dependency to opentracing.io API and Noop tracer implementation.
We need to push the artifact of this project to the maven repository with the correctly defined pom in future, so that users can include it when they want to make their own spans are part of a trace.
Supported technologies and frameworks
Currently we support two technologies for the remote communication: HTTP and JMS. Here is the list of the framework related implementations available:
| Technology | Type | Framework | Version(s) | Comment |
|---|---|---|---|---|
| HTTP | Server | Java Servlet | All | Does not support response code reading in version 2.0 or less. |
| HTTP | Client | Apache Http Client | 4.x | Not including the asynchronous client library. |
| HTTP | Client | Jetty Http Client | 6.x-8.x | |
| HTTP | Client | URL Connection | java 1.6, 1.7 & 1.8 (1.9 ) | |
| HTTP | Client | Spring Rest Template | 3.x - 4.x | SRT is a wrapper. We are independent of the underlying client used. |
| MQ | Server / Client | JMS | 1.x - |
UI adaptations
Since tracing requires non-agent focused UI, we needed to make a compromise and create an intermediate state. This means that tracing view is agent-less view and as such must not be in the data explorer tree. We decided that for now access to the tracing view is via the data explorer toolbar.