Файл error.log Gunicorn показывает ошибку в журнале, но сам Gunicorn работает.

Содержание

Вопрос или проблема
Ответ или решение
Ошибка в файле error.log Gunicorn, но работа сервера без проблем
1. Анализ логов
2. Причины возникновения записей в error.log
3. Рекомендации по исправлению ситуации
Заключение

Вопрос или проблема

Я настроил 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] Используя worker: gthread
[2024-12-05 04:36:15 +0000] [88] [INFO] Запуск worker с pid: 88
[2024-12-05 04:36:15 +0000] [89] [INFO] Запуск worker с pid: 89
[2024-12-05 04:36:15 +0000] [90] [INFO] Запуск worker с pid: 90
[2024-12-05 04:36:15 +0000] [91] [INFO] Запуск worker с 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"

Ответ или решение

Ошибка в файле error.log Gunicorn, но работа сервера без проблем

При настройке веб-приложений с использованием Nginx и Gunicorn, сталкиваться с различными проблемами неизбежно. В вашем случае, несмотря на отсутствие критических ошибок в работе сервера, запись в файле error.log Gunicorn вызывает вопросы. Давайте разберемся, что может быть причиной этого явления и как правильно с ним работать.

1. Анализ логов

Согласно предоставленным вами данным, файл error.log имеет размер 1 Кб и при его открытии содержит только информационные сообщения о старте процесса Gunicorn:

[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, что само по себе является положительным знаком. Однако отсутствие критических записей и наличие концевых сообщений могут вызывать недоумение.

2. Причины возникновения записей в error.log

Возможные источники записей в error.log могут включать:

Информационные сообщения: Некоторые настройки конфигурации могут вызывать вывод информационных сообщений в error.log. Gunicorn выводит лог уровня INFO, даже если приложение работает корректно.
Предупреждения: Если ваше приложение или сам Gunicorn генерируют предупреждения (например, связанные с конфигурацией), они также могут записываться в error.log.
Неполадки на уровне приложения: Если ваше Django приложение имеет ошибки, которые не мешают ему функционировать, Gunicorn может фиксировать их в error.log.

3. Рекомендации по исправлению ситуации

Измените уровень логирования: Если наличие информационных сообщений в error.log вам не нужно, вы можете изменить уровень логирования. Достаточно в конфигурации Gunicorn задать loglevel = "WARNING" или loglevel = "ERROR", чтобы увеличить порог записываемых сообщений.
Проверьте приложение на наличие ошибок: Если вы подозреваете наличие ошибок в вашем приложении, выполните его тестирование и просмотрите Django логи на наличие исключений.
Настройте автоматическую обработку логов: Если необходимо, вы можете использовать средства мониторинга логов, такие как ELK-stack (Elasticsearch, Logstash, Kibana) или другие для централизованного управления логами и облегчения поиска ошибок.
Проверка конфигурации Nginx: Убедитесь, что конфигурационные файлы Nginx правильно настроены и что он корректно проксирует запросы к Gunicorn.
Убедитесь в корректности скрипта запуска: Проверьте, правильно ли выполняется ваш скрипт myscript.sh. Убедитесь, что обе службы (Nginx и Gunicorn) запускаются без ошибок.

Заключение

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

Если проблема продолжает сохраняться, рассмотрите возможность обращения в сообщество разработчиков Django или на специализированные форумы по Gunicorn, чтобы получить дополнительные советы и рекомендации.