From de4a0142a9b7f76a94902bf611877304f0dba182 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Tue, 14 Aug 2018 10:09:28 -0700 Subject: [PATCH 1/2] added ordering rationale: --- trace_context/HTTP_HEADER_FORMAT_RATIONALE.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md b/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md index c1974620..c520e21d 100644 --- a/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md +++ b/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md @@ -31,6 +31,17 @@ interfere with identification of the tracing system responsible for an entry. - The typical name will be a single word in latin and the value will be a copy of the `traceparent` format or an opaque string. +## Ordering of keys in `tracestate` + +Specification calls for ordering of values in tracestate. This requirements allows better interoperability between tracing vendors. + +Typical distributed trace is clustered - components calling each other often monitored +by the same tracing vendor. So information supplied by tracing system originated a +request will typically be less and less important deeper in distributed trace. Immediate +caller's information on other hand typically is more valuable as it is more likely being +monitored by the same tracing vendor. Thus it is logical to move immediate caller's +information to the beginning of the `tracestate` list. + ### Size limits #### Total size limit From 237d24954503b5bbbc4beeb5d2feb220c0fcb6be Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Tue, 14 Aug 2018 10:14:11 -0700 Subject: [PATCH 2/2] added perf and truncation justification --- trace_context/HTTP_HEADER_FORMAT_RATIONALE.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md b/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md index c520e21d..0af44eb1 100644 --- a/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md +++ b/trace_context/HTTP_HEADER_FORMAT_RATIONALE.md @@ -40,7 +40,12 @@ by the same tracing vendor. So information supplied by tracing system originated request will typically be less and less important deeper in distributed trace. Immediate caller's information on other hand typically is more valuable as it is more likely being monitored by the same tracing vendor. Thus it is logical to move immediate caller's -information to the beginning of the `tracestate` list. +information to the beginning of the `tracestate` list. So less important values will be +pushed to the end of the list. + +This prioritization of `tracestate` values improves performance of querying value of +tracestate - typically you only need a first pair. It also allows to meaningfully truncate +`tracestate` when required instead of dropping the entire list of values. ### Size limits