Gunicorn Airflow спам-журналы ошибок - PullRequest
Новая
       33

Gunicorn Airflow спам-журналы ошибок

0 голосов
/ 14 мая 2018

Я использую Apache Airflow и обнаружил, что размер gunicorn-error.log вырос более чем на 50 ГБ в течение 5 месяцев.Большинство сообщений журнала представляют собой журналы уровня INFO, такие как:

[2018-05-14 17:31:39 +0000] [29595] [INFO] Сигнал обработки: ttou
[2018-05-14 17:32:37 +0000] [2359] [INFO] Рабочий выходит (pid: 2359)
[2018-05-14 17:33:07 +0000] [29595] [INFO] Сигнал обработки:ttin
[2018-05-14 17:33:07 +0000] [5758] [INFO] Загрузка работника с pid:
5758 [2018-05-14 17:33:10 +0000] [29595][INFO] Обработка сигнала: ttou [2018-05-14 17:33:41 +0000] [2994] [INFO] Рабочий выходит (pid: 2994)
[2018-05-14 17:34:11 +0000] [29595] [INFO] Сигнал обработки: ttin
[2018-05-14 17:34:11 +0000] [6400] [INFO] Загрузка работника с pid: 6400 [2018-05-14 17:34:13 +0000] [29595] [INFO] Сигнал обработки: ttou
[2018-05-14 17:34:36 +0000] [3611] [INFO] Рабочий выходит (pid: 3611)

В файле конфигурации Airflow я могу только указать путь к файлу журнала.Кто-нибудь знает, как изменить регистрацию Gunicorn на другой уровень в Airflow?Мне не нужен этот мелкозернистый уровень ведения журнала, потому что он переполняет мой жесткий диск.

Ответы [ 2 ]

0 голосов
/ 23 апреля 2019

Мне удалось решить проблему, установив переменную среды

GUNICORN_CMD_ARGS "--log-level WARNING"

0 голосов
/ 03 августа 2018

Ведение воздушного потока мне кажется немного сложным в Airflow. Одна из причин заключается в том, что регистрация делится на несколько частей. Например, конфигурация регистрации для Airflow полностью отличается от конфигурации веб-сервера gunicorn (журналы «спама», которые вы упоминаете в своих сообщениях, происходят от gunicorn).

Чтобы решить эту проблему со спамом, я немного изменил bin / cli.py в Airflow, добавив несколько строк в функцию webserver (): 

   if args.log_config:
        run_args += ['--log-config', str(args.log_config)]

(ради краткости я не вставил код для обработки аргумента)

А затем, что касается файла конфигурации журнала, у меня есть что-то похожее на: 

[loggers]
keys=root, gunicorn.error, gunicorn.access

[handlers]
keys=console, error_file, access_file

[formatters]
keys=generic, access

[logger_root]
level=INFO
handlers=console

[logger_gunicorn.error]
level=INFO
handlers=error_file
propagate=0
qualname=gunicorn.error

[logger_gunicorn.access]
level=INFO
handlers=access_file
propagate=1
qualname=gunicorn.access

[handler_console]
class=StreamHandler
formatter=generic
args=(sys.stdout, )

[handler_error_file]
class=logging.handlers.TimedRotatingFileHandler
formatter=generic
args=('/home/airflow/airflow/logs/webserver/gunicorn.error.log',)

[handler_access_file]
class=logging.handlers.TimedRotatingFileHandler
formatter=access
args=('/home/airflow/airflow/logs/webserver/gunicorn.access.log',)

[formatter_generic]
format=[%(name)s] [%(module)s] [%(asctime)s] {%(filename)s:%(lineno)d} %(levelname)s - %(message)s
#format=[%(levelname)s] %(asctime)s [%(process)d] [%(levelname)s] %(message)s
datefmt=%Y-%m-%d %H:%M:%S
class=logging.Formatter

[formatter_access]
format=%(message)s
class=logging.Formatter

Обратите внимание на "тип распространения = 0" в gunicorn.error, который позволяет избежать спама в вашем стандартном выводе. У вас все еще они есть, но, по крайней мере, они локализованы в /home/airflow/airflow/logs/webserver/gunicorn.error.log, который должен быть повернут (если честно, я еще не полностью протестировал вращающуюся часть).

Если у меня будет время, я отправлю это изменение как билет Jira для Airflow.

...