Go to the source code of this file.
|
#define | OPENTRACINGC_CHILD_OF(span_context) |
|
#define | OPENTRACINGC_FOLLOWS_FROM(span_context) |
|
◆ OPENTRACINGC_CHILD_OF
#define OPENTRACINGC_CHILD_OF |
( |
|
span_context | ) |
|
Value:{ \
opentracing_span_reference_child_of, &(span_context) \
}
◆ OPENTRACINGC_FOLLOWS_FROM
#define OPENTRACINGC_FOLLOWS_FROM |
( |
|
span_context | ) |
|
Value:{ \
opentracing_span_reference_follows_from, &(span_context) \
}
◆ opentracing_span_context
Span context interface.
Span context represents span state that must be propagated to descendant spans and across boundaries (e.g. trace I:D, span ID, baggage).
◆ opentracing_span_reference_type
Enumerator |
---|
opentracing_span_reference_child_of | Refers to a parent span that caused and somehow depends upon the new child span.
Often (but not always), the parent span cannot finish until the child span does.
|
opentracing_span_reference_follows_from | Refers to a parent span that does not depend in any way on the result of the new child span.
For instance, one might use "follow from" to describe pipeline stages separated by queues, or a fire-and-forget cache insert at the tail end of a web request.
A "follow from" span is part of the same logical trace as the new span: i.e., the new span is somehow caused by the work of its "follow from."
All of the following could be valid timing diagrams for children that "follow from" a parent. [-Parent Span-] [-Child Span-]
[-Parent Span--]
[-Child Span-]
[-Parent Span-]
[-Child Span-]
See http://opentracing.io/spec/
|