Django provides a working default logging configuration that is readily extended.
\nTo send a log message from within your code, you place a logging call into it.
\n\nFirst, import the Python logging library, and then obtain a logger instance\nwith logging.getLogger(). Provide the getLogger() method with a\nname to identify it and the records it emits. A good option is to use\n__name__ (see Use logger namespacing below for more on this) which will\nprovide the name of the current Python module as a dotted path:
import logging\n\nlogger = logging.getLogger(__name__)\nIt’s a good convention to perform this declaration at module level.
\nAnd then in a function, for example in a view, send a record to the logger:
\ndef some_view(request):\n ...\n if some_risky_state:\n logger.warning("Platform is running at risk")\nWhen this code is executed, a LogRecord containing that\nmessage will be sent to the logger. If you’re using Django’s default logging\nconfiguration, the message will appear in the console.
The WARNING level used in the example above is one of several\nlogging severity levels: DEBUG,\nINFO, WARNING, ERROR, CRITICAL. So, another example might be:
logger.critical("Payment system is not responding")\nAlthough Django’s logging configuration works out of the box, you can control\nexactly how your logs are sent to various destinations - to log files, external\nservices, email and so on - with some additional configuration.
\nYou can configure:
\nlogger mappings, to determine which records are sent to which handlers
handlers, to determine what they do with the records they receive
filters, to provide additional control over the transfer of records, and\neven modify records in-place
formatters, to convert LogRecord objects to a string or\nother form for consumption by human beings or another system
There are various ways of configuring logging. In Django, the\nLOGGING setting is most commonly used. The setting uses the\ndictConfig format, and extends the\ndefault logging configuration.
See Configuring logging for an explanation of how your custom settings\nare merged with Django’s defaults.
\nSee the Python logging documentation for\ndetails of other ways of configuring logging. For the sake of simplicity, this\ndocumentation will only consider configuration via the LOGGING setting.
When configuring logging, it makes sense to
\nLOGGING dictionaryLink to this heading#In your settings.py:
LOGGING = {\n "version": 1, # the dictConfig format version\n "disable_existing_loggers": False, # retain the default loggers\n}\nIt nearly always makes sense to retain and extend the default logging\nconfiguration by setting disable_existing_loggers to False.
This example configures a single handler named file, that uses Python’s\nFileHandler to save logs of level DEBUG and higher to the\nfile general.log (at the project root):
LOGGING = {\n # ...\n "handlers": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n },\n },\n}\nDifferent handler classes take different configuration options. For more\ninformation on available handler classes, see the\nAdminEmailHandler provided by Django and the various\nhandler classes provided by Python.
Logging levels can also be set on the handlers (by default, they accept log\nmessages of all levels). Using the example above, adding:
\n{\n "class": "logging.FileHandler",\n "filename": "general.log",\n "level": "DEBUG",\n}\nwould define a handler configuration that only accepts records of level\nDEBUG and higher.
To send records to this handler, configure a logger mapping to use it for\nexample:
\nLOGGING = {\n # ...\n "loggers": {\n "": {\n "level": "DEBUG",\n "handlers": ["file"],\n },\n },\n}\nThe mapping’s name determines which log records it will process. This\nconfiguration ('') is unnamed. That means that it will process records\nfrom all loggers (see Use logger namespacing below on how to use the mapping\nname to determine the loggers for which it will process records).
It will forward messages of levels DEBUG and higher to the handler named\nfile.
Note that a logger can forward messages to multiple handlers, so the relation\nbetween loggers and handlers is many-to-many.
\nIf you execute:
\nlogger.debug("Attempting to connect to API")\nin your code, you will find that message in the file general.log in the\nroot of the project.
By default, the final log output contains the message part of each log\nrecord. Use a formatter if you want to include additional\ndata. First name and define your formatters - this example defines\nformatters named verbose and simple:
LOGGING = {\n # ...\n "formatters": {\n "verbose": {\n "format": "{name} {levelname} {asctime} {module} {process:d} {thread:d} {message}",\n "style": "{",\n },\n "simple": {\n "format": "{levelname} {message}",\n "style": "{",\n },\n },\n}\nThe style keyword allows you to specify { for str.format() or\n$ for string.Template formatting; the default is $.
See LogRecord attributes for the LogRecord attributes\nyou can include.
To apply a formatter to a handler, add a formatter entry to the handler’s\ndictionary referring to the formatter by name, for example:
"handlers": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n "formatter": "verbose",\n },\n}\nThe unnamed logging configuration '' captures logs from any Python\napplication. A named logging configuration will capture logs only from loggers\nwith matching names.
The namespace of a logger instance is defined using\ngetLogger(). For example in views.py of my_app:
logger = logging.getLogger(__name__)\nwill create a logger in the my_app.views namespace. __name__ allows you\nto organize log messages according to their provenance within your project’s\napplications automatically. It also ensures that you will not experience name\ncollisions.
A logger mapping named my_app.views will capture records from this logger:
LOGGING = {\n # ...\n "loggers": {\n "my_app.views": {...},\n },\n}\nA logger mapping named my_app will be more permissive, capturing records\nfrom loggers anywhere within the my_app namespace (including\nmy_app.views, my_app.utils, and so on):
LOGGING = {\n # ...\n "loggers": {\n "my_app": {...},\n },\n}\nYou can also define logger namespacing explicitly:
\nlogger = logging.getLogger("project.payment")\nand set up logger mappings accordingly.
\nLogger naming is hierarchical. my_app is the parent of my_app.views,\nwhich is the parent of my_app.views.private. Unless specified otherwise,\nlogger mappings will propagate the records they process to their parents - a\nrecord from a logger in the my_app.views.private namespace will be handled\nby a mapping for both my_app and my_app.views.
To manage this behavior, set the propagation key on the mappings you define:
\nLOGGING = {\n # ...\n "loggers": {\n "my_app": {\n # ...\n },\n "my_app.views": {\n # ...\n },\n "my_app.views.private": {\n # ...\n "propagate": False,\n },\n },\n}\npropagate defaults to True. In this example, the logs from\nmy_app.views.private will not be handled by the parent, but logs from\nmy_app.views will.
Logging is most useful when it contains as much information as possible, but\nnot information that you don’t need - and how much you need depends upon what\nyou’re doing. When you’re debugging, you need a level of information that would\nbe excessive and unhelpful if you had to deal with it in production.
\nYou can configure logging to provide you with the level of detail you need,\nwhen you need it. Rather than manually change configuration to achieve this, a\nbetter way is to apply configuration automatically according to the\nenvironment.
\nFor example, you could set an environment variable DJANGO_LOG_LEVEL\nappropriately in your development and staging environments, and make use of it\nin a logger mapping thus:
"level": os.getenv("DJANGO_LOG_LEVEL", "WARNING")\n- so that unless the environment specifies a lower log level, this\nconfiguration will only forward records of severity WARNING and above to\nits handler.
Other options in the configuration (such as the level or formatter\noption of handlers) can be similarly managed.