Правильная конфигурация ведения журнала для отключения сообщений об ошибках django - PullRequest
4 голосов
/ 30 мая 2020

Я только что получил часовую, работающую в моей среде, и я попытался настроить свой журнал, чтобы он больше не отправлял сообщения об ошибках, но это все еще есть, и я не понимаю, почему. Моя конфигурация ведения журнала:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "verbose": {
            "format": '%(levelname)s %(asctime)s (%(pathname)s %(funcName)s): "%(message)s"'
        },
        "simple": {"format": "%(levelname)s %(message)s"},
        "django.server": {
            "()": "django.utils.log.ServerFormatter",
            "format": "[%(server_time)s] %(message)s",
        },
    },
    "handlers": {
        "null": {"level": "DEBUG", "class": "logging.NullHandler",},
        "console": {
            "level": "DEBUG",
            "class": "logging.StreamHandler",
            "formatter": "simple",
        },
        "log_file": {
            "level": "DEBUG",
            "class": "logging.handlers.RotatingFileHandler",
            "filename": "/var/log/courtlistener/django.log",
            "maxBytes": "16777216",  # 16 megabytes
            "formatter": "verbose",
        },
        "django.server": {
            "level": "INFO",
            "class": "logging.StreamHandler",
            "formatter": "django.server",
        },
    },
    "loggers": {
        # Disable SuspiciousOperation.DisallowedHost exception ("Invalid
        # HTTP_HOST" header messages.) This appears to be caused by clients that
        # don't support SNI, and which are browsing to other domains on the
        # server. The most relevant bad client is the googlebot.
        "django.security.DisallowedHost": {
            "handlers": ["null"],
            "propagate": False,
        },
        "django.server": {
            "handlers": ["django.server"],
            "level": "INFO",
            "propagate": False,
        },
        # This is the one that's used practically everywhere in the code.
        "cl": {"handlers": ["log_file"], "level": "INFO", "propagate": True,},
    },
}

Здесь что-то не хватает? Я не знаю, как это могло отправлять электронные письма. Есть ли еще одна конфигурационная переменная, о которой я должен подумать?

ОБНОВЛЕНИЕ : Я заметил одну вещь: теперь я получаю сообщения об ошибках в виде обычного текста вместо HTML те, которые я получал. Это изменилось, когда я настроил конфигурацию ведения журнала, но я понятия не имею, почему, и поиск в Google, похоже, ничего не показывает.

Ответы [ 2 ]

2 голосов
/ 10 июня 2020

Django устанавливает обработчик по умолчанию mail_admins, который вы не можете просто заменить в разделе handlers, поэтому, если вы хотите избавиться от него, вам нужно перезаписать handlers в регистраторе root:

Все регистраторы, кроме django .server, передают ведение журнала своим родителям, вплоть до регистратора root django. Обработчики console и mail_admins прикреплены к регистратору root для обеспечения описанного выше поведения.

LOGGING = {
    'loggers': {
        'django': {
            'handlers': [],
            'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'),
            'propagate': False,
        },
    },

}

[edit] исправлено неправильное утверждение о перезаписи класса обработчика, к сожалению, это не работает как и ожидалось, похоже, каким-то образом жестко запрограммирован (слишком занят, чтобы искать его в базе кода django).

1 голос
/ 09 июня 2020

Ваша LOGGING конфигурация выглядит (почти, до конца) мне хорошо. Я могу придумать еще несколько вещей.

Возможно, вы внесли изменения, но не везде, у вас могут быть другие приложения, процессы с сельдереем, промежуточные развертывания и т. Д. c. работает где-то, о чем вы забыли.

Возможно, что-то еще (я не уверен, что ...) настраивает этот обработчик журналов. В этом случае вы можете отключить существующие регистраторы:

LOGGING = {
    "disable_existing_loggers": True,
    ...
}

Это не очень хорошая идея, отключать чужие регистраторы, так что в качестве альтернативы вы можете отключить его другим способом.

Параметр ADMINS определяет адреса электронной почты для отправки ошибок, поэтому вы можете отключить его, просто установив пустой список:

ADMINS = []

Это должно быть относительно безопасно, как отправка Сообщения об ошибках - единственное, для чего используется этот параметр - если вы или стороннее приложение не используете его.

Вы также можете получать электронные письма не с ошибками сервера, а с ошибками 404. Убедитесь, что ваш MIDDLEWARE не содержит BrokenLinkEmailsMiddleware. Для этого также существует настройка, аналогичная ADMINS, но она называется MANAGERS:

MANAGERS = []

Вы также должны проверить конфигурацию ведения журнала по умолчанию , чтобы убедиться, что у вас нет Я что-то пропустил при создании собственного LOGGING dict.

Еще одна вещь, которую я заметил при подключении конфигурации LOGGING к проекту, заключается в том, что конфигурация не анализируется правильно для меня, потому что значение maxBytes должно быть целым числом, а не строкой. Так что вы также можете попробовать изменить:

"log_file": {
    "level": "DEBUG",
    "class": "logging.handlers.RotatingFileHandler",
    "filename": "/var/log/courtlistener/django.log",
    "maxBytes": "16777216",  # 16 megabytes
    "formatter": "verbose",
}

на:

"log_file": {
    "level": "DEBUG",
    "class": "logging.handlers.RotatingFileHandler",
    "filename": "/var/log/courtlistener/django.log",
    "maxBytes": 16777216,  # 16 megabytes
    "formatter": "verbose",
}
...