The Common Trace API (CTA) is an interface-based specification of a common trace representation to allow a monitoring-tool-format-independent access of trace data. The CTA supports the exchange of monitoring data between stakeholders (e.g., Ops and Dev, or different research groups) while the consumer accesses the data with the CTA.
Implementations of the CTA can be tool- and case-specific. However the following points should be considered:
- The target application that uses the trace data provided by a certain monitoring tool needs access to the specific implementation (i.e. Java Classes) of the CTA.
- Whether a certain CTA implementation directly contains all trace information within the implementation objects, or whether the CTA implementation uses lazy loading to calculate the information from a third source is up to the implementation. However, in the case when trace data is (CTA Implementation objects) are transferred remotely, lazy loading may become a problem as the underlying data source may be gone. This needs to be kept in mind when providing implementations for the CTA.
A trace that traverses multiple locations is divided into subtraces. Hence, a subtrace is identified by the Location tuple (Host (e.g. IP), Container(e.g. JVM Id), Application Id, Business Transaction Id). Subtraces are structured along a composite pattern (tree structure). In this way, subtraces provide a coarse-grained view on the logical trace. A subtrace, in turn, contains a tree of Callables, hence, a trace covering one Location.
JavaDoc
Interface Diagram
Support
You can request new Features and report experienced Bugs in our JIRA. We are pleased to improve CTA daily and appreciate any feedback.