A logging level classifies message severity and controls which events an application emits. Unlike scattered print statements, levels let development capture detailed execution information while production suppresses debug noise without removing diagnostic code. section 7.8 section 12.2.3
Python logging orders levels from NOTSET through CRITICAL and uses the configured level as a filter:
- DEBUG records detailed development information; setting the threshold to DEBUG admits DEBUG messages and more severe messages. section 7.8.1
- INFO admits informational messages and higher-severity messages while ignoring DEBUG output, making it suitable for production configuration. section 7.8.1
- The level can be applied to loggers and handlers, while formatters provide consistent, chronological output to destinations such as standard output. section 7.8 section 7.8.1
Development versus production
An application can leave logger.debug("rendering home page") and logger.debug("rendering about page") in its route code. Development sets logging_level to DEBUG to show these events; production sets it to INFO so the statements remain available for future diagnosis but stay out of normal logs. section 7.8.1 section 12.2.3
def _configure_logging(app, dynaconf):
logging_config_path = Path(app.root_path).parent / "logging_config.yaml"
with open(logging_config_path, "r") as fh:
logging_config = yaml.safe_load(fh.read())
env_logging_level = dynaconf.settings.get(
"logging_level", "INFO"
).upper()
logging_level = logging.INFO
if env_logging_level == "INFO"
else logging.DEBUG
logging_config["handlers"]["console"]["level"] = logging_level
logging_config["loggers"][""]["level"] = logging_level
logging.config.dictConfig(logging_config)
Use the configuration listing to trace how an environment setting becomes a numeric logging threshold for the console handler and root logger. section 7.8.1
