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

feat: add client logging with slf4j #1586

Open
wants to merge 25 commits into
base: main
Choose a base branch
from
Open

feat: add client logging with slf4j #1586

wants to merge 25 commits into from

Conversation

zhumin8
Copy link
Contributor

@zhumin8 zhumin8 commented Dec 5, 2024

This is a draft pr for preview changes for adding client logging capability to auth.
see go/java-client-logging-design

Very limited testing added at this point.

changes includes:

  • add slf4j dependency, introduce LoggingConfigs to enable logging only when GOOGLE_SDK_JAVA_LOGGING=true
  • logging implementation depends on users binding added. If no binding, default to no-op.
  • introduce LoggingUtils for helper method for logging. Add log for request and response made to auth endpoints for UserCredentials, ServiceAccountCredentials, ComputeEngineCredentials, ImpersonatedCredentials. For token values included, added hash in log.

Here is an example logging output for access token request from UserCredentials when DEBUG level is allowed.

{"@timestamp":"2024-12-04T21:10:48.596382834-05:00","@version":"1","message":"Sending auth request to refresh access token.","logger_name":"com.google.auth.oauth2.UserCredentials","thread_name":"main","severity":"DEBUG","level_value":10000,"request.method":"POST","request.headers":"{x-goog-api-client=gl-java/19.0.1 auth/${project.parent.version} cred-type/u, accept-encoding=[gzip]}","request.url":"https://foo.com/bar","request.payload":"{refresh_token=1/Tl6*****yGWY, grant_type=refresh_token, client_secret=jakua*****wZcu, client_id=ya29.1.AADtN_UtlxN3PuGAxrN2XQnZTVRvDyVWnYq4I6dws}"}
{"@timestamp":"2024-12-04T21:10:48.624914522-05:00","@version":"1","message":"Received auth respond for refresh access token.","logger_name":"com.google.auth.oauth2.UserCredentials","thread_name":"main","severity":"INFO","level_value":20000,"response.status":"200","response.headers":"{}"}
{"@timestamp":"2024-12-04T21:10:48.627483862-05:00","@version":"1","message":"Auth response payload.","logger_name":"com.google.auth.oauth2.UserCredentials","thread_name":"main","severity":"DEBUG","level_value":10000,"access_token":"1/MkS*****KPY2","refresh_token":"1/Tl6*****yGWY","token_type":"Bearer","expires_in":"3600"}

Update Dec 9: I added basic test coverage, not showcasing all the logging messages details. Will add that as followup task.

@product-auto-label product-auto-label bot added the size: l Pull request size is large. label Dec 5, 2024
@zhumin8 zhumin8 requested a review from lqiu96 December 5, 2024 20:41
@zhumin8
Copy link
Contributor Author

zhumin8 commented Dec 5, 2024

@lqiu96 I still have some trouble with the test env, but wanted to put it out there so you can get a preview of the changes. Can you take a quick look and let me know if you have any concerns.

Comment on lines 147 to 149
LoggingUtils.logRequest(request, LOGGER, "auth sending request to get signature.");
HttpResponse response = request.execute();
LoggingUtils.logResponse(response, LOGGER, "auth received response for signature.");
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Could the message to be more descriptive? i.e. Signature to sign the blob or something that better describes this

logger.info(message);
// Default to INFO level
}
MDC.clear();
Copy link
Contributor

Choose a reason for hiding this comment

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

why does this need to be cleared?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

MDC carries contextual information in log messages. It is tied to thread, and is safer to clear it to avoid it be carried over to other log entries.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. Can you add that as a comment? Or a link to a guide that tells us clear it so future readers?

Comment on lines 494 to 498
private GenericData parseResponseAs(HttpResponse response) throws IOException {
GenericData genericData = response.parseAs(GenericData.class);
LoggingUtils.logGenericData(genericData, LOGGER, "Auth response payload.");
return genericData;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we move this to LoggingUtils since this seems to be used in the other credentials?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are slightly different, but I will try to extract any useful shared logics into LoggingUtils.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you highlight the difference? From what I see, the other Credentials also end up calling GenericData responseData = response.parseAs(GenericData.class); but this is moved to a function.

Might be missing something, but I don't see what is preventing this from going into LoggingUtils.

@product-auto-label product-auto-label bot added size: xl Pull request size is extra large. and removed size: l Pull request size is large. labels Dec 10, 2024
@zhumin8 zhumin8 marked this pull request as ready for review December 10, 2024 16:05
@zhumin8 zhumin8 requested review from a team as code owners December 10, 2024 16:05
@zhumin8 zhumin8 changed the title [draft] feat: add client logging feat: add client logging with slf4j Dec 10, 2024
@@ -36,6 +36,7 @@ jobs:
- run: .kokoro/build.sh
env:
JOB_TYPE: test
GOOGLE_SDK_JAVA_LOGGING: true
Copy link
Contributor Author

Choose a reason for hiding this comment

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

for next release: this env var is probably only needed for LoggingTest.java class.

@zhumin8
Copy link
Contributor Author

zhumin8 commented Dec 10, 2024

sonar has been failing since Dec 2. Filed
#1591

try {
if (logger.isInfoEnabled()) {
Map<String, String> loggingDataMap = new HashMap<>();
loggingDataMap.put("request.method", request.getRequestMethod());
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 good to duplicate information like request.method and request.url in message instead of always relying on MDC, as we discussed yesterday. It would be great if we can make this change in this release. However, if not, it should not be a blocker either, as adding these info later is not a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's already done. (9e20be9)
It is verified in LoggingTest (here you can see the message is parsed then verified. The test is not extensive in verifying information. )

// are payload always GenericData? If so, can parse and store in json
if (request.getContent() instanceof UrlEncodedContent) {

GenericData data = (GenericData) ((UrlEncodedContent) request.getContent()).getData();
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a quick comment about why UrlEncodedContent is casted to GenericData? But JsonHttpContent (below) doesn't need to be?

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

}
}

static void logGenericData(GenericData genericData, Logger logger, String message) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Can we change this to be something like logResponsePayload and parseResponsePayload so it's clearer as to what it's doing?

Comment on lines 494 to 498
private GenericData parseResponseAs(HttpResponse response) throws IOException {
GenericData genericData = response.parseAs(GenericData.class);
LoggingUtils.logGenericData(genericData, LOGGER, "Auth response payload");
return genericData;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

qq, isn't this the same thing as LoggingUtils.logGenericData()? I'm missing why this method needs to exist

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This response.parseAs(GenericData.class); can only be parsed once. So this is a wrapper to parse the data, log and continue with whatever is to do with the genericData.

Copy link
Contributor

Choose a reason for hiding this comment

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

Apologies, I might be missing something obvious but I'm not see where it's parsed more than once and might as be missing why it's different for ServiceAccountCredentials.

What I see is that it's changed to be:

GenericData responseData = parseResponseAs(response);

but I think it could just be

GenericData responseData = response.parseAs(GenericData.class);
LoggingUtils.logGenericData(responseData, LOGGER, "Auth response payload");
...

which is the same as it is for the other Credential types (i.e.

GenericData responseData = response.parseAs(GenericData.class);
LoggingUtils.logGenericData(
responseData, SLF4JLOGGER, "Response from refresh access token payload");
)

}
}

static void logResponse(HttpResponse response, Logger logger, String message) {
Copy link
Contributor

Choose a reason for hiding this comment

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

In general, I think we should not try to call these methods if logging is not enabled due to performance concerns, similar to the comment in sdk-platform-java.

responseLogDataMap.put("response.headers", headers.toString());
logWithMDC(logger, org.slf4j.event.Level.INFO, responseLogDataMap, message);
}
} catch (Exception e) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar to the comment in sdk-platform-java, I think we should try to avoid doing these try catches or fail more gracefully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: xl Pull request size is extra large.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants