Use standard python logging facilities instead of printing to stdout

[saulbein]

Describe the feature you'd like
Currently, the library uses print() statements to print most logs from the framework itself, and also the ones it receives from models. If the library is used in, for example, a web service, it would be preferable to be able to use the standard python logging library to configure log levels, and be able to send the logs somewhere else than stdout.

How would this feature be used? Please describe.
This would allow the logging to be configured in a standard pythonic way. For example, if I wanted to redirect the logs to a file, I could attach a logging.FileHandler to the sagemaker logger, or alternatively sagemaker.session logger if I wanted to redirect only the session logs. It would also allow customizing the log format, and other features of the python logging module.

Describe alternatives you've considered
The current workaround I am using is to redirect all stdout text to a custom stream handler, which then re-prints them via logging. The problem with this is that I can not control log levels and formats, and if any other library prints to stdout it's output will also end up in the logs.

[metrizable]

@saulbein Thanks for the great suggestion!

[saulbein]

I've looked up if I would be able to do a PR myself, and it seems most of the print culprits are in session.py. The difficulty comes from the progress bar like behaviour of some actions, for example when creating a training job:

2020-07-02 10:00:41 Starting - Starting the training job...

The dots here are printed each poll, so they show up like this in logs:

2020-07-02 10:00:41 Starting - Starting the training job
.
.
.

The question then becomes either:

1. is this behaviour really necessary?
2. can we preserve this behaviour only when printing to the console, but ignore it when logging?

[metrizable]

off the top of my head, we have a few options:

1. define a logger as is typical elsewhere in the package and unilaterally convert every print() to a call to the logger
2. define a logger as is typical elsewhere in the package and judiciously refactor some print() statements to calls to the logger
3. define a new logger and attach a stream handler targeting sys.stdout, convert print() to calls to this logger

there are probably others that we can consider.

[saulbein]

Well, I would strongly prefer the first option - print is essentially the same as logging to stdout (which can be easily set up in cli, and it seems like jupyter sets up logging automatically, so not much work to do there as well). The only real difference is with polling / progress bars, since they would create separate messages for each 'tick'.

In my opinion the third option is a no go, since a stream handler will capture stdout output from other stuff, for example a user's print() statements.

I will try to get some PR done next week, to see how difficult the changes would be. As for the polling 'tick' text, maybe adding an option to disable it would be best? I would not want my logs to end up like this:

2020-07-02 10:00:41 Starting - Starting the training job
2020-07-02 10:00:46 .
2020-07-02 10:00:51 .
2020-07-02 10:00:56 .

[akrishna1995]

Thanks for opening this issue. The fix PR has been merged : #4133. Feel free to reopen if you have any issues - Thank you