À l'aide de Python journalisation dans plusieurs modules

J'ai un petit projet de python qui a la structure suivante - 

Project 
 -- pkg01
   -- test01.py
 -- pkg02
   -- test02.py
 -- logging.conf

J'ai l'intention d'utiliser la journalisation par défaut un module pour imprimer les messages sur la sortie standard, et un fichier journal.
Pour utiliser le module de journalisation, certains d'initialisation est nécessaire - 

import logging.config

logging.config.fileConfig('logging.conf')
logger = logging.getLogger('pyApp')

logger.info('testing')

À l'heure actuelle, j'ai effectuer cette initialisation dans chaque module avant de commencer la journalisation des messages. Est-il possible d'effectuer cette initialisation qu'une seule fois à un endroit, que les mêmes paramètres sont réutilisés par l'exploitation forestière à travers tout le projet?

  • En réponse à votre commentaire sur ma réponse: vous n'avez pas à appeler fileConfig dans chaque module de journalisation, sauf si vous avez if __name__ == '__main__' logique dans chacun d'eux. prost réponse n'est pas une bonne pratique si le package est une bibliothèque, mais il pourrait travailler pour vous - il ne faut pas configurer la journalisation dans les paquets de bibliothèque, autres que pour ajouter un NullHandler.
  • prost implicite que nous devons appeler l'importation et l'enregistreur de stmts dans chaque module, et appeler l'fileconfig stmt dans le module principal. nest pas similaire à ce que vous dites?
  • prost est en train de dire que vous devriez mettre la journalisation config code dans package/__init__.py. Ce n'est pas normalement l'endroit où vous mettre if __name__ == '__main__' code. Aussi, prost exemple dirait qu'il va appeler la config code sans condition à l'importation, ce qui n'est pas bon pour moi. Généralement, l'exploitation forestière config code doit être fait en un seul endroit et ne devrait pas se produire comme effet secondaire de l'importation, sauf lorsque vous importez __principaux__.
  • vous avez raison, j'ai totalement raté la ligne "# package/__init__.py " dans son code de l'échantillon. merci pour le signaler et votre patience.
  • Donc ce qui arrive si vous avez plusieurs if __name__ == '__main__'? (il n'est pas mentionné explicitement dans la question si c'est le cas)
InformationsquelleAutor Quest Monger | 2013-03-31
  1. 236

    La meilleure pratique est, dans chaque module, d'avoir un enregistreur définie comme ceci:

    import logging
logger = logging.getLogger(__name__)

    près de la partie supérieure du module, puis dans un autre code dans le module n'par exemple

    logger.debug('My message with %s', 'variable data')

    Si vous avez besoin de subdiviser les activités d'exploitation forestière à l'intérieur d'un module, utiliser, par exemple,

    loggerA = logging.getLogger(__name__ + '.A')
loggerB = logging.getLogger(__name__ + '.B')

    et journal de loggerA et loggerB appropriées.

    Dans votre programme principal ou de programmes, de faire par exemple:

    def main():
    "your program code"

if __name__ == '__main__':
    import logging.config
    logging.config.fileConfig('/path/to/logging.conf')
    main()

    ou 

    def main():
    import logging.config
    logging.config.fileConfig('/path/to/logging.conf')
    # your program code

if __name__ == '__main__':
    main()

    Voir ici pour l'enregistrement de plusieurs modules, et ici pour la configuration de la journalisation pour le code qui sera utilisé comme un module de la bibliothèque par un autre code.

    Mise à jour: Lors de l'appel de fileConfig(), vous pouvez spécifier disable_existing_loggers=False si vous êtes à l'aide de Python 2.6 ou version ultérieure (voir les docs pour plus d'informations). La valeur par défaut est True pour des raisons de compatibilité ascendante, ce qui provoque tous les enregistreurs être désactivée par fileConfig() à moins qu'ils ou leur ancêtre sont explicitement nommées dans la configuration. Avec la valeur de la valeur False, existant bûcherons sont laissés seuls. Si à l'aide de Python 2.7 et Python 3.2 ou version ultérieure, vous pouvez envisager de la dictConfig() API qui est mieux que fileConfig() car il donne plus de contrôle sur la configuration.

    • si vous regardez mon exemple, je fais déjà ce que vous suggérez ci-dessus. ma question est comment faire pour centraliser cette journalisation initialisation telle que je n'ai pas à répéter ces 3 états. aussi, dans votre exemple, vous avez manqué la " journalisation.config.fileConfig('journalisation.conf')' stmt. cette stmt est en fait la cause de mon souci. vous voyez, si j'ai lancer l'enregistreur de données dans chaque module, je voudrais taper cette stmt dans chaque module. que signifierait suivi le chemin d'accès du fichier conf de chaque module, ce qui ne ressemble pas à une meilleure pratique pour moi (imaginez les ravages lors du changement de module/paquet emplacements).
    • Si vous appelez fileConfig après la création de l'enregistreur de données, que ce soit dans le même ou dans un autre module (par exemple, lorsque vous créez l'enregistreur à la tête de fichier) ne fonctionne pas. La configuration de la journalisation s'applique uniquement aux enregistreurs créé après. Donc, cette approche ne fonctionne pas ou n'est pas une option viable pour plusieurs modules. @Quête Monger: Vous pouvez toujours créer un autre fichier qui contient l'emplacement du fichier de config..;)
    • Pas nécessairement à voir le disable_existing_loggers drapeau qui est True par défaut mais peut être False.
    • Sajip, merci! Enfin je peux le faire fonctionner dans mon principal..:) je ne suis pas entièrement sûr de comprendre pourquoi cela fonctionne bien, le soin de m'éclairer? Et peut-être l'ajouter à votre message..;)
    • réponse de mise à jour.
    • Sajip, je vous remercie. Avez-vous des recommandations pour les bûcherons qui travaillent dans les modules, mais à l'extérieur des classes ainsi? Étant donné que les importations sont réalisées avant la principale fonction est appelée, ces journaux ont déjà été enregistrés. Je suppose que la configuration de votre enregistreur avant de toutes les importations dans le module principal est le seul moyen? Cet enregistreur peut alors être remplacé en main, si vous le souhaitez.
    • non, vous pouvez créer des enregistreurs de n'importe où, que ce soit à l'intérieur ou à l'extérieur des classes. Poser une autre question si vous avez besoin d' - les commentaires ne sont pas l'endroit approprié pour poser de nouvelles questions.
    • Notez que l'officiel 2.6 docs sont trompeurs et ne mentionnent pas disable_existing_loggers. Vous pouvez vérifier la pydoc ou de la source pour se rassurer qu'il n'a, en fait, existent dans cette version.
    • Salut Vinay, de la bonne réponse. Je veux juste savoir ce que tu veux dire par With the value set to False, existing loggers are left alone. Est-ce à dire défini précédemment enregistreur peut également charger les paramètres d' dictConfig() qui sont invoquées plus tard?
    • Si je veux avoir tous mes module spécifique bûcherons ont un niveau d'enregistrement différent de la valeur par défaut d'AVERTISSEMENT, aurai-je à faire de ce paramètre sur chaque module? Dire, je veux avoir tous mes modules journal INFO.
    • cela ne semble pas fonctionner pour moi (à l'aide de ballon avec python 3.6). la seule façon de journaux, c'est quand j'utilise codé en dur la chaîne "flacon.app" comme l'enregistreur de son nom. par exemple: logger = logging.getLogger('flask.app') est-il un moyen de le faire fonctionner avec __name__ ? mon flacon application est également configuré avec __name__: app = Flask(__name__)
    • quel est le nom du module de la Fiole d'application, c'est à dire la valeur de __name__ pour l'enregistreur? Si c'est par exemple foo.bar, vous devez veiller à ce que les gestionnaires sont configurés pour enregistreurs de foo.bar, foo ou de la racine de l'enregistreur.
    • ouais merci. j'ai effectivement ajouté ma propre réponse ainsi que le décrit la façon dont j'ai géré avec celui-ci

    InformationsquelleAutor Vinay Sajip
  2. 94

    En fait, tous les logger est un enfant de la mère du package enregistreur (c'est à dire package.subpackage.module hérite de package.subpackage), de sorte que tous vous avez besoin à faire est de configurer la racine de l'enregistreur. Ceci peut être réalisé par journalisation.config.fileConfig (votre propre config pour les bûcherons) ou journalisation.basicConfig (définit la racine de l'enregistreur). Journalisation de l'installation de votre module d'entrée (__main__.py ou ce que vous souhaitez exécuter, par exemple main_script.py. __init__.py fonctionne aussi bien)

    à l'aide de basicConfig:

    # package/__main__.py
import logging
import sys

logging.basicConfig(stream=sys.stdout, level=logging.INFO)

    à l'aide de fileConfig:

    # package/__main__.py
import logging
import logging.config

logging.config.fileConfig('logging.conf')

    et puis créer chaque enregistreur à l'aide de:

    # package/submodule.py
# or
# package/subpackage/submodule.py
import logging
log = logging.getLogger(__name__)

log.info("Hello logging!")

    Pour plus d'informations, voir Enregistrement Avancé Tutoriel.

    • c'est, de loin, la solution la plus simple au problème, pour ne pas mentionner il expose & exploite la relation parent-enfant entre les modules, quelque chose que j'ai comme un noob était pas au courant de. merci.
    • vous êtes de droite. et comme vinay a souligné dans son poste, votre solution est bonne tant qu'elle n'est pas dans le init.py module. votre solution ne fonctionne quand je l'ai appliquée au module principal (point d'entrée).
    • en réalité, beaucoup plus de réponse pertinente depuis la la question avec des modules séparés.
    • Question stupide peut-être: si il n'y a pas de logger dans __main__.py (par exemple, Si je veux utiliser le module dans un script qui n'a pas d'enregistreur) sera logging.getLogger(__name__) encore faire une sorte de journalisation dans le module ou il va lever une exception?
    • Je ne suis pas sûr si je comprends votre question. Voulez-vous dire que vous avez pas de connexion.basicConfig ou à l'exploitation forestière.config.fileConfig? Vous pouvez certainement utiliser la journalisation.getLogger et de faire de l'abattage, il ne serait pas juste d'imprimer n'importe quoi n'importe où. De nombreuses bibliothèques de journalisation, mais ils sortent de la journalisation de la configuration (comme l'endroit où les messages de journalisation aller) à leurs utilisateurs.
    • Merci @StanProkop. Oui je pense que c'est mon problème avec cela. J'aime l'idée de le module "hériter" le bûcheron et la journalisation de config dans le script principal, mais si c'est un objectif général du module, je risque de ne pas toujours disposer de journalisation dans mon script principal. (Dans mon cas, je suis utilisateur et 'développeur'). Que faire si je suis d'importer le module à partir de l'interprète, par exemple?
    • Est-il un moyen de faire quelque chose comme if logging.getLogger(__name__): ... else: logging.basicConfig(... )?
    • quand je joue avec mon propre ou d'un tiers des bibliothèques de l'utilisation de la journalisation j'utilise ipython avec autoreload (donc toutes les modifications enregistrées dans mes bibliothèques sont auto reloaded) et j'ai configurer la journalisation juste une fois au début à l'aide de basicConfig. Dans les tests que j'ai utiliser pytest, elle capte la journalisation et l'imprime sur des échecs. Parfois j'ai même l'échec des tests intentionnellement juste pour voir l'enregistrement.
    • De toute façon, pour vérifier si la connexion a été établie, vous pouvez essayer de voir si la journalisation.de la racine.les gestionnaires sont vides. Mais je ne le recommande pas, il y a peut être quelques mises en garde.

    InformationsquelleAutor Stan Prokop
  3. 21

    Je fais toujours comme ci-dessous.

    Utiliser un seul fichier python pour config mon journal comme le pattern singleton qui l'a nommé 'log_conf.py'

    #-*-coding:utf-8-*-

import logging.config

def singleton(cls):
    instances = {}
    def get_instance():
        if cls not in instances:
            instances[cls] = cls()
        return instances[cls]
    return get_instance()

@singleton
class Logger():
    def __init__(self):
        logging.config.fileConfig('logging.conf')
        self.logr = logging.getLogger('root')

    Dans un autre module, il suffit d'importer le fichier config.

    from log_conf import Logger

Logger.logr.info("Hello World")

    C'est un singleton pour vous connecter, simplement et efficacement.

    • merci pour détailler le pattern singleton. j'ai été la planification sur la mise en œuvre, mais alors le @prost solution est beaucoup plus simple et convient parfaitement mes besoins. j'ai cependant voyez-vous votre solution utile est de grands projets, qui ont de multiples points d'entrée (autres que les principaux). merci.
    • Ceci est inutile. La racine de l'enregistreur est déjà un singleton. Utilisez simplement logging.info au lieu de Logger.logr.info.
    InformationsquelleAutor Yarkee
  4. 8

    Plusieurs de ces réponses suggèrent que dans le haut d'un module que vous vous n'avez 

    import logging
logger = logging.getLogger(__name__)

    C'est ma compréhension que cela est considéré comme très mauvaise pratique. La raison en est que le fichier de config va désactiver tous les enregistreurs par défaut. E. g.

    #my_module
import logging

logger = logging.getLogger(__name__)

def foo():
    logger.info('Hi, foo')

class Bar(object):
    def bar(self):
        logger.info('Hi, bar')

    Et dans votre module principal :

    #main
import logging

# load my module - this now configures the logger
import my_module

# This will now disable the logger in my module by default, [see the docs][1] 
logging.config.fileConfig('logging.ini')

my_module.foo()
bar = my_module.Bar()
bar.bar()

    Maintenant le journal spécifié lors de l'enregistrement.ini est vide, l'enregistreur a été désactivé par fileconfig appel.

    Tout est est certainement possible de contourner ce problème (disable_existing_Loggers=False), de façon réaliste, de nombreux clients de votre bibliothèque ne sais pas à propos de ce comportement, et de ne pas recevoir vos journaux. Le rendre facile pour vos clients toujours à l'appel de l'enregistrement.getLogger localement. Chapeau Astuce : j'ai appris à propos de ce comportement de Victor Lin de Site web.

    Les bonnes pratiques est au lieu de toujours faire appel à la journalisation.getLogger localement. E. g.

    #my_module
import logging

logger = logging.getLogger(__name__)

def foo():
    logging.getLogger(__name__).info('Hi, foo')

class Bar(object):
    def bar(self):
        logging.getLogger(__name__).info('Hi, bar')

    Aussi, si vous utilisez fileconfig dans votre main, jeu de disable_existing_loggers=False, juste au cas où votre bibliothèque, les concepteurs utilisent le niveau de module enregistreur de cas.

    • Pouvez-vous l'exécutez pas logging.config.fileConfig('logging.ini') avant import my_module? Comme l'a suggéré dans cette réponse.
    • Pas sûr - mais il serait certainement aussi être considéré comme une mauvaise pratique de mélanger les importations et le code exécutable de cette façon. Vous aussi vous ne voulez pas que vos clients pour vérifier si ils ont besoin pour configurer la journalisation avant qu'ils importent, surtout quand il ya une simple alternative! Imaginez si largement utilisée de la bibliothèque, comme les demandes avait fait cela....!
    • "Pas sûr - mais il serait certainement aussi être considéré comme une mauvaise pratique de mélanger les importations et le code exécutable de cette façon." - pourquoi?
    • Je ne suis pas trop clair sur les raisons de ce qui est mauvais. Et je ne comprends pas tout à ton exemple. Vous pouvez poster votre config pour cet exemple et de montrer certains de l'utilisation?
    • pouvez-vous poster un lien vers quelques officiel de python de la documentation indiquant c'est une mauvaise pratique?
    • Pep 8 indique que les importations doivent venir avant les variables de niveau module: voir par exemple stackoverflow.com/questions/1188640/... et c'est en gros la même idée dans les principlal - réglage du niveau du module de l'état, avant de terminer l'importation.
    • Il est entièrement travaillé exemple sur le lien dans la réponse originale à cette question.
    • Je serais certainement vous appeler les bonnes pratiques une mauvaise pratique. Vous essayez de prendre le contrôle de l'utilisateur, mais en Python, nous nous attendons à l'utilisateur d'être une personne raisonnable. Si j'ai une configuration et l'utilisation disable_existing_loggers=True je serai très surpris de découvrir que vous ignorer et encore journal de.

    InformationsquelleAutor phil_20686
  5. 6

    Lancer dans une autre solution.

    Dans mon module de init.py j'ai quelque chose comme:

    # mymodule/__init__.py
import logging

def get_module_logger(mod_name):
  logger = logging.getLogger(mod_name)
  handler = logging.StreamHandler()
  formatter = logging.Formatter(
        '%(asctime)s %(name)-12s %(levelname)-8s %(message)s')
  handler.setFormatter(formatter)
  logger.addHandler(handler)
  logger.setLevel(logging.DEBUG)
  return logger

    Puis dans chaque module, j'ai besoin d'un enregistreur, je n':

    # mymodule/foo.py
from [modname] import get_module_logger
logger = get_module_logger(__name__)

    Lorsque les journaux sont manqués, vous pouvez différencier leur source par le module de provenance.

    • Que signifie "mon principal du module init" signifie? Et "Puis dans chaque classe, j'ai besoin d'un enregistreur, je fais:"? Pouvez-vous fournir un échantillon called_module.py et un exemple de son utilisation comme une importation du module caller_module.py ? Voir cette réponse pour une inspiration de le format que je veux parler. Ne pas essayer d'être condescendante. J'essaie de comprendre votre réponse et je sais que je le ferais si vous avez écrit de cette façon.
    • J'ai précisé.
    InformationsquelleAutor Tommy
  6. 5

    @Yarkee la solution semblait aller mieux. Je voudrais ajouter somemore à elle -

    class Singleton(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances.keys():
            cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
        return cls._instances[cls]


class LoggerManager(object):
    __metaclass__ = Singleton

    _loggers = {}

    def __init__(self, *args, **kwargs):
        pass

    @staticmethod
    def getLogger(name=None):
        if not name:
            logging.basicConfig()
            return logging.getLogger()
        elif name not in LoggerManager._loggers.keys():
            logging.basicConfig()
            LoggerManager._loggers[name] = logging.getLogger(str(name))
        return LoggerManager._loggers[name]    


log=LoggerManager().getLogger("Hello")
log.setLevel(level=logging.DEBUG)

    Donc LoggerManager peut être un enfichables pour l'ensemble de l'application.
    Espérons que cela a du sens et de la valeur.

    • Le module de journalisation traite déjà avec des singletons. la journalisation.getLogger("Bonjour") auront le même enregistreur de données pour l'ensemble de vos modules.
    InformationsquelleAutor deeshank
  7. 4

    Vous pouvez également venir avec quelque chose de ce genre!

    def get_logger(name=None):
    default = "__app__"
    formatter = logging.Formatter('%(levelname)s: %(asctime)s %(funcName)s(%(lineno)d) -- %(message)s',
                              datefmt='%Y-%m-%d %H:%M:%S')
    log_map = {"__app__": "app.log", "__basic_log__": "file1.log", "__advance_log__": "file2.log"}
    if name:
        logger = logging.getLogger(name)
    else:
        logger = logging.getLogger(default)
    fh = logging.FileHandler(log_map[name])
    fh.setFormatter(formatter)
    logger.addHandler(fh)
    logger.setLevel(logging.DEBUG)
    return logger

    Maintenant, vous pouvez utiliser plusieurs enregistreurs de même module et à travers tout le projet si le ci-dessus est définie dans un module séparé et importés dans d'autres modules ont été la journalisation est nécessaire.

    a=get_logger("__app___")
b=get_logger("__basic_log__")
a.info("Starting logging!")
b.debug("Debug Mode")
    InformationsquelleAutor deeshank
  8. 2

    Il y a plusieurs réponses. j'ai fini avec une similaires, mais différentes, solution qui fait sens pour moi, peut-être que ça aura du sens pour vous.
    Mon principal objectif était d'être en mesure de passer à des journaux, à des gestionnaires de par leur niveau (niveau de débogage journaux de la console, les avertissements et les ci-dessus pour les fichiers):

    from flask import Flask
import logging
from logging.handlers import RotatingFileHandler

app = Flask(__name__)

# make default logger output everything to the console
logging.basicConfig(level=logging.DEBUG)

rotating_file_handler = RotatingFileHandler(filename="logs.log")
rotating_file_handler.setLevel(logging.INFO)

app.logger.addHandler(rotating_file_handler)

    créé une belle util fichier nommé logger.py:

    import logging

def get_logger(name):
    return logging.getLogger("flask.app." + name)

    le flacon.app est une valeur codée en dur dans le flacon. l'application enregistreur est toujours en commençant par flacon.application comme le module du même nom.

    maintenant, dans chaque module, je suis en mesure de l'utiliser dans le mode suivant:

    from logger import get_logger
logger = get_logger(__name__)

logger.info("new log")

    Cela va créer un nouveau journal pour "app.flacon.NOM_DU_MODULE" avec un minimum d'effort.

    InformationsquelleAutor Ben Yitzhaki
  9. 1

    La meilleure pratique serait de créer un module séparément qui n'a qu'une méthode dont la tâche serait de donner un enregistreur de gestionnaire à l'appel de la méthode. Enregistrez ce fichier en tant que m_logger.py

    import logger, logging

def getlogger():
    # logger
    logger = logging.getLogger(__name__)
    logger.setLevel(logging.DEBUG)
    # create console handler and set level to debug
    #ch = logging.StreamHandler()
    ch = logging.FileHandler(r'log.txt')
    ch.setLevel(logging.DEBUG)
    # create formatter
    formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
    # add formatter to ch
    ch.setFormatter(formatter)
    # add ch to logger
    logger.addHandler(ch)
    return logger

    Maintenant appeler les getlogger() la méthode à chaque fois que l'enregistreur de gestionnaire est nécessaire.

    from m_logger import getlogger
logger = getlogger()
logger.info('My mssg')
    • C'est bien si vous n'avez pas de paramètres supplémentaires. Mais si, disons, vous avez --debug option dans l'application et que vous voulez définir le niveau de journalisation dans tous bûcherons dans votre application basée sur ce paramètre...
    • Oui, cela est difficile à atteindre par cette méthode. Ce que nous pouvons faire dans cette situation est que créer une classe pour qui prendrait formateur en paramètre au moment de la création de l'objet et aurait la même fonction pour retourner l'enregistreur de gestionnaire.Quels sont vos avis?
    • Oui,j'ai fait une chose semblable, faite get_logger(level=logging.INFO) pour retourner une sorte de singleton, donc, quand il appelle le premier temps de l'application principale, il initialise l'enregistreur de données et les gestionnaires d'avec le bon niveau, puis renvoie le même logger objet de toutes les autres méthodes.
    InformationsquelleAutor Mousam Singh