2011-07-19 9 views
21

No soy un novato de Django. Estoy intentando iniciar sesión en Django ahora. Mientras trataba, estoy consiguiendo este error [ "No hay manipuladores hemos encontrado nada con logger "muestra""] ..here es mi código,No se encontraron manipuladores para el registrador

(En mi settings.py)

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': False, 
    'formatters': { 
     'simple': { 
      'format': '%(asctime)s %(levelname)s %(name)s %(message)s' 
     }, 
    }, 
    'handlers': { 
     'default': { 
      'level':'DEBUG', 
      'class':'logging.handlers.RotatingFileHandler', 
      'filename': '/home/linuxuser/mani/f/logs/msg.log', 
      'maxBytes': 1024*1024*5, # 5 MB 
      'backupCount': 5, 
      'formatter':'simple', 
     }, 
    }, 
    'loggers': { 
     'sample': { 
      'handlers': ['default'], 
      'level': 'DEBUG', 
      'propagate': True, 
     }, 
    } 
} 

(en mi views.py)

import logging 
import logging.handlers 
from django.conf import settings 
logger = logging.getLogger('sample') 

def empdel(request,id): 
    e = get_object_or_404(emp, pk=id) 
    e.delete() 
    logger.info('A row is deleted successfully !!!') 
    return HttpResponseRedirect('/empthanks/') 

Mientras se ejecuta este código, tengo este error es decir [ "No hay manipuladores hemos encontrado nada con logger 'muestra'"] .. ¿Cuál es incorrecto con mi código? ¿Por qué estoy obteniendo un error así incluso estoy usando controlador en LOGGING? y también estoy tratando de guardar el mensaje de registro en el archivo que he usado en LOGGING ... alguna idea? Gracias por adelantado !!!

+1

Este código exacto funciona para mí (he cambiado el nombre de archivo). ¿Puedes obtener el registrador del 'shell' de Django? ¿Has probado a reiniciar el 'runserver'? – sneeu

+0

@ sneeu: ya funciona ahora. He usado django 1.2.3 antes, así que no funcionaba ... ahora me he actualizado a django 1.3, por lo tanto, está funcionando ahora ... ¿hay más dudas? Guarda mi mensaje de registro (lo que he usado en mi código) y también algunos mensajes predeterminados en ese archivo ... por ejemplo: DEBUG django.db.backends (0.049) alguna consulta sql ... ¿por qué está pasando? ¿Alguna idea? – Mani

+0

Django tiene unos pocos registradores propios que parece que están encendidos, sugiero echar un vistazo a los [documentos] (https://docs.djangoproject.com/en/1.3/topics/logging/#django- s-logging-extensions). – sneeu

Respuesta

22

Los documentos no están claros al respecto, pero cuando utiliza la funcionalidad integrada para especificar la configuración de registro, no necesita obtener una instancia del registrador.

sólo tendría que hacer lo siguiente:

import logging 

def empdel(request,id): 
    e = get_object_or_404(emp, pk=id) 
    e.delete() 
    logging.info('A row is deleted successfully !!!') 
    return HttpResponseRedirect('/empthanks/') 
+9

, creo que está mezclando cosas. Al llamar a las funciones de nivel del módulo en 'logging', el registrador que se utiliza es el registrador de raíz. Su ejemplo es análogo a 'import logging',' logger = logging.getLogger() ',' logger.info (...) '. – glarrain

12

Creo que han entendido mal lo que es un Handler en el contexto del paquete logging.

Un controlador es un objeto que se conecta a un registrador. Cuando el registrador tiene que procesar un mensaje, envía el mensaje a todos sus controladores. Además, los registradores existen en una estructura de árbol, con el registrador "raíz" acertadamente llamado en su raíz. Después de enviar un mensaje a sus manejadores, un registrador puede pasarlo a su padre en el árbol (determinado por el atributo propagate de la instancia de registrador).

Como un lado ligeramente humorístico, una vez encontré un error de aplicación en el que alguien comenzó a usar el Logger llamado "raíz", que es diferente del Root Logger.

No utilice el registrador de raíz (al que se accede por logging.info y compañía, o logging.getLogger()). Cualquier manejador que adjunte o la configuración que modifique también afectará a las bibliotecas que se comportan bien y que propagan sus errores hasta el registrador de raíz. Ejemplo: una vez escribí un script simple usando el registrador de raíz por pereza. Luego incorporé algunas llamadas al boto y obtuve una explosión de mensajes de depuración que se propagaban al registrador de raíz. Se recomienda crear siempre un registrador cuyo nombre coincide con el nombre de su paquete en el espacio de nombres (esto también conduce a la buena estructura de herencia con la interpretación getLogger 's de .) mediante la creación de madereros con logging.getLogger(__name__)

os recomiendo dar una minuciosa leyendo en la sección Objetos del registrador en el logging documentos: https://docs.python.org/2/library/logging.html

Puede observar que su configuración también especifica un Formatter. Los formateadores manejan la presentación de un mensaje cuando lo procesa un Manejador, de modo que un solo mensaje puede formatearse de forma diferente para la salida del terminal que para, por ejemplo, rsyslog.


Todo esto dicho, para fijar su código que puede utilizar el registrador que ha creado, y solo conectar un controlador a la misma. Recomendaría crear un StreamHandler (la clase base Handler no está pensada para ser instanciada, pero por horribles razones no es un ABC), ya que cubre una gran cantidad de casos de uso típicos.

myhandler = logging.StreamHandler() # writes to stderr 
myformatter = logging.Formatter(fmt='%(levelname)s: %(message)s') 
myhandler.setFormatter(myformatter) 
logger.addHandler(myhandler) 

Sin embargo, parece que Django config ya incluye una gran cantidad de esta información, no se configura la forma en que hago las cosas de arriba, por supuesto. Al no haber escrito aplicaciones de Django, no quiero darle información incorrecta sobre esto, pero Django proporciona buenos documentos aquí: https://docs.djangoproject.com/en/dev/topics/logging/

+0

¿qué razones horribles? – n611x007

+1

@naxa No recuerdo con 100% de claridad exactamente lo que tenía en mente, pero probablemente fue solo un lamento por la aversión histórica de Python al ABC. Era una opinión arraigada que la noción de una clase que no se puede instanciar no es necesaria cuando se puede esquivar cosas de tipo. El argumento es que no debería necesitar definir la clase base, simplemente implemente su protocolo. Esa actitud ha cambiado desde que '' logging'' se agregó por primera vez en 2002, y se agregaron ABC en 2007, precisamente debido a casos como la clase Handler base. – sirosen

Cuestiones relacionadas