-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
api: gRPC Access Log Service (ALS) sink #3078
Conversation
Signed-off-by: David Alger <davidmalger@gmail.com>
6772d1b
to
5b9ebea
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3078 +/- ##
==========================================
+ Coverage 66.51% 66.58% +0.07%
==========================================
Files 161 157 -4
Lines 22673 21956 -717
==========================================
- Hits 15080 14620 -460
+ Misses 6720 6494 -226
+ Partials 873 842 -31 ☔ View full report in Codecov by Sentry. |
api/v1alpha1/accesslogging_types.go
Outdated
// +optional | ||
// +kubebuilder:validation:MinLength=1 | ||
// +kubebuilder:default="accesslog" | ||
LogName string `json:"logName,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of asking users to specify the LogName
, can we generate this name in EG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since access log filters could be implemented in the future to send different logs to different places my preference would be to leave it a user-configurable 'friendly name' with a simple default of accesslog
so it's not mandatory.
If it were generated, we'd have to determine a way to differentiate between different log sinks on the same listener so the name would be useful to differentiate the logs in the receiver.
With the quickstart demo deployed locally, here is a portion of an example log entry generated by our ALS server:
"envoy_node": "envoy-default-eg-9fd49bdd-556b9fdf4864klx", // --service-node value from bootstrap
"envoy_version": "1.29.2",
"envoy_cluster": "default/eg", // --service-cluster value from bootstrap
"envoy_log_name": "accesslog", // logName value from CRD
"upstream_cluster": "httproute/default/backend/rule/0",
"route_name": "httproute/default/backend/rule/0/match/0/www_example_com"
Just to say that an EG generated name is already present, although missing the listener name.
Given this context and the possibility of arbitrary access log filters resulting in multiple sinks to the same logging service in the future, what are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation. Sounds reasonable for me to allow the user to specify the log name.
For the default name, probably add the listener name and the protocol? Like: lisetener1/http/accesslog
Signed-off-by: David Alger <davidmalger@gmail.com>
Signed-off-by: David Alger <davidmalger@gmail.com>
c03da7b
to
a32679e
Compare
Signed-off-by: David Alger <davidmalger@gmail.com>
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Defer to @arkodg
api/v1alpha1/accesslogging_types.go
Outdated
type ALSEnvoyProxyAccessLog struct { | ||
// BackendRef references a Kubernetes object that represents the gRPC service to which | ||
// the access logs will be sent. Currently only Service is supported. | ||
BackendRef gwapiv1.BackendObjectReference `json:"backendRef"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prefer if we wait another day or two to make sure #3091 has majority votes, and a decision is made, and that can be incorporated in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like there were enough votes to support pluralizing backendRefs
, suggest waiting on #3080 which is trying to create a common BackendRef
struct that all APIs can reuse
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good, thanks for the followup. will wait on that one to polish this one up
Signed-off-by: David Alger <davidmalger@gmail.com>
3581b97
to
dd46082
Compare
/retest |
/retest |
1 similar comment
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
// ResponseHeaders defines response headers to include in log entries sent to the access log service. | ||
// +optional | ||
ResponseHeaders []string `json:"responseHeaders,omitempty"` | ||
// ResponseTrailers defines response trailers to include in log entries sent to the access log service. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you have a use case for trailers atm ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks !
What type of PR is this?
API to support a gRPC Access Log Service (ALS) sink.
What this PR does / why we need it:
When implemented, a sink may be configured to send log messages to a gRPC stream with rich and strongly typed protobufs including all the details for the request.
We are using a lightweight gRPC logging service to post-process logs (ex: enrich with user session metadata) and then publish them to Stackdriver which in turn routes them to both BigQuery and Pub/Sub for further processing and long-term storage.
Currently we are relying on a patched bootstrap and two XDS patches on each listener to replace the default access logging config with an
HttpGrpcAccessLogConfig
, but would like to natively support this in theEnvoyProxy
CRD in order to keep configuration simple and not rely on having a Terraform configuredEnvoyPatchPolicy
for each listener on our Gateways.https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto