[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.

35 lines
1021 B

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";
package envoy.data.tap.v2alpha;
option java_outer_classname = "WrapperProto";
option java_multiple_files = true;
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
option java_package = "io.envoyproxy.envoy.data.tap.v2alpha";
import "envoy/data/tap/v2alpha/http.proto";
import "envoy/data/tap/v2alpha/transport.proto";
import "validate/validate.proto";
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
// [#protodoc-title: Tap data wrappers]
// Wrapper for all fully buffered and streamed tap traces that Envoy emits. This is required for
// sending traces over gRPC APIs or more easily persisting binary messages to files.
message TraceWrapper {
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
oneof trace {
option (validate.required) = true;
// An HTTP buffered tap trace.
HttpBufferedTrace http_buffered_trace = 1;
// An HTTP streamed tap trace segment.
HttpStreamedTraceSegment http_streamed_trace_segment = 2;
// A socket buffered tap trace.
SocketBufferedTrace socket_buffered_trace = 3;
// A socket streamed tap trace segment.
SocketStreamedTraceSegment socket_streamed_trace_segment = 4;
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
}
}