Question
How can I configure Django logging to capture deployment errors when using Azure App Service deployment logs?
Rey Cedar
0 reputation · 11 Apr 2024, 08:42 UTC
134.2K views1
Loading…
0 reputation · 11 Apr 2024, 08:42 UTC
When a Django application fails to start during deployment to Azure App Service, the deployment log indicates a generic failure but does not show the Python traceback. To diagnose the issue, Django’s logging must be configured so that uncaught exceptions during startup are written to the same log store that App Service reads for deployment logs. The standard logging module uses hierarchical loggers and propagates messages to parent handlers unless propagate is disabled. However, it is unclear whether the default root logger configuration in a Django project will capture startup errors and forward them to a file handler pointing at /home/LogFiles/Application/. Additionally, the deployment log files are stored under /LogFiles/Git/ and /deployments/, and it is uncertain whether adding a FileHandler to that path will make the logs visible alongside the deployment entries.
What logging configuration ensures that exceptions raised during Django’s WSGI application load are recorded in the App Service file system? Should the root logger’s level be set to DEBUG and propagate left enabled, or is a dedicated handler required? Is it necessary to point a FileHandler at /home/LogFiles/Application/ to capture Django logs together with the deployment logs?
26525 reputation · 11 Apr 2024, 09:12 UTC
To see Django startup exceptions in Azure App Service deployment logs, Django’s logging must write to the same log store that App Service reads when it surfaces deployment output. If App Service captures logs from the process’ stdout/stderr, configuring Django to use a StreamHandler pointing at those streams will make tracebacks appear. If instead App Service reads from a specific file path (for example, a file under /home/LogFiles/Application/), a FileHandler targeting that path is required.
No verifiable details about Azure App Service log ingestion for Django were found in the supplied sources.
Once the log destination is known, apply one of the following configurations in your Django settings.py:
djangoLOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'stream': sys.stdout,
},
},
'root': {
'handlers': ['console'],
'level': 'ERROR',
},
}/home/LogFiles/Application/django.log):LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'file': {
'class': 'logging.FileHandler',
'filename': '/home/LogFiles/Application/django.log',
},
},
'root': {
'handlers': ['file'],
'level': 'ERROR',
},
}After saving the setting, redeploy the app and check the deployment logs for the traceback.
Missing diagnostic detail: Does Azure App Service capture deployment logs from the application’s stdout/stderr, or does it read from a specific file path under /home/LogFiles? Knowing this determines whether to use a StreamHandler or a FileHandler.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 11 Apr 2024, 10:06 UTC
By default Django sets the root logger to DEBUG. If you leave it that way, an exception raised while the WSGI app is loading will be logged at ERROR, but the root logger’s level will filter it out. Set the root level to ERROR (or CRITICAL) so that all startup errors bubble up.
When an exception is raised, Django’s internal loggers (e.g., django.core.wsgi) propagate the message to the root logger unless propagate=False is set. In most projects this is already true, so once the root level is ERROR you’ll see the traceback.
Azure App Service automatically ingests anything written to stdout or stderr. Adding a StreamHandler that points to sys.stderr guarantees the traceback appears in the portal’s Log Stream without any extra Azure configuration.
import sys
LOGGING = {
"version": 1,
"disable_existing_loggers": False,
"handlers": {
"console": {
"class": "logging.StreamHandler",
"stream": sys.stderr,
},
},
"root": {
"handlers": ["console"],
"level": "ERROR",
},
}
If you prefer a file, use logging.handlers.RotatingFileHandler under D:\\home\\logfiles\\django_deploy.log and enable File System Logging in the portal. Remember that the file is wiped on redeploy, so rotate or ship it elsewhere for persistence.