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

[Core] Enable Users to Configure Python Standard Log Attributes #49871

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

MengjinYan
Copy link
Collaborator

@MengjinYan MengjinYan commented Jan 15, 2025

Why are these changes needed?

This PR enables user to configure a list of additional standard python logging attributes so that the fields can be included in the log recored in for both plain text and structured logging.

It adds an additional field addl_log_std_attrs in the existing ray.LoggingConfig. The addl_log_std_attrs takes in a list of field names and add the fields & its value to the log line when formatting the log line.

Corresponding tests are added as well.

Related issue number

#49502

Checks

  • I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
    • I've added any new APIs to the API Reference. For example, if I added a
      method in Tune, I've added it in doc/source/tune/api/ under the
      corresponding .rst file.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

@MengjinYan MengjinYan added the go add ONLY when ready to merge, run all tests label Jan 21, 2025
@MengjinYan MengjinYan requested review from kevin85421, jjyao and rynewang and removed request for kevin85421 January 21, 2025 17:08
Comment on lines +25 to +26
# Should be marked as @abstractmethod, but we can't do that because of backwards
# compatibility.
Copy link
Collaborator

Choose a reason for hiding this comment

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

We don't need to consider backward compatibility here as LoggingConfigurator is not a public thing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Unfortunately, we need to consider the backward compatibility here because rayturbo extend this class as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then can we just add the extra param to it?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Rayturbo we can change as well so it's not an issue.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's right. The only thing is if we add the @abstractmethod now, the build will fail after the the PR merged to RayTurbo because the configurator class in RayTurbo doesn't have the method override.

To solve this, I'm planning to have 2 followup PRs:
(1) After the current PR is merged to RayTurbo, I'll update the the configurator class in RayTurbo, override configure_logging_settings function and remove the previous configure_logging function
(2) Update OSS to cleanup the configure_logging function and add @abstractmethod to the configure_logging_settings function to only keep the new function.

In this sense, we can migrate all the configure_logging with configs listed in function parameters to configure_logging_settings function with configs in the data class.

@@ -17,9 +18,17 @@ def get_supported_encodings(self) -> Set[str]:
raise NotImplementedError

@abstractmethod
@Deprecated
Copy link
Collaborator

Choose a reason for hiding this comment

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

why deprecating this one?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm thinking as we add one more field in the config, we should make sure all log fields are configured. So deprecating the previous function that only takes in 2 fields.

{
"encoding": encoding,
"log_level": log_level,
"addl_log_std_attrs": [],
Copy link
Collaborator

Choose a reason for hiding this comment

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

what's addl?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

addl means "additional". As suggested by Ruiyang above, I'll update to whole word to avoid confusion

…_standard_attrs; (2) add LoggingConfigData to pass the parameters to LoggingConfigurator; (3) Update the new method name in LoggingConfigurator to avoid duplicate function name; (4) Add more commens

Signed-off-by: Mengjin Yan <[email protected]>
class LoggingConfigData:
encoding: str
log_level: str
additional_log_standard_attrs: list
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need 2 separate classes: LoggingConfigData and LoggingConfig? I mean, can we just pass the public LoggingConfig to the Configurator?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We can't because otherwise, there will be circular dependency between LoggingConfig and LoggingConfigurator.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you tell me more about the circular dependency?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Synced offline. Will leverage the python's forward declaration for types to avoid adding an additional LoggingConfigData class.

python/ray/_private/ray_logging/logging_config.py Outdated Show resolved Hide resolved
record_format_attrs[LogKey.TIMESTAMP_NS.value] = record_format_attrs.pop(
INTERNAL_TIMESTAMP_LOG_KEY
)
class AbstractFormatter(logging.Formatter, ABC):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't see any abstract methods

class LoggingConfigData:
encoding: str
log_level: str
additional_log_standard_attrs: list
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you tell me more about the circular dependency?

…eak circular depencency; 2. add format as the abstract method in AbstractFormatter

Signed-off-by: Mengjin Yan <[email protected]>
Signed-off-by: Mengjin Yan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go add ONLY when ready to merge, run all tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants