api: model edge and middle proxies in tracing configurations

[kyessenov]

Reference: #7723

The existing traffic direction configuration provides two options: ingress and egress.
For Envoy deployed as a middle or an edge proxy, there is no guideline for setting this option.
The option affects the behavior of the tracing engine (e.g. whether to open or close a span).
Edge/middle (which are sometimes combined) may perform at least two distinct actions in the context of distributed tracing:

• be transparent, pass-through tracing contexts as-is;
• break the span into two, close the existing span and open a new one.

This is a request to extend the API with ability to control tracing behavior for the middle/edge proxies.

/cc @objectiser @htuch

[objectiser]

@kyessenov I think I need more context about what a "middle/edge" proxy is?

For example in Istio there is currently a proxy associated with each of the Ingress and Egress gateways, and also a proxy associated with workloads that trace inbound & outbound traffic from that workload.

How does the concepts of middle and edge proxy relate to this example - or are they different?

[kyessenov]

Gateway proxy would be an example, or a k8s ingress proxy. It is any proxy that is not directly associated with a user workload. Istio models gateways as a client proxy for the mesh (all requests are marked as inbound), but it has a problem that requests coming from inside the mesh to the gateway are not represented properly.

[objectiser]

Ok thanks for the explanation.

I think one of the issues is the use of Ingress/Egress concepts in envoy vs as a mesh ingress/egress in something like Istio.

As part of #7723, maybe it would be a good idea to have the re-named traffic direction values of Inbound and Outbound, instead of Ingress and Egress.

Then to address your requirement, if we had a "traffic direction" value of "Gateway" - it could be used to generate two spans within the proxy, a server span to represent the received request and client span to represent the forwarded request (generated in the router filter). Actually it was something I was exploring back in #2081 (comment) (option c).

Might mean a better name is required for "traffic direction", but could have four values: Inbound (server span), Outbound (client span), Gateway (server and client spans) and PassThrough (no spans).

[mattklein123]

Complete

[objectiser]

@mattklein123 not sure this is complete - #7723 only deals with the Inbound and Outbound cases. Do we want to leave this open to further discuss and possibly implement the Gateway and PassThrough cases?

[htuch]

+1, I'm going to reopen, happy to close out if this is really solved somewhere though.

[mattklein123]

Sorry for closing too early, SGTM.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.