[READ ONLY MIRROR] Envoy REST/proto API definitions and documentation. (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

120 lines
4.1 KiB

tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
syntax = "proto3";
import "envoy/api/v2/route/route.proto";
import "validate/validate.proto";
package envoy.service.tap.v2alpha;
option java_package = "io.envoyproxy.envoy.service.tap.v2alpha";
// [#protodoc-title: Common tap configuration]
// Tap configuration.
message TapConfig {
// The match configuration. If the configuration matches the data source being tapped, a tap will
// occur, with the result written to the configured output.
MatchPredicate match_config = 1 [(validate.rules).message.required = true];
// The tap output configuration. If a match configuration matches a data source being tapped,
// a tap will occur and the data will be written to the configured output.
OutputConfig output_config = 2 [(validate.rules).message.required = true];
// [#comment:TODO(mattklein123): Rate limiting]
}
// Tap match configuration. This is a recursive structure which allows complex nested match
// configurations to be built using various logical operators.
message MatchPredicate {
// A set of match configurations used for logical operations.
message MatchSet {
// The list of rules that make up the set.
repeated MatchPredicate rules = 1 [(validate.rules).repeated .min_items = 2];
}
oneof rule {
option (validate.required) = true;
// A set that describes a logical OR. If any member of the set matches, the match configuration
// matches.
MatchSet or_match = 1;
// A set that describes a logical AND. If all members of the set match, the match configuration
// matches.
MatchSet and_match = 2;
// A negation match. The match configuration will match if the negated match condition matches.
MatchPredicate not_match = 3;
// The match configuration will always match.
bool any_match = 4 [(validate.rules).bool.const = true];
// HTTP request headers match configuration.
HttpHeadersMatch http_request_headers_match = 5;
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
// HTTP request trailers match configuration.
HttpHeadersMatch http_request_trailers_match = 6;
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
// HTTP response headers match configuration.
HttpHeadersMatch http_response_headers_match = 7;
// HTTP response trailers match configuration.
HttpHeadersMatch http_response_trailers_match = 8;
}
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
}
// HTTP headers match configuration.
message HttpHeadersMatch {
// HTTP headers to match.
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
repeated api.v2.route.HeaderMatcher headers = 1;
}
// Tap output configuration.
message OutputConfig {
// Output sinks for tap data. Currently a single sink is allowed in the list. Once multiple
// sink types are supported this constraint will be relaxed.
repeated OutputSink sinks = 1 [(validate.rules).repeated = {min_items: 1, max_items: 1}];
// [#comment:TODO(mattklein123): Output filtering. E.g., certain headers, truncated body, etc.]
}
// Tap output sink configuration.
message OutputSink {
oneof output_sink_type {
option (validate.required) = true;
// Tap output will be streamed out the :http:post:`/tap` admin endpoint.
//
// .. attention::
//
// It is only allowed to specify the streaming admin output sink if the tap is being
// configured from the :http:post:`/tap` admin endpoint. Thus, if an extension has
// been configured to receive tap configuration from some other source (e.g., static
// file, XDS, etc.) configuring the streaming admin output type will fail.
StreamingAdminSink streaming_admin = 1;
// Tap output will be written to a file per tap sink.
FilePerTapSink file_per_tap = 2;
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
}
}
// Streaming admin sink configuration.
message StreamingAdminSink {
}
// The file per tap sink outputs a discrete file for every tapped stream.
message FilePerTapSink {
// Path prefix. The output file will be of the form <path_prefix>_<id>.pb, where <id> is an
// identifier distinguishing the recorded trace for stream instances (the Envoy
// connection ID, HTTP stream ID, etc.).
string path_prefix = 1 [(validate.rules).string.min_bytes = 1];
// File format.
enum Format {
// Binary proto format.
PROTO_BINARY = 0;
// Text proto format.
PROTO_TEXT = 1;
}
Format format = 2 [(validate.rules).enum.defined_only = true];
}