-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
http: periodic HCM access logs #25824
Conversation
Signed-off-by: Paul Gallagher <pgal@google.com>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
// at the specified interval. This is especially useful in the case of long-lived requests, such as | ||
// CONNECT and Websockets. | ||
// The interval must be at least 1 second. | ||
google.protobuf.Duration access_log_flush_interval = 53 |
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.
I think it would be useful to log on stream open/close as well.
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.
stream close is already logged via the normal process, right?
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.
Yeah, but it's not clear from the description. Stream open is certainly useful for long running operations.
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.
This was supported in the TCP proxy. It would be better to keep both fields have similar behavior.
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/tcp_proxy/v3/tcp_proxy.proto
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.
Added comment clarifying the stream close, as well as adjusted the min duration to 1ms to align w/ TCP Proxy.
https://github.com/orgs/envoyproxy/teams/first-pass-reviewers assignee is @None |
/assign-from @envoyproxy/first-pass-reviewers |
@envoyproxy/first-pass-reviewers assignee is @tonya11en |
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
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.
This will need a release note. I'm not sure what is done in TCP proxy, but is there any clear way to understand whether the log is an interval log vs. the final log? If so I might also make that clear in the API field description.
/wait
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
// logs periodically at the specified interval. This is especially useful in the case of long-lived | ||
// requests, such as CONNECT and Websockets. Final access logs can be detected via the | ||
// `requestComplete()` method of `StreamInfo`. | ||
// The interval must be at least 1 millisecond. |
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.
I mentioned this privately - but I'm a bit concerned about the unexpected filter interactions. I think some filters register for onLog
as some sort of end-of-stream signal. Wasm, for example. Once they start getting multiple calls, they might do something weird. There are two ways I can think of:
- make filters deal with it, there are other callbacks
onStreamComplete
andonDestroy
. - make this setting finer grained, e.g. per access log formatter.
If we go with this change (option 1), we should warn downstream projects about a possible bad interaction.
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.
Yeah that's a good point. With that said, this is an opt-in feature so maybe it's ok while we sort out issues like that? I could go either way.
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.
Yeah, I think this is a good feature so we should bring it in. Mostly concerned about how to minimize disruption.
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.
I updated the comment, and the changelog description, in addition to adding a check in the WASM filter.
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
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.
Getting close to completing, just a few more comments.
/wait
changelogs/current.yaml
Outdated
change: | | ||
add :ref:`periodic access logging <envoy_v3_api_field_extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.access_log_flush_interval>` | ||
to http access logs for long-lived requests (Websockets, CONNECT, etc). :ref:`%DURATION% <config_access_log_format_duration>` will | ||
be empty for mid-request logs. Enabling this may affect access loggers that expect to be called only once. |
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.
_ and filters that register as access loggers_
StreamInfo::MockStreamInfo log_stream_info; | ||
EXPECT_CALL(log_stream_info, requestComplete()).WillRepeatedly(testing::Return(absl::nullopt)); | ||
filter().log(&request_headers, nullptr, nullptr, log_stream_info); |
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.
Not sure this actually checks that Wasm log() is not called here? Is this the same check as for regular access log?
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.
Added a clarifying EXPECT_CALL(...).Times(0);
filter->callbacks_->encodeHeaders(std::move(response_headers), true, "details"); | ||
} | ||
|
||
TEST_F(HttpConnectionManagerImplTest, TestNoPeriodicAccessLoggingWithRequestComplete) { |
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.
Not sure what this test does that's different from above, can you elaborate?
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.
Removed this test -- I was trying to get a test going that makes the timer go off in a race-condition way with the stream being completed, but couldn't quite figure out how to do it.
@@ -1457,6 +1457,11 @@ void Context::log(const Http::RequestHeaderMap* request_headers, | |||
const Http::ResponseHeaderMap* response_headers, | |||
const Http::ResponseTrailerMap* response_trailers, | |||
const StreamInfo::StreamInfo& stream_info) { | |||
// `log` may be called multiple times due to mid-request logging -- we only want to run on the | |||
// last call. | |||
if (!stream_info.requestComplete().has_value()) { |
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.
I think we'll probably want Wasm access logs to conform, just not Wasm HTTP filters. Both share the code, so I imagine it's tricky to untangle. Maybe leave a comment or issue for later.
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.
Not sure what you mean -- i.e. the access logger should have the ability to write mid-connection logs, but the filter should not?
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.
Yeah, there are two different extension points - Wasm HTTP filters and Wasm access loggers. I guess it makes sense to make them both support periodic reporting at the same time, rather than just Wasm access loggers.
Signed-off-by: Paul Gallagher <pgal@google.com>
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
Would be good to get a non-Googler take a look at the core code as well.
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.
Please resolve the conflict first, then we can merge this patch. Thanks. 😄 |
Signed-off-by: Paul Gallagher <pgal@google.com>
Commit Message: http: periodic HCM access logs
Additional Description: Make it possible to log periodically from the HCM. This parallels the work already done in TcpProxy.
Risk Level: low
Testing: unit tests.
Docs Changes: none
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]