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

✨ Add metadata filter support for context logger #297

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

gkumbhat
Copy link
Member

@gkumbhat gkumbhat commented Jun 6, 2023

Description

What does this PR do?

Changes

What changes are included in this PR?

Testing

How did you test this PR?

Related Issue(s)

List any issues related to this PR

Copy link
Collaborator

@gabe-l-hart gabe-l-hart left a comment

Choose a reason for hiding this comment

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

Thanks for putting this together @gkumbhat! I think we want to look carefully at LoggerAdapter instead of logging.Filter, and I think the naming could be cleaned up a little. Also, it's probably worth using a separate scope object rather than just ScopedLog since that's explicitly designed to add Start/End blocks. Something like ScopedMetadata.

@@ -577,6 +594,19 @@ def use_channel(channel):
"""
return logging.getLogger(channel)

## Logger Filters ##############################################################
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmmm, this is interesting. I have two reactions to this:

  1. I don't think this is what logging.Filter is meant to do. I think LogAdapter is probably the more correct utility for this type of contextual information.
  2. This makes me think that some of the alog functionality around filtering should be refactored to use logging.Filter in a more standard way

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried to use LogAdapter, however, but it modifies the logger which is read only inside _ScopedLog

Copy link
Member Author

Choose a reason for hiding this comment

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

Filters are also designed / recommended for this use-case it seems: https://docs.python.org/3/howto/logging-cookbook.html#filters-contextual

Copy link
Member Author

Choose a reason for hiding this comment

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

This makes me think that some of the alog functionality around filtering should be refactored to use logging.Filter in a more standard way

I was thinking same while exploring adapters and filtering.

Copy link
Member Author

@gkumbhat gkumbhat Jun 7, 2023

Choose a reason for hiding this comment

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

Also current implementation isn't thread safe. I think for it to be threadsafe, I'll need to save this metadata in a threadlng.local based class object similar to how we do it for indent. Was wondering if there would be any concerns for that?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, this is the nastiest part IMO. I think we'd want some careful threading behavior:

  • Independent threads manage independent metadata contexts
  • Spawned threads inherit context metadata from parents
  • Closing a metadata scope removes the metadata from the thread where the scope was created
    • I'm honestly not sure what should happen to threads spawned by this parent thread while the scope was open

Also, the same behavior should probably be true of spawned processes

@@ -177,6 +177,9 @@ def format(self, record):
else:
log_record['message'] = str(record_args)

if hasattr(record, "additional_ctxt_metadata"):
Copy link
Collaborator

Choose a reason for hiding this comment

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

If we're going to have a "special" string for this, I think it should be (a) a constant, and (b) a __dunder__ name

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, certainly. Will update the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants