Skip to content

tracing: Add config support for a Tracing Decorator to enable operati…#170

Closed
objectiser wants to merge 1 commit intoenvoyproxy:masterfrom
objectiser:decorator
Closed

tracing: Add config support for a Tracing Decorator to enable operati…#170
objectiser wants to merge 1 commit intoenvoyproxy:masterfrom
objectiser:decorator

Conversation

@objectiser
Copy link
Copy Markdown
Contributor

…on name to be specified for matched criteria

Definitions associated with envoyproxy/envoy#1527

…on name to be specified for matched criteria

// If specified, this is a regular expression match on the :path header
// once the query string is removed.
string regex = 3;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently a placeholder, as in RouteMatch.

oneof path_specifier {
// If specified, this is a prefix rule meaning that the prefix must
// match the beginning of the :path header.
string prefix = 1;
Copy link
Copy Markdown
Member

@htuch htuch Sep 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, but does this need to be independent to the existing https://github.com/lyft/envoy-api/blob/master/api/rds.proto#L67 RouteMatch message? Can we attach a Decorator to a Route https://github.com/lyft/envoy-api/blob/master/api/rds.proto#L288 instead?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So for example?

                  "routes": [
                    {
                      "timeout_ms": 0,
                      "prefix": "/trace",
                      "cluster": "service2",
                      "method": "GET",
                      "operation": "getTrace"
                    }
                  ]

Then the method would become part of the routing criteria and potentially a route would need to be defined for each REST endpoint.
If that is the preference, then I could look at changing - but would be good to get opinions from others?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the user is going to have to basically build a route table inside the tracing config, why not just build a more specific route table as you demonstrate above, and just allow specifying an operation name on the route. (This could be used in the future for stats, logging, and other things potentially).

That seems better to me and more future proof. Any reason not to do that?

If we don't want to do that, I think we could probably move RouteMatch message out and use it in both places. (Note that you don't need to have a method specific match. You can do a header match on the :method header).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok will rework to add to Route - will close this PR and reopen with new version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants