Enregistrer toutes les demandes de fichiers Django

Lorsque je lance le serveur de développement django ( ./manage.py runserver ), toutes les URL demandées sont facilement connectées au processus stdout, avec l’heure précise et le code de réponse:

 [09/Jun/2016 23:35:53] "GET /api/game/ HTTP/1.1" 404 3185 [09/Jun/2016 23:36:01] "GET /api/game/123/ HTTP/1.1" 404 1735

C’est très pratique car lors de l’parsing de la sortie, vous voyez immédiatement la demande correspondant à vos messages de journalisation, par exemple:

 WARNING:2016-06-09 23:41:27,806:views:7449:140139847718656: No such object in the database: u'123' [09/Jun/2016 23:41:27] "GET /api/game/123/ HTTP/1.1" 404 1735

J’avais l’habitude de travailler avec uwsgi + nginx, alors j’ai utilisé le gestionnaire de consignation ‘console’ pour tout, puis j’ai lancé uwsgi comme ceci:

 exec uwsgi --master --die-on-term --logto /var/log/uwsgi.log

En conséquence, j’ai obtenu toutes les informations nécessaires dans /var/log/uwsgi.log , les enregistrements de demande d’uwsgi et mes propres messages de journalisation.

Maintenant, je veux obtenir le même résultat avec Apache + mod WSGI + django. Je veux que le seul fichier contienne toutes les requêtes et tous les journaux de mon application Django en un seul endroit.

J’ai essayé de réaliser cela avec la configuration de la journalisation de Django, mais même lorsque je redirige les requêtes django.requests vers le même fichier, je ne reçois que mes propres messages dans les journaux, sans aucune demande. Voici la partie de la configuration:

 'handlers': { 'file_handler': { 'level': DEBUG and 'DEBUG' or 'INFO', 'class': 'logging.handlers.RotatingFileHandler', 'filename': join(LOG_DIRECTORY, 'api_log.log'), 'maxBytes': 1024 * 1024 * 5, # 5 MB 'backupCount': 15, 'formatter': 'verbose', }, }, 'loggers': { 'api': { 'handlers': ['file_handler'], 'level': DEBUG and 'DEBUG' or 'INFO', }, 'django': { 'handlers': ['file_handler'], 'level': DEBUG and 'DEBUG' or 'INFO', }, 'django.request': { 'handlers': ['file_handler'], 'level': DEBUG and 'DEBUG' or 'INFO', }, 'django.db.backends': { 'handlers': ['file_handler'], 'level': DEBUG and 'INFO' or 'WARNING', 'propagate': False, }, }

Existe-t-il un moyen d’atteindre le comportement de journalisation de nginx + uwsgi + django avec apache + WSGI + django? Ou le seul moyen est de garder apache access.log et mes journaux dans des fichiers séparés?

Je suppose que dans le premier cas, c’est le serveur de développement qui a consigné les requêtes et dans le second cas, c’était le processus uwsgi. Peut-être y a-t-il un moyen de dire à WSGIDaemonProcess de faire la même chose?

Pour une installation Apache standard, vous allez à l’encontre de ce qui est considéré comme la meilleure pratique en essayant de mélanger les journaux d’access et les journaux d’erreurs. Traditionnellement, ils ont été laissés séparés afin que l’parsing puisse être effectuée sur les journaux d’access sur le trafic du serveur.

Cela dit, avez-vous essayé de modifier les directives ErrorLog et CustomLog dans Apache pour utiliser le même fichier?

Lorsque j’ai utilisé mod_wsgi-express avec la commande:

 mod_wsgi-express start-server --access-log --access-log-name application.log --error-log-name application.log

il génère:

  ErrorLog "|/usr/sbin/rotatelogs \ /tmp/mod_wsgi-localhost:8000:502/application.log.%Y-%m-%d-%H_%M_%S 5M"   ErrorLog "/tmp/mod_wsgi-localhost:8000:502/application.log"  LogLevel warn   LoadModule log_config_module ${MOD_WSGI_MODULES_DIRECTORY}/mod_log_config.so  LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined LogFormat "undefined" custom  CustomLog "|/usr/sbin/rotatelogs \ /tmp/mod_wsgi-localhost:8000:502/application.log.%Y-%m-%d-%H_%M_%S 5M" common   CustomLog "/tmp/mod_wsgi-localhost:8000:502/application.log" common

avec le application.log résultant étant:

 [Fri Jun 10 07:17:30.845264 2016] [mpm_prefork:notice] [pid 84334] AH00163: Apache/2.4.18 (Unix) mod_wsgi/4.5.2 Python/2.7.10 configured -- resuming normal operations [Fri Jun 10 07:17:30.845518 2016] [core:notice] [pid 84334] AH00094: Command line: 'httpd (mod_wsgi-express) -f /tmp/mod_wsgi-localhost:8000:502/httpd.conf -D MOD_WSGI_ACCESS_LOG -D FOREGROUND' ::1 - - [10/Jun/2016:07:17:36 +1000] "GET / HTTP/1.1" 200 709 ::1 - - [10/Jun/2016:07:17:37 +1000] "GET / HTTP/1.1" 200 709 ::1 - - [10/Jun/2016:07:17:37 +1000] "GET / HTTP/1.1" 200 709 ::1 - - [10/Jun/2016:07:17:38 +1000] "GET / HTTP/1.1" 200 709 ::1 - - [10/Jun/2016:07:17:38 +1000] "GET / HTTP/1.1" 200 709 [Fri Jun 10 07:17:39.784486 2016] [mpm_prefork:notice] [pid 84334] AH00169: caught SIGTERM, shutting down

Donc, techniquement, cela devrait fonctionner pour une installation Apache autonome avec à la fois le journal des erreurs et des access et le même fichier en définissant ErrorLog et CustomLog sur le même fichier.

En ce qui concerne la journalisation Django supplémentaire qu’elle pourrait générer en interne à cause d’exceptions, vous auriez toujours besoin de:

 LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'class': 'logging.StreamHandler', }, }, 'loggers': { 'django': { 'handlers': ['console'], 'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'), }, }, }

Ceci indique à Django de se connecter théoriquement au terminal, que mod_wsgi va intercepter et envoyer au journal des erreurs Apache, ce qui, avec ce qui précède, constituera le journal d’application combiné.

BTW, si vous voulez exécuter Apache / mod_wsgi dans un conteneur où la journalisation doit aller à la sortie standard, ne le faites pas vous-même. Utilisez mod_wsgi-express car il est spécialement conçu pour être utilisé dans des conteneurs. Dans ce cas, vous utiliseriez simplement:

 mod_wsgi-express start-server --access-log --log-to-terminal

Si vous souhaitez activer la journalisation des access (désactivée par défaut uniquement en termes de bruit pour les déploiements de conteneurs) et si vous souhaitez envoyer les journaux d’access et d’erreur au terminal, Docker peut les capturer.

Si vous avez besoin de plus d’informations ou d’assistance, utilisez la liste de diffusion mod_wsgi.