-
Notifications
You must be signed in to change notification settings - Fork 31
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
Setup log level depending of the environment #1096
Conversation
Tangential question on logging that seeing "don't run debug in prod" made me think of: if we did need to run debug in prod (say there's a major incident that we need to resolve), what would it take to enable debug logs? Would we have to restart the gateway (and if so, what are the consequences of doing that)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there ever a case where we'd want to run with log level other than DEBUG or WARNING? I'm going to assume not (you opened the issue, so you would know 😄 ), and if we did need to run in INFO it wouldn't be too difficult to update later on.
It may be easier to understand to expose all log levels (instead of DEBUG 0 or 1) but this may be good for now because it requires minimum changes. |
Yep, it's one of the things that I was thinking meanwhile I was developing it. If all of you agree that it should have a dedicated environment I can change it. My assumption was that most of the time the configuration will be:
And we could afford one environment to take care. If you think that we can have an use case where we are going to need more granularity I'm open to change it.
Currently yeah, we need to restart the application. We have all the previous logs stored though. But I assume that it will happen with every environment that we need to change currently. |
Initially no, to be honest. Or I don't see an use case where we are going to need to see all the logs without activate the |
Assuming restarting gateway / scheduler is totally fine and wouldn't impact running jobs? |
Thinking in loud right now. So let's take my words carefully but the problematic points would be:
We could find bad situations but it could affect to one job or so. It should not have bigger implications. The jobs running should not be affected by the restart of the gateway or the scheduler if they are just running in the ray-cluster. |
Summary
Fix #727 . This PR setup different levels of logging depending of the
DEBUG
mode.Details and comments
DEBUG=1
the gateway will print all the logs availableDEBUG=0
the gateway will print the logs from "WARNING" and above (ref: here)In this case instead to add a new environment variable to manage the logs independently I opted for a way where the log level depends on the
DEBUG
mode to avoid to add more environment variables.