Удалить журналы планировщика воздушного потока

Я использую Docker Apache airflow ВЕРСИИ 1.9.0-2 (https://github.com/puckel/docker-airflow).

Планировщик создает значительное количество журналов, а файловая система быстро исчерпывает пространство, поэтому я пытаюсь программно удалить журналы планировщика, созданные воздушным потоком, найденные в контейнере планировщика в (/ usr / local / airflow / logs / scheduler )

У меня настроены все эти задачи обслуживания: https://github.com/teamclairvoyant/airflow-mainasted-dags

Однако эти задачи удаляют только журналы рабочего, а журналы планировщика находятся в контейнере планировщика.

Я также настроил удаленное ведение журнала, отправив журналы на S3, но, как упоминалось в этом сообщении SO, Удаление журналов задач Airflow эта настройка не останавливает воздушный поток от записи на локальную машину.

Кроме того, я также попытался создать общий именованный том между рабочим и планировщиком, как описано здесь Docker Compose - совместное использование именованного тома между несколькими контейнерами. Однако я получаю следующую ошибку в worker:

ValueError: Unable to configure handler 'file.processor': [Errno 13] Permission denied: '/usr/local/airflow/logs/scheduler'

и следующая ошибка в планировщике:

ValueError: Unable to configure handler 'file.processor': [Errno 13] Permission denied: '/usr/local/airflow/logs/scheduler/2018-04-11'

Итак, как люди удаляют журналы планировщика ??


docker docker-volume docker-compose airflow airflow-scheduler
person Ryan Stack    schedule 11.04.2018    source источник

Ответы (4)


arrow_upward
10
arrow_downward

Вдохновленный этим ответом, я добавил airflow-log-cleanup.py DAG (с некоторыми изменениями его параметров) из здесь, чтобы удалить все старые журналы воздушного потока, включая планировщик. журналы.

Мои изменения незначительны, за исключением того, что, учитывая размер моего диска EC2 (7,7 ГБ для /dev/xvda1), 30-дневное значение по умолчанию для DEFAULT_MAX_LOG_AGE_IN_DAYS казалось слишком большим, поэтому (у меня было 4 DAG) я изменил его на 14 дней, но не стесняйтесь настраивать его в соответствии с вашими среда:

DEFAULT_MAX_LOG_AGE_IN_DAYS = Variable.get("max_log_age_in_days", 30) изменен на DEFAULT_MAX_LOG_AGE_IN_DAYS = Variable.get("max_log_age_in_days", 14)

person HaMi    schedule 22.05.2018

arrow_upward
4
arrow_downward

Следующее может быть одним из вариантов решения этой проблемы.

Войдите в контейнер докеров, используя следующий механизм

#>docker exec -it <name-or-id-of-container> sh

Выполняя указанную выше команду, убедитесь, что контейнер запущен.

а затем используйте задания cron для настройки запланированной команды rm для этих файлов журнала.

person fly2matrix    schedule 12.04.2018
comment
Ссылка на задание cron: cyberciti.biz/faq/ - person fly2matrix; 12.04.2018
comment
Ха, я действительно думал о чем-то подобном вчера вечером ... Я думаю, я просто не хочу, чтобы работа cron была очищена после моего планировщика lol ... Я думаю, что также может быть решение с совместным использованием папок между контейнерами, но мне не хватает знаний о докере и воздушном потоке. Спасибо за предложение! - person Ryan Stack; 12.04.2018
comment
В итоге я добавил это /usr/local/bin/docker-compose exec -T scheduler bash -c "rm -rf /usr/local/airflow/logs/scheduler/*" и запустил его со следующим выражением cron 0 0 * * * cd /path/to/script && /bin/bash ./cleanup.sh 1> /tmp/success.txt 2> /tmp/err.txt - person Ryan Stack; 12.04.2018

arrow_upward
4
arrow_downward

Этот ответ на «Удаление журналов задач воздушного потока» также подходит для вашего варианта использования в Airflow 1.10.

По сути, вам необходимо реализовать собственный обработчик журнала и настроить ведение журнала Airflow для использования этого обработчика вместо стандартного (см. UPDATING.md, не README и документы !!, в репозитории источников Airflow)

Одно предупреждение: из-за способа взаимодействия обработчиков по умолчанию для ведения журнала, многопроцессорности и Airflow безопаснее переопределять методы обработчика, чем расширять их, вызывая super () в производном классе обработчика. Поскольку обработчики Airflow по умолчанию не используют блокировки

person jnj16180340    schedule 28.03.2019

arrow_upward
-1
arrow_downward

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

На самом деле проблема была больше на уровне Docker, каждый из этих процессов отвечает за тонны журналов, которые по умолчанию Docker хранит в json файлах. Решением было изменить драйверы ведения журнала, чтобы что журналы больше не хранятся на экземпляре хоста Docker; но в моем случае отправлено напрямую в AWS CloudWatch Logs.

Мне просто нужно было добавить следующее к каждой службе в docker-compose.yml файле (https://github.com/puckel/docker-airflow):

    logging:
      driver: awslogs
      options:
        awslogs-group: myAWSLogsGroupID

Обратите внимание, что экземпляр EC2, на котором работает мое приложение Airflow, составленное из докеров, имеет роль AWS, которая позволяет ей создавать поток журнала и добавлять события журнала (действия CreateLogStream и PutLogEvents в сервисе AWS IAM).

Если вы запускаете его на машине за пределами экосистемы AWS, вам необходимо убедиться, что на нем есть доступ к AWS через учетные данные.

person jguillon    schedule 11.02.2021
comment
На самом деле вы можете легко вращать журналы докеров. Так что нет, это не вызвано докером, и ваше решение вообще не поможет решить проблему с журналом планировщика. - person qichao_he; 12.03.2021