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/Disable Ray Worker Logging via Toggle #47712

Open
Innixma opened this issue Sep 17, 2024 · 4 comments
Open

[Core] Enable/Disable Ray Worker Logging via Toggle #47712

Innixma opened this issue Sep 17, 2024 · 4 comments
Labels
core Issues that should be addressed in Ray Core enhancement Request for new feature and/or capability observability Issues related to the Ray Dashboard, Logging, Metrics, Tracing, and/or Profiling P1 Issue that should be fixed within a few weeks

Comments

@Innixma
Copy link

Innixma commented Sep 17, 2024

Description

I'd like to be able to enable/disable Ray worker logging via a repeatable toggle without needing to call ray.shutdown() followed by ray.init(log_to_driver=...), which takes a non-trivial amount of time.

Slack Thread on this Topic

Code Example: Colab

Note in the above code example, there is a private hack which allows to do this specifically for disabling ray logging. However, this is an irreversible process and logging cannot be re-enabled until ray.shutdown() is called, which isn't ideal.

Private Hack:

ray.init(log_to_driver=True)
# ray will log to driver

ray_private.ray­_logging.global­_worker­_stdstream­_dispatcher.remove­_handler("ray­_print­_logs")
# ray will not log to driver (irreversible)

I have implemented this private hack into AutoGluon to clean up our logging, but would prefer to have it be a toggle. Currently, if someone fits AutoGluon twice in a row, the 2nd fit call will never log with Ray. The only way to avoid it is to spend 7 seconds calling ray.shutdown().

Example Solution API:

ray.init(log_to_driver=True)
# ray will log to driver

ray.set_log_to_driver(False)
# ray will not log to driver

ray.set_log_to_drier(True)
# ray will log to driver

Use case

In AutoGluon, we have logic called DyStack which fits models in two phases. The first phase is in a ray subprocess to avoid memory leakage. We want to have ray logging in this phase so the user sees the output of the training. For the second phase, we fit models outside a ray subprocess, but still use ray for parallelizing tasks. In the second phase we don't want ray to produce logs, as it pollutes the log space and makes it harder to understand.

For an example of AutoGluon logging (using the ray private hack to fix logging), refer to the AutoGluon tutorial documentation in the Maximizing predictive performance cell and click "Show code cell output".

@Innixma Innixma added enhancement Request for new feature and/or capability triage Needs triage (eg: priority, bug/not-bug, and owning component) labels Sep 17, 2024
@nikhilbalwani
Copy link

I would love to have this feature as well. Thank you

@nikhilbalwani
Copy link

Hi guys, any updates on this? Thank you

@anyscalesam anyscalesam added the core Issues that should be addressed in Ray Core label Sep 24, 2024
@jjyao
Copy link
Collaborator

jjyao commented Oct 7, 2024

@nikhilbalwani what's your use case? Why do you need it?

@jjyao jjyao added observability Issues related to the Ray Dashboard, Logging, Metrics, Tracing, and/or Profiling P1 Issue that should be fixed within a few weeks and removed triage Needs triage (eg: priority, bug/not-bug, and owning component) labels Oct 7, 2024
@nikhilbalwani
Copy link

I am working on a package where i need to decide at runtime whether or not to enable/disable logging to the worker. At the same time I don't want to use _private ray APIs to achieve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues that should be addressed in Ray Core enhancement Request for new feature and/or capability observability Issues related to the Ray Dashboard, Logging, Metrics, Tracing, and/or Profiling P1 Issue that should be fixed within a few weeks
Projects
None yet
Development

No branches or pull requests

4 participants