--- title: "Logging" version: 3.0 locale: pt-br source: https://docs.djangoproject.com/pt-br/3.0/topics/logging/ canonical: https://djangodocs.dev/pt-br/3.0/topics/logging/ --- # Logging ## Uma breve introdução ao log de dados O Django usa o módulo [`logging`](https://docs.python.org/3/library/logging.html#module-logging) da linguagem Python para realizar logs de sistema. A utilização desse módulo é discutida em detalhes na própria documentação do Python. Contudo, se você nunca usou o framework de logs do Python (ou mesmo que você tenha usado), aqui vai um breve resumo. ### O elenco de jogadores A configuração de logs do Python é composta por quatro partes: - [Loggers](#topic-logging-parts-loggers) - [Manipuladores](#topic-logging-parts-handlers) - [Filtros](#topic-logging-parts-filters) - [Formatadores](#topic-logging-parts-formatters) #### Loggers O logger é o ponto de entrada no sistema de logs. Cada logger é um balde nomeado para o qual mensagens podem ser escritas para serem processadas. O logger é configurado para possuir um *level de log*. Esse level descreve o grau de severidade das mensagens que o logger irá manipular. O Python define os seguintes leveis de log: - `DEBUG`: Informações de sistema de baixo nível para propósitos de depuração - `INFO`: Informações gerais de sistema - `WARNING`: Informações descrevendo a ocorrência de um pequeno problema - `ERROR`: Informações descrevendo a ocorrência de um problema grande. - `CRITICAL`: Informações descrevendo a ocorrência de um problema crítico. Cada mensagem que é escrita para o logger é um *Registro de Log*. Cada registro de log também tem um *level de log* indicando a gravidade de cada mensagem em específico. O registro de log pode conter também metadados úteis descrevendo o evento que está sendo logado. Isso pode incluir detalhes como um código de erro ou um “stack trace” ou “rastreamento de pilha” em português. Quando a mensagem é dada ao logger, o level de log da mensagem é comparado com o level de log do logger. Se o level de log da mensagem for igual ou maior que o level de log do próprio logger, a mensagem seguirá em diante para processamento. Caso contrário, a mensagem será ignorada. Se o logger determinar que a mensagem precisa ser processada, ela será passada para um *Handler*. #### Manipuladores O handler ou manipulador em português, é o motor que determina o que acontece com cada mensagem em um logger. Ele descreve o comportamento de um logger em particular, tais como escrever a mensagem na tela, em um arquivo, ou em um socket de rede. Assim como os loggers, os handlers também possuem um level de log. Se o level de um registro de log não for igual ou maior ao level do handler, o handler irá ignorar a mensagem. Cada logger pode ter múltiplos handlers, e cada handler pode ter um level de log diferente. Desta forma, é possível fornecer diferentes formas de notificação dependendo da importância da mensagem. Por exemplo, você pode instalar um handler que encaminha mensagens do tipo `ERROR` e `CRITICAL` para um serviço de paginação, enquanto que um segundo handler loga todas as mensagens (incluindo mensagens do tipo `ERROR` e `CRITICAL`) para um arquivo para análise posterior. #### Filtros O filter ou filtro em português, é usado para fornecer controle adicional sobre quais registros de logs serão passados do logger para o handler. Por padrão, qualquer mensagem de log que satisfaça os pré-requisitos de level de log será manipulada. Contudo, instalando um filtro, você pode colocar critérios adicionais no processamento de logs. Por exemplo, você pode instalar um filtro que permite a emissão de mensagens do tipo `ERROR` de apenas uma fonte em particular. Os filters também podem ser usados para modificar o registro de log antes dele ser emitido. Por exemplo, você pode escrever um filter que rebaixa registros de logs do tipo `ERROR` para registros do tipo `WARNING` se um conjunto de critérios em particular for atingido. Filters podem ser instalados em loggers ou em handlers; múltiplos filters podem ser usados em sequência para realizar múltiplas ações de filtragem. #### Formatadores Finalmente, um registro de log precisa ser renderizado como texto. Formatters ou formatadores em portuguẽs, descrevem o exato formato desse texto. O formatter geralmente consiste de uma string de formatação Python contendo [atributos de um LogRecord](https://docs.python.org/3/library/logging.html#logrecord-attributes); contudo, você também pode escrever um formatador customizado para implementar comportamentos específicos de formatação. ## Using logging Once you have configured your loggers, handlers, filters and formatters, you need to place logging calls into your code. Using the logging framework works like this: ``` # import the logging library import logging # Get an instance of a logger logger = logging.getLogger(__name__) def my_view(request, arg1, arg): ... if bad_mojo: # Log an error message logger.error('Something went wrong!') ``` E é só isso! Toda vez que a condição `bad_mojo` for válida, um registro de log indicando um erro será gravado. ### Nomeando loggers A chamada [`logging.getLogger()`](https://docs.python.org/3/library/logging.html#logging.getLogger) obtém (cria, se necessário) uma instância de um logger. A instância do logger é identificada por um nome. Esse nome é usado para identificar o logger para propósitos de configuração. By convention, the logger name is usually `__name__`, the name of the Python module that contains the logger. This allows you to filter and handle logging calls on a per-module basis. However, if you have some other way of organizing your logging messages, you can provide any dot-separated name to identify your logger: ``` # Get an instance of a specific named logger logger = logging.getLogger('project.interesting.stuff') ``` Os caminhos com pontos do nome de um logger definem a hierarquia. O logger `project.interesting` é considerado como o pai do logger `project.interesting.stuff`; o logger `project` é o pai do logger `project.interesting`. Why is the hierarchy important? Well, because loggers can be set to *propagate* their logging calls to their parents. In this way, you can define a single set of handlers at the root of a logger tree, and capture all logging calls in the subtree of loggers. A logger defined in the `project` namespace will catch all logging messages issued on the `project.interesting` and `project.interesting.stuff` loggers. A propagação pode ser controlada para cada logger em especifico. Se você não quiser que um logger em particular propague para os seus pais, você pode desativar esse comportamento. ### Fazendo chamadas de log Cada instância de um logger contém um método de entrada para cada um dos leveis padrão de log: - `logger.debug()` - `logger.info()` - `logger.warning()` - `logger.error()` - `logger.critical()` Existem ainda outras duas chamadas de log disponíveis: - `logger.log()`: Emite manualmente uma mensagem de log com um level de log em específico. - `logger.exception()`: Cria uma mensagem de log usando o level `ERROR` envolvendo a stack frame, ou estrutura de pilha em português, da exceção atual. ## Configuring logging Evidentemente, não é o bastante apenas adicionar chamadas de log no seu código. Você também precisa confgurar os loggers, handlers, filters e formatters para garantir que a saída de log seja exibida de forma útil. A biblioteca de log do Python fornece várias técnicas para configurar o log, desde uma interface programática até arquivos de configuração. Por padrão, o Django usa o [formato dictConfig](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema). Para configurar os logs, você irá utilizar [`LOGGING`](/pt-br/3.0/ref/settings/#std-setting-LOGGING) para definir um dicionário de configurações de log. Essas configurações descrevem os loggers, handlers, filters e formatters que você deseja usar no seu ambiente de log, assim como os leveis de log e outras propriedads que você deseja que esses componentes possuam. Por padrão, a configuração [`LOGGING`](/pt-br/3.0/ref/settings/#std-setting-LOGGING) é mesclada a [configuração padrão de logs do Django](#default-logging-configuration) usando o esquema a seguir. If the `disable_existing_loggers` key in the [`LOGGING`](/pt-br/3.0/ref/settings/#std-setting-LOGGING) dictConfig is set to `True` (which is the `dictConfig` default if the key is missing) then all loggers from the default configuration will be disabled. Disabled loggers are not the same as removed; the logger will still exist, but will silently discard anything logged to it, not even propagating entries to a parent logger. Thus you should be very careful using `'disable_existing_loggers': True`; it’s probably not what you want. Instead, you can set `disable_existing_loggers` to `False` and redefine some or all of the default loggers; or you can set [`LOGGING_CONFIG`](/pt-br/3.0/ref/settings/#std-setting-LOGGING_CONFIG) to `None` and [handle logging config yourself](#disabling-logging-configuration). O log é configurado como parte da função geral `setup()` do Django. Assim sendo, você pode se certificar que os loggers estarão sempre prontos para serem usados no código do seu projeto. ### Exemplos A documentação completa para [o formato dictConfig](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) é a melhor fonte de informação sobre configuração de dicionários de log. Contudo, para te dar uma ideia das possibilidades, aqui vão vários exemplos. To begin, here’s a small configuration that will allow you to output all log messages to the console: *settings.py* ```python import os LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'class': 'logging.StreamHandler', }, }, 'root': { 'handlers': ['console'], 'level': 'WARNING', }, } ``` This configures the parent `root` logger to send messages with the `WARNING` level and higher to the console handler. By adjusting the level to `INFO` or `DEBUG` you can display more messages. This may be useful during development. Next we can add more fine-grained logging. Here’s an example of how to make the logging system print more messages from just the [django](#django-logger) named logger: *settings.py* ```python import os LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'class': 'logging.StreamHandler', }, }, 'root': { 'handlers': ['console'], 'level': 'WARNING', }, 'loggers': { 'django': { 'handlers': ['console'], 'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'), 'propagate': False, }, }, } ``` By default, this config sends messages from the `django` logger of level `INFO` or higher to the console. This is the same level as Django’s default logging config, except that the default config only displays log records when `DEBUG=True`. Django does not log many such `INFO` level messages. With this config, however, you can also set the environment variable `DJANGO_LOG_LEVEL=DEBUG` to see all of Django’s debug logging which is very verbose as it includes all database queries. You don’t have to log to the console. Here’s a configuration which writes all logging from the [django](#django-logger) named logger to a local file: *settings.py* ```python LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/path/to/django/debug.log', }, }, 'loggers': { 'django': { 'handlers': ['file'], 'level': 'DEBUG', 'propagate': True, }, }, } ``` Se você usar esse exemplo, certifique-se de alterar o caminho `'filename'` para um local com permissões de escrita pelo usuário que estiver rodando a aplicação Django. Finally, here’s an example of a fairly complex logging setup: *settings.py* ```python LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'formatters': { 'verbose': { 'format': '{levelname} {asctime} {module} {process:d} {thread:d} {message}', 'style': '{', }, 'simple': { 'format': '{levelname} {message}', 'style': '{', }, }, 'filters': { 'special': { '()': 'project.logging.SpecialFilter', 'foo': 'bar', }, 'require_debug_true': { '()': 'django.utils.log.RequireDebugTrue', }, }, 'handlers': { 'console': { 'level': 'INFO', 'filters': ['require_debug_true'], 'class': 'logging.StreamHandler', 'formatter': 'simple' }, 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'filters': ['special'] } }, 'loggers': { 'django': { 'handlers': ['console'], 'propagate': True, }, 'django.request': { 'handlers': ['mail_admins'], 'level': 'ERROR', 'propagate': False, }, 'myproject.custom': { 'handlers': ['console', 'mail_admins'], 'level': 'INFO', 'filters': ['special'] } } } ``` Essa configuração de log faz o seguinte: - Identifica a configuração como sendo da ‘versão 1 do formato dictConfig’. Atualmente, essa é a única versão disponível. - Define dois formatters: - `simple`, that outputs the log level name (e.g., `DEBUG`) and the log message. A string `format` é uma string normal de formatação Python descrevendo os detalhes que devem ser exibidos em cada linha de log. A lista completa de detalhes que podem ser exibidos pode ser encontrada em [Formatter Objects](https://docs.python.org/3/library/logging.html#formatter-objects). - `verbose`, que exibe o nome do level de log, a mensagem de log, e também o tempo, o processo, a thread e o módulo que gerou a mensagem de log. - Define dois filters: - `project.logging.SpecialFilter`, utilizando o alias `special`. Se esse filtro necessitar de argumentos adicionais, eles podem ser fornecidos como chaves adicionais no dicionário de configuração do filter. Nesse caso, o argumento `foo` será dado para o valor de `bar` na instanciação de `SpecialFilter`. - `django.utils.log.RequireDebugTrue`, que transmite registros quando [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) é `True`. - Define dois handlers: - `console`, a [`StreamHandler`](https://docs.python.org/3/library/logging.handlers.html#logging.StreamHandler), which prints any `INFO` (or higher) message to `sys.stderr`. This handler uses the `simple` output format. - `mail_admins`, an [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler), which emails any `ERROR` (or higher) message to the site [`ADMINS`](/pt-br/3.0/ref/settings/#std-setting-ADMINS). This handler uses the `special` filter. - Configura três loggers: - `django`, que transmite todas as mensagens para o handler `console`. - `django.request`, que transmite todas as mensagens do tipo `ERROR` para o handler `mail_admins`. Adicionalmente, esse logger é marcado para *não* propagar mensagens. Isso significa que as mensagens de log gravadas em `django.request` não serão manipuladas pelo logger `django`. - `myproject.custom`, que transmite todas as mensagens do level `INFO` ou maior e que também transmite o filtro `special` para dois handlers – o `console`, e o `mail_admins`. Isso significa que todas as mensagens de level `INFO` (ou maiores) serão exibidas no console; mensagens `ERROR` e `CRITICAL` também serão emitidas via email. ### Configurações customizadas de log Se você não quer usar o formato dictConfig do Python para configurar o seu logger, você pode especificar o seu próprio esquema de configuração. A configuração [`LOGGING_CONFIG`](/pt-br/3.0/ref/settings/#std-setting-LOGGING_CONFIG) define o callable que será usado para configurar os loggers do Django. Por padrão, ele aponta para a função [`logging.config.dictConfig()`](https://docs.python.org/3/library/logging.config.html#logging.config.dictConfig) do Python. Contudo, se você quiser usar um processo diferente de configuração, você pode usar qualquer outro callable que recebe um único argumento. O conteúdo de [`LOGGING`](/pt-br/3.0/ref/settings/#std-setting-LOGGING) será fornecido como sendo o valor do argumento onde o log será configurado. ### Desabilitando a configuração de log Se você não quser configurar qualquer tipo de log (ou se você deseja configurar o log manualmente usando sua própria abordagem), você pode definir [`LOGGING_CONFIG`](/pt-br/3.0/ref/settings/#std-setting-LOGGING_CONFIG) para `None`. Isso irá desabilitar o processo de configuração para [configuração de log padrão do Django](#default-logging-configuration). Segue um exemplo de uma configuração que desabilita a configuração de logs do Django e então configura o log manualemente: *settings.py* ```python LOGGING_CONFIG = None import logging.config logging.config.dictConfig(...) ``` Configurar [`LOGGING_CONFIG`](/pt-br/3.0/ref/settings/#std-setting-LOGGING_CONFIG) como `None` significa tão somente que o processo de configuração automática está desabilitado, não os logs em si. Se você desabilitar o processo de configuração, o Django ainda fará chamadas de logs, recorrendo a qualquer comportamento padrão de log que for definido. ## Extensões de log do Django O Django fornece uma série de recursos para lidar com requisitos únicos de log em ambientes de Web servers. ### Loggers O Django fornece vários loggers embutidos. #### `django` The catch-all logger for messages in the `django` hierarchy. No messages are posted using this name but instead using one of the loggers below. #### `django.request` Log messages related to the handling of requests. 5XX responses are raised as `ERROR` messages; 4XX responses are raised as `WARNING` messages. Requests that are logged to the `django.security` logger aren’t logged to `django.request`. Mensagens para esse logger possuem o seguinte contexto adicional: - `status_code`: o código da resposta HTTP associado a requisição. - `request`: O objeto da requisição que gerou a mensagem de log. #### `django.server` Mensagens de log relacionadas com a manipulação de requisições recebidas pelo comando [`runserver`](/pt-br/3.0/ref/django-admin/#django-admin-runserver). Respostas HTTP 5XX são logadas como mensagens do tipo `ERROR`, respostas HTTP 4XX são logadas como mensagens do tipo `WARNING`, e todo o resto é logado como `INFO`. Mensagens para esse logger possuem o seguinte contexto adicional: - `status_code`: o código da resposta HTTP associado a requisição. - `request`: O objeto da requisição que gerou a mensagem de log. #### `django.template` Mensagens de log relacionadas a renderização de templates. - Variáveis de contexto esquecidas são logadas como mensagens do tipo `DEBUG`. #### `django.db.backends` Mensagens relacionadas a interação de código com o banco de dados. Por exemplo, cada comando SQL executado por uma requisição é logada no level `DEBUG` para esse logger. Mensagens para esse logger possuem o seguinte contexto adicional: - `duration`: O tempo tomado para executar o comando SQL. - `sql`: O comando SQL que foi executado. - `params`: Os parâmetros que foram usados na chamada SQL. Por questões de performance, o log de SQL só é ativado quando `settings.DEBUG` é configurado como `True`, independentemente do level de log ou dos handlers que estão instalados. Nesse logger não estão incluídos initializações a level de framework (ex `SET TIMEZONE`) ou consultas relacionadas ao gerenciamento de transações (ex `BEGIN`, `COMMIT`, e `ROLLBACK`). Ative o log de consultas no seu banco de dados se você desejar ver todas as consultas de banco. #### `django.security.*` Os loggers de segurança irão receber mensagens em qualquer ocorrência de [`SuspiciousOperation`](/pt-br/3.0/ref/exceptions/#django.core.exceptions.SuspiciousOperation) e outros erros relacionados a segurança. Existe um sub-logger para cada subtipo de erro de segurança, incluindo todos do tipo `SuspiciousOperation`s. O level de log depende de onde a exceção for manipulada. A maioria das ocorrências serão logadas como um aviso. enquanto que qualquer `SuspiciousOperation`s que alcançar o handler WSGI será logada como um erro. Por exemplo, quando um cabeçalho HTTP `Host` é incluído em uma requisição de um cliente que não for encontrado em [`ALLOWED_HOSTS`](/pt-br/3.0/ref/settings/#std-setting-ALLOWED_HOSTS), Django irá retornar uma resposta 400, e uma mensagem de erro será logada para o logger `django.security.DisallowedHost`. Esses eventos de log irão alcançar o logger `django` por padrão, que irá enviar emails de eventos de erro para os administradores quando `DEBUG=False`. Requisições resultando em uma resposta 400 devido a uma `SuspiciousOperation` não serão logadas no logger `django.request`, mas somente para o logger `django.security`. To silence a particular type of `SuspiciousOperation`, you can override that specific logger following this example: ``` 'handlers': { 'null': { 'class': 'logging.NullHandler', }, }, 'loggers': { 'django.security.DisallowedHost': { 'handlers': ['null'], 'propagate': False, }, }, ``` Outros loggers `django.security` não baseados em `SuspiciousOperation` são: - `django.security.csrf`: Para [falhas CSRF](/pt-br/3.0/ref/csrf/#csrf-rejected-requests). #### `django.db.backends.schema` Loga as consultas SQL que são executadas durante mudanças de esquema no banco de dados pelo [migrations framework](/pt-br/3.0/topics/migrations/). Note que ele não irá logar as consultas executadas pela classe [`RunPython`](/pt-br/3.0/ref/migration-operations/#django.db.migrations.operations.RunPython). As mensagens para esse logger possuem `params` e `sql` em seu contexto extra (mas ao contrário de `django.db.backends`, não possui `duration`). Os valores tem o mesmo significado como explicado em [django.db.backends](#django-db-logger). ### Manipuladores O Django fornece um handler de log adicional para os já fornecidos pelo módulo de log do Python. #### `class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)` This handler sends an email to the site [`ADMINS`](/pt-br/3.0/ref/settings/#std-setting-ADMINS) for each log message it receives. Se o registro de log contém um atributo `request`, todos os detalhes da requisição serão incluídos no email. O assunto do email irá incluir a fase “internal IP” se o endereço IP do cliente foi informado em [`INTERNAL_IPS`](/pt-br/3.0/ref/settings/#std-setting-INTERNAL_IPS); Caso contrário, ele irá incluir o “EXTERNAL IP”. Se o registro de log contiver infromações de rastreamento de pilha, o rastreamento de pilha será incluído no email. The `include_html` argument of `AdminEmailHandler` is used to control whether the traceback email includes an HTML attachment containing the full content of the debug Web page that would have been produced if [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) were `True`. To set this value in your configuration, include it in the handler definition for `django.utils.log.AdminEmailHandler`, like this: ``` 'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'include_html': True, } }, ``` Note que a versão HTML do email contém um traceback completo, com nomes e valores de variáveis locais em cada level da pilha, além dos valores da sua configuração do Django. Essa informação é potencialmente muito sensível, e você pode não querer enviá-la por email. Considere usar algo como [Sentry](https://pypi.org/project/sentry/) para obter o melhor dos dois mundos – a rica informação dos tracebacks completos e mais a segurança de *não* enviar informações por email. Você pode também explicitamente designar certas informações sensíveis para serem filtradas para fora dos relatórios de erro – saiba mais em [Filtrando relatórios de erro](/pt-br/3.0/howto/error-reporting/#filtering-error-reports). By setting the `email_backend` argument of `AdminEmailHandler`, the [email backend](/pt-br/3.0/topics/email/#topic-email-backends) that is being used by the handler can be overridden, like this: ``` 'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'email_backend': 'django.core.mail.backends.filebased.EmailBackend', } }, ``` Por padrão, uma instância do backend de email especificado em [`EMAIL_BACKEND`](/pt-br/3.0/ref/settings/#std-setting-EMAIL_BACKEND) será usado. The `reporter_class` argument of `AdminEmailHandler` allows providing an `django.views.debug.ExceptionReporter` subclass to customize the traceback text sent in the email body. You provide a string import path to the class you wish to use, like this: ``` 'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log.AdminEmailHandler', 'include_html': True, 'reporter_class': 'somepackage.error_reporter.CustomErrorReporter' } }, ``` > **New in Django 3.0** > > The `reporter_class` argument was added. #### `send_mail(subject, message, *args, **kwargs)` Envia emails para os usuários administradores. Para customizar esse comportamento, você pode fazer uma subclasse de [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler) e sobrescrever esse método. ### Filtros Django provides some log filters in addition to those provided by the Python logging module. #### `class CallbackFilter(callback)` Esse filter aceita uma função de callback (que deve aceitar um único argumento, o registro a ser logado), e chama essa função para cada registro que passa pelo filter. A manipulação desse registro não será continuada caso a função de callback retorne False. Por exemplo, para filtrar para fora exceções do tipo [`UnreadablePostError`](/pt-br/3.0/ref/exceptions/#django.http.UnreadablePostError) (levantadas quando o usuário cancela um upload) de emails destinadoas a administradores, você teria que criar uma função de filtro: ``` from django.http import UnreadablePostError def skip_unreadable_post(record): if record.exc_info: exc_type, exc_value = record.exc_info[:2] if isinstance(exc_value, UnreadablePostError): return False return True ``` and then add it to your logging config: ``` 'filters': { 'skip_unreadable_posts': { '()': 'django.utils.log.CallbackFilter', 'callback': skip_unreadable_post, } }, 'handlers': { 'mail_admins': { 'level': 'ERROR', 'filters': ['skip_unreadable_posts'], 'class': 'django.utils.log.AdminEmailHandler' } }, ``` #### `class RequireDebugFalse` Esse filtro irá passar adiante registros de logs somente quando settings.DEBUG for False. This filter is used as follows in the default [`LOGGING`](/pt-br/3.0/ref/settings/#std-setting-LOGGING) configuration to ensure that the [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler) only sends error emails to admins when [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) is `False`: ``` 'filters': { 'require_debug_false': { '()': 'django.utils.log.RequireDebugFalse', } }, 'handlers': { 'mail_admins': { 'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler' } }, ``` #### `class RequireDebugTrue` Esse filtro é similar a [`RequireDebugFalse`](#django.utils.log.RequireDebugFalse), exceto pelo fato de que os registros são passados adiante somente quando [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) é `True`. ## A configuração default de log do Django Por padrão, o Django configura o log da seguinte forma: Quando [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) é `True`: - The `django` logger sends messages in the `django` hierarchy (except `django.server`) at the `INFO` level or higher to the console. Quando [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG) é `False`: - The `django` logger sends messages in the `django` hierarchy (except `django.server`) with `ERROR` or `CRITICAL` level to [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler). Independentemente do valor de [`DEBUG`](/pt-br/3.0/ref/settings/#std-setting-DEBUG): - The [django.server](#django-server-logger) logger sends messages at the `INFO` level or higher to the console. All loggers except [django.server](#django-server-logger) propagate logging to their parents, up to the root `django` logger. The `console` and `mail_admins` handlers are attached to the root logger to provide the behavior described above. See also [Configuring logging](#configuring-logging) to learn how you can complement or replace this default logging configuration defined in [django/utils/log.py](https://github.com/django/django/blob/stable/3.0.x/django/utils/log.py).