Skip to content
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

Merged
merged 15 commits into from
Mar 10, 2023
Merged

Conversation

paul-r-gall
Copy link
Contributor

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:]

Signed-off-by: Paul Gallagher <pgal@google.com>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #25824 was opened by paul-r-gall.

see: more, trace.

// 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
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Contributor Author

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.

@repokitteh-read-only
Copy link

https://github.com/orgs/envoyproxy/teams/first-pass-reviewers assignee is @None

🐱

Caused by: a #25824 (comment) was created by @paul-r-gall.

see: more, trace.

@paul-r-gall
Copy link
Contributor Author

/assign-from @envoyproxy/first-pass-reviewers

@repokitteh-read-only
Copy link

@envoyproxy/first-pass-reviewers assignee is @tonya11en

🐱

Caused by: a #25824 (comment) was created by @paul-r-gall.

see: more, trace.

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>
@mattklein123 mattklein123 assigned kyessenov and unassigned tonya11en Mar 2, 2023
Copy link
Member

@mattklein123 mattklein123 left a 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>
// 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.
Copy link
Contributor

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 and onDestroy.
  • 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.

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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>
@paul-r-gall paul-r-gall requested a review from lizan as a code owner March 6, 2023 13:55
@mattklein123 mattklein123 removed their assignment Mar 6, 2023
Signed-off-by: Paul Gallagher <pgal@google.com>
Signed-off-by: Paul Gallagher <pgal@google.com>
Copy link
Contributor

@kyessenov kyessenov left a 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

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.
Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor Author

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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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()) {
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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>
kyessenov
kyessenov previously approved these changes Mar 9, 2023
Copy link
Contributor

@kyessenov kyessenov left a 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.

wbpcode
wbpcode previously approved these changes Mar 10, 2023
Copy link
Member

@wbpcode wbpcode left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks.

@wbpcode
Copy link
Member

wbpcode commented Mar 10, 2023

Please resolve the conflict first, then we can merge this patch. Thanks. 😄

Signed-off-by: Paul Gallagher <pgal@google.com>
@paul-r-gall paul-r-gall dismissed stale reviews from wbpcode and kyessenov via 9da04aa March 10, 2023 16:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants