Docs: docs to cover x-ot-span-context header#521
Conversation
| _________________ | ||
|
|
||
| The *x-ot-span-context* HTTP header is used by Envoy to establish proper parent-child relationships | ||
| between tracing spans. Envoy relies on data from *x-ot-span-context* header to extract the parent |
| The *x-ot-span-context* HTTP header is used by Envoy to establish proper parent-child relationships | ||
| between tracing spans. Envoy relies on data from *x-ot-span-context* header to extract the parent | ||
| context for the current span. For example, an egress span is a child of ingress span (if there was an ingress call). | ||
| Envoy injects the *x-ot-span-context* header on ingress call and passes it to the local service and |
There was a problem hiding this comment.
I think this sentence is too long. I would say:
Envoy injects the x-ot-span-context header on ingress requests and forwards it in the request to the local service. Envoy relies on the application to propagate x-ot-span-context on the egress call to an upstream.
| See more on tracing :ref:`here <arch_overview_tracing>`. | ||
| between tracing spans. Envoy relies on data from the *x-ot-span-context* header to extract the parent | ||
| context for the current span. For example, an egress span is a child of an ingress | ||
| span (if there was the ingress span). Envoy injects the *x-ot-span-context* header on ingress requests and |
There was a problem hiding this comment.
should be "the" as I've already mentioned that span in "child of an ingress span"
There was a problem hiding this comment.
Sure, but if there was ... is not correct with the. You could say (if the ingress span was present). I think the likely explanation for the phrase not working with the, is that the phrase expresses ambiguity of existence even though the object is explicit in the rest of the sentence.
There was a problem hiding this comment.
But I am not a linguist, so my favored explanation is that it doesn't sound right with the :)
There was a problem hiding this comment.
i'll redo to avoid confusion :)
|
|
||
| .. _config_http_conn_man_headers_x-ot-span-context: | ||
|
|
||
| x-ot-span-context |
There was a problem hiding this comment.
Is it worth documenting that the actual format of this is base64 "binary OT carrier?" This is quite LS specific currently. I guess I would probably mention that this is LS specific and when Zipkin support is added we can update the docs to cover the differences between the 2 providers.
There was a problem hiding this comment.
Yup, it def makes sense and it's LS specific
envoyproxy#521) * Move control of the in-VM context lifecycle to the host specific code. Signed-off-by: John Plevyak <jplevyak@gmail.com>
Updates to utilize the options exposed in envoyproxy/envoy-mobile#520 to prevent unnecessarily buffering requests that will never be retried. This can be especially useful for preventing buffering of long-lived [gRPC] streams, for example. We discussed having a full fledged platform level struct to parallel `envoy_stream_options`, but decided that while we only expose one option we can leave the API as a boolean argument. Matching Android functionality is being tracked here: envoyproxy/envoy-mobile#524. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Description: android parallel to #521. Risk Level: low - matching ios functionality Testing: unit tests Signed-off-by: Jose Nino <jnino@lyft.com> Signed-off-by: JP Simard <jp@jpsim.com>
Updates to utilize the options exposed in envoyproxy/envoy-mobile#520 to prevent unnecessarily buffering requests that will never be retried. This can be especially useful for preventing buffering of long-lived [gRPC] streams, for example. We discussed having a full fledged platform level struct to parallel `envoy_stream_options`, but decided that while we only expose one option we can leave the API as a boolean argument. Matching Android functionality is being tracked here: envoyproxy/envoy-mobile#524. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Description: android parallel to #521. Risk Level: low - matching ios functionality Testing: unit tests Signed-off-by: Jose Nino <jnino@lyft.com> Signed-off-by: JP Simard <jp@jpsim.com>
No description provided.