Hi
Currently the concept of a Property is associated with a trace fragment in the APM model.
The fragment represents is the root object of the call trace that occurs within a
particular service. So an end to end trace is comprised of a set of fragments captured
from the various services that were involved in the execution of a particular business
transaction.
The reason for associating the Property with the fragment initially was that these
properties represented contextual information extracted from the message contents (or
headers) that could be used to search for the relevant trace (business transaction)
instance. So for example, the "order id" may be extracted and then associated
with the fragment, which would then subsequently become associated with the end to end
call trace.
However zipkin and the opentracing standard are based on the concept of spans, which
represent particular points in the trace - and don't have an equivalent
'fragment' concept. Therefore all 'properties' (binary annotations in
zipkin, tags in opentracing) are associated with each instrumentation point (node in APM
model). This is also because the information they record in binary annotations/tags is not
necessarily business contextual information, but can also be lower level.
So we are considering moving the APM Property concept to the Node instead of Trace
fragment, to align more with zipkin/opentracing. However when querying the various data
types in APM, the properties would still be aggregated as before, the only difference is
that the finer grained association between Node and Property will now be maintained.
Let me know if this is an issue for anyone.
Regards
Gary