Запланированная группа доступности базы данных не работает.Как мне диагностировать проблему? - PullRequest
Новая
       3

Запланированная группа доступности базы данных не работает.Как мне диагностировать проблему?

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

Я использую Airflow 1.8.1. У меня есть группа обеспечения доступности баз данных, которую, как мне кажется, я планирую запускать каждые 5 минут, но она этого не делает: enter image description here

Игнорировать 2 успешных прогона DAG, они были запущены вручную.

Я смотрю журнал планировщика для этой группы DAG и вижу: 

[2019-04-26 22:03:35,601] {jobs.py:343} DagFileProcessor839 INFO - Started process (PID=5653) to work on /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:03:35,606] {jobs.py:1525} DagFileProcessor839 INFO - Processing file /usr/local/airflow/dags/retrieve_airflow_artifacts.py for tasks to queue
[2019-04-26 22:03:35,607] {models.py:168} DagFileProcessor839 INFO - Filling up the DagBag from /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:03:36,083] {jobs.py:1539} DagFileProcessor839 INFO - DAG(s) ['retrieve_airflow_artifacts'] retrieved from /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:03:36,112] {jobs.py:1172} DagFileProcessor839 INFO - Processing retrieve_airflow_artifacts
[2019-04-26 22:03:36,126] {jobs.py:566} DagFileProcessor839 INFO - Skipping SLA check for <DAG: retrieve_airflow_artifacts> because no tasks in DAG have SLAs
[2019-04-26 22:03:36,132] {models.py:323} DagFileProcessor839 INFO - Finding 'running' jobs without a recent heartbeat
[2019-04-26 22:03:36,132] {models.py:329} DagFileProcessor839 INFO - Failing jobs without heartbeat after 2019-04-26 21:58:36.132768
[2019-04-26 22:03:36,139] {jobs.py:351} DagFileProcessor839 INFO - Processing /usr/local/airflow/dags/retrieve_airflow_artifacts.py took 0.539 seconds
[2019-04-26 22:04:06,776] {jobs.py:343} DagFileProcessor845 INFO - Started process (PID=5678) to work on /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:04:06,780] {jobs.py:1525} DagFileProcessor845 INFO - Processing file /usr/local/airflow/dags/retrieve_airflow_artifacts.py for tasks to queue
[2019-04-26 22:04:06,780] {models.py:168} DagFileProcessor845 INFO - Filling up the DagBag from /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:04:07,258] {jobs.py:1539} DagFileProcessor845 INFO - DAG(s) ['retrieve_airflow_artifacts'] retrieved from /usr/local/airflow/dags/retrieve_airflow_artifacts.py
[2019-04-26 22:04:07,287] {jobs.py:1172} DagFileProcessor845 INFO - Processing retrieve_airflow_artifacts
[2019-04-26 22:04:07,301] {jobs.py:566} DagFileProcessor845 INFO - Skipping SLA check for <DAG: retrieve_airflow_artifacts> because no tasks in DAG have SLAs
[2019-04-26 22:04:07,307] {models.py:323} DagFileProcessor845 INFO - Finding 'running' jobs without a recent heartbeat
[2019-04-26 22:04:07,307] {models.py:329} DagFileProcessor845 INFO - Failing jobs without heartbeat after 2019-04-26 21:59:07.307607
[2019-04-26 22:04:07,314] {jobs.py:351} DagFileProcessor845 INFO - Processing /usr/local/airflow/dags/retrieve_airflow_artifacts.py took 0.538 seconds

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

Вот как определяется расписание моей группы доступности базы данных: 

args = {
    'owner': 'airflow',
    'start_date': (datetime.datetime.now() - datetime.timedelta(minutes=5))
}

dag = DAG(
    dag_id='retrieve_airflow_artifacts', default_args=args,
    schedule_interval="0,5,10,15,20,25,30,35,40,45,50,55 * * * *")

Может ли кто-нибудь помочь мне выяснить, почему мой DAG не работает, потому что я выглядел высоко и низко и не могу понять это.

1 Ответ

2 голосов
/ 28 апреля 2019

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

Измените ваши аргументы так, чтобы они имели статический старт, и не допускайте его запуска в течение прошедших интервалов: 

args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'start_date': datetime(2019, 4, 27) #year month day
}

Кроме того, просто для облегчения чтения измените ваши аргументы DAG на (те же функции): 

dag = DAG(
    dag_id='retrieve_airflow_artifacts', 
    default_args=args,
    schedule_interval="*/5 * * * *"
)

Это должно позволить планировщику забрать его!

Обычно рекомендуется не устанавливать динамическую дату начала.

Взято из Часто задаваемые вопросы о воздушном потоке:

Мы не рекомендуем использовать динамические значения в качестве start_date, особенно datetime.now (), так как это может привести к путанице.Задача запускается после закрытия периода, и в теории @hourly DAG никогда не дойдет до часа спустя, так как now () продвигается.

Еще один вопрос SO по этому вопросу: почемудинамические даты начала вызывают проблемы

...