...
- 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
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.