Configuration élégante de la journalisation Python dans Django

Je n'ai pas encore trouvé un moyen de configurer la journalisation Python avec Django qui me satisfait. Mes exigences sont assez simples:

• Différents gestionnaires de journaux pour différents événements - c'est-à-dire que je veux pouvoir me connecter à différents fichiers
• Accès facile aux enregistreurs dans mes modules. Le module devrait pouvoir trouver son enregistreur avec peu d'effort.
• Devrait être facilement applicable aux modules de ligne de commande. Certaines parties du système sont des processus de ligne de commande ou de démon autonomes. La journalisation doit être facilement utilisable avec ces modules.

Ma configuration actuelle consiste à utiliser un logging.conffichier et une journalisation de configuration dans chaque module à partir duquel je me connecte. Ça ne va pas.

Avez-vous une configuration de journalisation que vous aimez? Veuillez le détailler: comment configurez-vous la configuration (utilisez-vous logging.confou configurez-la dans le code), où / quand lancez-vous les enregistreurs, et comment y avez-vous accès dans vos modules, etc.

Le meilleur moyen que j'ai trouvé jusqu'à présent est d'initialiser la configuration de la journalisation dans settings.py - nulle part ailleurs. Vous pouvez utiliser un fichier de configuration ou le faire par programmation étape par étape - cela dépend uniquement de vos besoins. L'essentiel est que j'ajoute généralement les gestionnaires que je veux à l'enregistreur racine, en utilisant des niveaux et parfois en journalisant.Filtres pour obtenir les événements que je veux dans les fichiers appropriés, la console, les syslogs, etc. aussi, mais ce n'est généralement pas nécessaire dans mon expérience.

Dans chaque module, je définis un enregistreur en utilisant

logger = logging.getLogger(__name__)

et utilisez-le pour enregistrer les événements dans le module (et, si je veux différencier davantage), utilisez un enregistreur qui est un enfant de l'enregistreur créé ci-dessus.

Si mon application va être potentiellement utilisée dans un site qui ne configure pas la journalisation dans settings.py, je définis un NullHandler quelque part comme suit:

#someutils.py

class NullHandler(logging.Handler):
    def emit(self, record):
        pass

null_handler = NullHandler()

et assurez-vous qu'une instance de celui-ci est ajoutée à tous les enregistreurs créés dans les modules de mes applications qui utilisent la journalisation. (Remarque: NullHandler est déjà dans le package de journalisation pour Python 3.1, et sera dans Python 2.7.) Donc:

logger = logging.getLogger(__name__)
logger.addHandler(someutils.null_handler)

Ceci est fait pour garantir que vos modules jouent bien dans un site qui ne configure pas la journalisation dans settings.py, et que vous n'obtenez aucun message ennuyeux "Aucun gestionnaire n'a pu être trouvé pour le logger XYZ" (qui sont des avertissements sur des journalisation mal configurée).

Cela répond à vos exigences déclarées:

• Vous pouvez configurer différents gestionnaires de journaux pour différents événements, comme vous le faites actuellement.
• Accès facile aux enregistreurs dans vos modules - utilisation getLogger(__name__).
• Facilement applicable aux modules de ligne de commande - ils importent également settings.py.

Mise à jour: Notez qu'à partir de la version 1.3, Django intègre désormais la prise en charge de la journalisation .

Je sais que c'est déjà une réponse résolue, mais selon django> = 1.3, il y a un nouveau paramètre de journalisation.

Passer de l'ancien au nouveau n'est pas automatique, alors j'ai pensé l'écrire ici.

Et bien sûr, consultez la documentation django pour en savoir plus.

Ceci est la configuration de base, créée par défaut avec django-admin createproject v1.3 - le kilométrage peut changer avec les dernières versions de django:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'class': 'django.utils.log.AdminEmailHandler',
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        }
    }
}

Cette structure est basée sur la journalisation Python standard dictConfig , qui dicte les blocs suivants:

• formatters - la valeur correspondante sera un dict dans lequel chaque clé est un identifiant de formateur et chaque valeur est un dict décrivant comment configurer l'instance de formateur correspondante.
• filters - la valeur correspondante sera un dict dans lequel chaque clé est un identifiant de filtre et chaque valeur est un dict décrivant comment configurer l'instance de filtre correspondante.

• handlers- la valeur correspondante sera un dict dans lequel chaque clé est un identifiant de gestionnaire et chaque valeur est un dict décrivant comment configurer l'instance de gestionnaire correspondante. Chaque gestionnaire possède les clés suivantes:

  • class(obligatoire). Il s'agit du nom qualifié complet de la classe de gestionnaire.
  • level(optionnel). Le niveau du gestionnaire.
  • formatter(optionnel). L'identifiant du formateur pour ce gestionnaire.
  • filters(optionnel). Une liste des identifiants des filtres pour ce gestionnaire.

Je fais généralement au moins ceci:

• ajouter un fichier .log
• configurer mes applications pour écrire dans ce journal

Ce qui se traduit par:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
        },
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
    },
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'handlers': {
        'null': {
            'level':'DEBUG',
            'class':'django.utils.log.NullHandler',
        },
        'console':{
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'simple'
        },
        # I always add this handler to facilitate separating loggings
        'log_file':{
            'level': 'DEBUG',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': os.path.join(VAR_ROOT, 'logs/django.log'),
            'maxBytes': '16777216', # 16megabytes
            'formatter': 'verbose'
        },
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler',
            'include_html': True,
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        'apps': { # I keep all my of apps under 'apps' folder, but you can also add them one by one, and this depends on how your virtualenv/paths are set
            'handlers': ['log_file'],
            'level': 'INFO',
            'propagate': True,
        },
    },
    # you can also shortcut 'loggers' and just configure logging for EVERYTHING at once
    'root': {
        'handlers': ['console', 'mail_admins'],
        'level': 'INFO'
    },
}

Éditer

Les exceptions de demande sont désormais toujours enregistrées et le ticket n ° 16288 :

J'ai mis à jour l'exemple de configuration ci-dessus pour inclure explicitement le filtre correct pour mail_admins afin que, par défaut, les e-mails ne soient pas envoyés lorsque le débogage a la valeur True.

Vous devez ajouter un filtre:

'filters': {
    'require_debug_false': {
        '()': 'django.utils.log.RequireDebugFalse'
    }
},

et appliquez-le au gestionnaire mail_admins:

    'mail_admins': {
        'level': 'ERROR',
        'filters': ['require_debug_false'],
        'class': 'django.utils.log.AdminEmailHandler',
        'include_html': True,
    }

Sinon, django.core.handers.base.handle_uncaught_exceptionne transmet pas les erreurs à l'enregistreur 'django.request' si settings.DEBUG est True.

Si vous ne le faites pas dans Django 1.5, vous obtiendrez un

DeprecationAvertissement: Vous n'avez pas de filtre défini sur le gestionnaire de journalisation 'mail_admins': ajout d'un filtre implicite debug-false-only

mais les choses fonctionneront toujours correctement LES DEUX dans django 1.4 et django 1.5.

** fin de modification **

Cette conf est fortement inspirée de l'exemple de conf dans la doc django, mais en ajoutant la partie du fichier journal.

Je fais souvent aussi ce qui suit:

LOG_LEVEL = 'DEBUG' if DEBUG else 'INFO'

...
    'level': LOG_LEVEL
...

Ensuite, dans mon code python, j'ajoute toujours un NullHandler au cas où aucune configuration de journalisation n'est définie. Cela évite les avertissements pour aucun gestionnaire spécifié. Particulièrement utile pour les bibliothèques qui ne sont pas nécessairement appelées uniquement dans Django ( ref )

import logging
# Get an instance of a logger
logger = logging.getLogger(__name__)
class NullHandler(logging.Handler): #exists in python 3.1
    def emit(self, record):
        pass
nullhandler = logger.addHandler(NullHandler())

# here you can also add some local logger should you want: to stdout with streamhandler, or to a local file...

[...]

logger.warning('etc.etc.')

J'espère que cela t'aides!

Nous initialisons la journalisation au niveau supérieur urls.pyà l'aide d'un logging.inifichier.

L'emplacement du logging.iniest fourni dans settings.py, mais c'est tout.

Chaque module fait alors

logger = logging.getLogger(__name__)

Pour distinguer les instances de test, de développement et de production, nous avons différents fichiers logging.ini. Pour la plupart, nous avons un "journal de console" qui va à stderr avec des erreurs uniquement. Nous avons un "journal d'application" qui utilise un fichier journal de roulement régulier qui va dans un répertoire de journaux.

J'utilise actuellement un système de journalisation, que j'ai créé moi-même. Il utilise le format CSV pour la journalisation.

django-csvlog

Ce projet n'a toujours pas de documentation complète, mais je travaille dessus.