Вопрос или проблема
Я настроил Nginx с Gunicorn и Django. Все кажется работающим нормально, по крайней мере, я так думал. Однако, когда я проверяю директорию .gunicorn-logs, которая должна быть создана в Docker, как указано в моем скрипте myscript.sh ниже, она показывает 2 файла:
access.log с всеми обращениями к серверу Gunicorn и
error.log, который должен быть пустым, показывает 1 Кб файла.
При проверке я получаю следующее внутри --->
Файл error.log Gunicorn --->
[2024-12-05 04:36:15 +0000] [85] [INFO] Запускается gunicorn 23.0.0
[2024-12-05 04:36:15 +0000] [85] [INFO] Слушает на: http://0.0.0.0:8585 (85)
[2024-12-05 04:36:15 +0000] [85] [INFO] Используется работник: gthread
[2024-12-05 04:36:15 +0000] [88] [INFO] Запускается работник с pid: 88
[2024-12-05 04:36:15 +0000] [89] [INFO] Запускается работник с pid: 89
[2024-12-05 04:36:15 +0000] [90] [INFO] Запускается работник с pid: 90
[2024-12-05 04:36:15 +0000] [91] [INFO] Запускается работник с pid: 91
Файл access.log Gunicorn --->
49.xxx.xxx.xx - - [05/Dec/2024:10:06:26 +0530] "GET /admin/login/?next=/admin/ HTTP/1.1" 200 4158 "-" "PostmanRuntime/7.43.0"
127.0.0.1 - - [05/Dec/2024:10:06:35 +0530] "GET /static/admin/ HTTP/1.1" 302 0 "-" "PostmanRuntime/7.43.0"
127.0.0.1 - - [05/Dec/2024:10:06:36 +0530] "GET /admin/login/?next=/static/admin/ HTTP/1.1" 200 4172 "http://34.xxx.xxx.xx:75/static/admin/" "PostmanRuntime/7.43.0"
127.0.0.1 - - [05/Dec/2024:10:06:42 +0530] "GET /static/admin/ HTTP/1.1" 302 0 "-" "PostmanRuntime/7.43.0"
127.0.0.1 - - [05/Dec/2024:10:06:42 +0530] "GET /admin/login/?next=/static/admin/ HTTP/1.1" 200 4172 "http://34.xxx.xxx.xx:75/static/admin/" "PostmanRuntime/7.43.0"
Файлы логов nginx содержат только заполненный access.log, а error.log пуст.
Файл access.log Nginx ---->
49.xxx.xxx.xx - - [05/Dec/2024:04:36:35 +0000] "GET /static/admin/ HTTP/1.1" 302 0 "-" "PostmanRuntime/7.43.0" "-"
49.xxx.xxx.xx - - [05/Dec/2024:04:36:36 +0000] "GET /admin/login/?next=/static/admin/ HTTP/1.1" 200 1522 "http://34.xxx.xxx.xx:75/static/admin/" "PostmanRuntime/7.43.0" "-"
49.xxx.xxx.xx - - [05/Dec/2024:04:36:42 +0000] "GET /static/admin/ HTTP/1.1" 302 0 "-" "PostmanRuntime/7.43.0" "-"
49.xxx.xxx.xx - - [05/Dec/2024:04:36:42 +0000] "GET /admin/login/?next=/static/admin/ HTTP/1.1" 200 1526 "http://34.xxx.xxx.xx:75/static/admin/" "PostmanRuntime/7.43.0" "-"
Вот как я определил строки, связанные с сервером Gunicorn, внутри Dockerfile.
RUN mkdir -p .gunicorn-logs
RUN touch /opt/.gunicorn-logs/error.log
RUN touch /opt/.gunicorn-logs/access.log
RUN chmod +x /opt/.gunicorn-logs/
cmd myscript.sh
Скрипт myscript.sh, где запускаются как nginx, так и gunicorn —>
#!/bin/sh
nginx -g 'daemon off;' &
gunicorn mydjangoapi.wsgi:application --config=gunicorn_config_api-1.py
Наконец, gunicorn_config_api-1.py в корневой папке —>
bind = "0.0.0.0:8585"
loglevel = "INFO"
workers = "4"
threads="10"
reload = True
errorlog = "/opt/.gunicorn-logs/error.log"
accesslog = "/opt/.gunicorn-logs/access.log"
Когда вы устанавливаете loglevel = "INFO", вы выбираете сообщения с серьезностью [INFO]. Полностью ожидаемо, что вы их увидите, после того как специально запросили их.
Ответ или решение
Проблема, с которой вы столкнулись, касается поведения Gunicorn и логирования в вашем приложении Django, запущенном в Docker с использованием Nginx в качестве обратного прокси. Давайте разберёмся подробнее.
Анализ ситуации
1. Логи Gunicorn
Вы заметили, что файл error.log в директории .gunicorn-logs весит 1 КБ, хотя вы ожидали, что он будет пустым. Внутри этого лог-файла содержатся записи с уровнями информационных сообщений:
[2024-12-05 04:36:15 +0000] [85] [INFO] Starting gunicorn 23.0.0
[2024-12-05 04:36:15 +0000] [85] [INFO] Listening at: http://0.0.0.0:8585 (85)
[2024-12-05 04:36:15 +0000] [85] [INFO] Using worker: gthread
[2024-12-05 04:36:15 +0000] [88] [INFO] Booting worker with pid: 88
...Данные записи не являются ошибками, а представляют собой стандартные информационные сообщения, которые Gunicorn генерирует при инициализации. Поскольку вы указали loglevel = "INFO" в настройках вашего Gunicorn, это означает, что ваше приложение будет записывать все сообщения с уровнем "INFO" и выше, включая информационные сообщения о запуске Gunicorn и его воркеров.
2. Логи Nginx
Вы также отметили, что файл error.log для Nginx пуст, в то время как в access.log есть записи запросов. Это может указывать на то, что Nginx корректно обрабатывает запросы и не сталкивается с критическими ошибками, что также является хорошим знаком.
Решение проблемы
Таким образом, у вас нет реальной ошибки, которая мешала бы работе вашего приложения. Однако, если вы хотите избежать записи информационных сообщений в error.log, вы можете изменить уровень логирования в конфигурации Gunicorn. Если вам не нужны сообщения с уровнем "INFO", вы можете установить его на более высокий уровень, например, "WARNING":
loglevel = "WARNING"Параметры конфигурации Gunicorn
Ваш файл конфигурации для Gunicorn (gunicorn_config_api-1.py) выглядит правильно, и вы правильно инициализируете логи. Убедитесь, что пути к логам являются доступными и имеют необходимые права для записи.
Примечания
-
Обновите Gunicorn: Убедитесь, что вы используете актуальную версию Gunicorn. Например, в вашем случае версия 23.0.0 может быть устаревшей. Обновление до последней стабильной версии может исправить некоторые проблемы с логгированием.
-
Проверка прав доступа: Проверьте права доступа к директории
.gunicorn-logsи убедитесь, что процесс Gunicorn имеет права на запись в эти файлы. -
Использование других уровней логирования: Если вы хотите больше контроля над логированием, вы можете настроить дополнительные параметры или использовать собственные обработчики логов для более детального управления.
Заключение
Вы на правильном пути, и ваше приложение на Django с Nginx и Gunicorn уже корректно функционирует. Логи, которые вы видите, лишь информируют о состоянии сервера и не указывают на ошибки. Рекомендуется следовать указанным выше рекомендациям для оптимизации логирования.