Apache Airflow - funktionierte jetzt gut Logdatei ist kein lokaler Fehler und Ausnahmen tauchen auf

Question

So sieht es aus wie meine Installation von Apache Airflow auf einer Google Compute Engine Instanz zusammengebrochen. Alles hat gut funktioniert und vor zwei Tagen sind alle DAG Runs in einem laufenden Zustand. Ich verwende LocalExecutioner.

Als ich im Protokoll zu sehen versuchen, bekomme ich diesen Fehler:

* Log-Datei nicht lokal ist. * Abrufen hier: http://:8793/log/collector/aa_main_combined_collector/2017-12-15T09:00:00 *** Fehler beim Abrufen der Protokolldatei vom Worker.

Ich habe nirgends eine Einstellung berührt. Ich schaute durch alle Config-Dateien und ich scannte die Protokolle und ich sehe diesen Fehler

[2017-12-16 20: 08: 42,558] {jobs.py:355} DagFileProcessor0 ERROR - eine Ausnahme! Vermehrung ... Traceback (letzter Anruf zuletzt): Datei "/usr/local/lib/python3.4/dist-packages/airflow/jobs.py", Zeile 347, in Helfer pickle_dags) Datei "/ usr/local/lib/python3.4/dist-packages/airflow/utils/db.py ", Zeile 53, in Wrapper Ergebnis = func (* args, ** kwargs) Datei"/usr/local/lib/python3.4/dist-packages/airflow/jobs.py ", Zeile 1584, in Prozessdatei self._process_dags (dagbag, dags, ti_keys_to_schedule) Datei" /usr/local/lib/python3.4/dist-packages/airflow /jobs.py ", Zeile 1173, in _process_dags dag_run = self.create_dag_run (dag) Datei" /usr/local/lib/python3.4/dist-packages/airflow/utils/db.py ", Zeile 53, im Wrapper Ergebnis = func (* args, * * kwargs) Datei "/usr/local/lib/python3.4/dist-packages/airflow/jobs.py", Zeile 763, in create_dag_run last_scheduled_run = qry.scalar() Datei "/ usr/local/lib /python3.4/dist-packages/sqlalchemy/orm/query.py ", Zeile 2843, in Skalar ret = self.one() Datei" /usr/local/lib/python3.4/dist-packages/sqlalchemy /orm/query.py ", Zeile 2814, in einem ret = self.one_or_none() Datei" /usr/local/lib/python3.4/dist-packages/sqlalchemy/orm/query.py ", Zeile 2784 , in one_or_none ret = Liste (Selbst-) File "/usr/local/lib/python3.4/dist-packages/sqlalchemy/orm/query.py", Zeile 2855, in iter return self._execute_and_instances (Kontext) Datei "/usr/local/lib/python3.4/dist-packages/sqlalchemy/orm/query.py", Zeile 2878, in _execute_and_instances Ergebnis = conn.execute (querycontext.statement, self._params) Datei " /usr/local/lib/python3.4/dist-packages/sqlalchemy/engine/base.py ", Zeile 945, in Ausführung return meth (self, multiparams, params) Datei"/usr/local/lib/python3 .4/dist-packages/sqlalchemy/sql/elements.py ", Zeile 263, in _execute_on_connection zurück connection._execute_clauseelement (self, multiparams, params) Datei" /usr/local/lib/python3.4/dist-packages /sqlalchemy/engine/base.py ", Zeile 1053, in _execute_clauseelement compiled_sql, destillated_params Datei" /usr/local/lib/python3.4/dist-packages/sqlalchemy/engine/base.py ", Zeile 1189, in _execute_co ntext- Kontext) File "/usr/local/lib/python3.4/dist-packages/sqlalchemy/engine/base.py", Zeile 1405 in _handle_dbapi_exception util.reraise (* exc_info) Datei „/ usr/local/lib/python3.4/dist-packages/sqlalchemy/util/compat.py ", Zeile 187, in Reraise Wert erhöhen Datei" /usr/local/lib/python3.4/dist-packages/sqlalchemy/engine /Base.py ", Zeile 1182, in _execute_context Kontext) Datei" /usr/local/lib/python3.4/dist-packages/sqlalchemy/engine/default.py ", Zeile 470, in do_execute cursor.execute (Anweisung, Parameter) File "/usr/local/lib/python3.4/dist-packages/airflow/bin/cli.py", Zeile 69, in sigint_handler sys.exit (0) Systemexit: 0

Alle da draußen Gedanken?

Answer 1

löste ich dieses Problem aber dabei ich ein anderes Problem entdeckt.

Lange Rede kurzer Sinn, sobald ich manuell starten ed den Scheduler, hat alles wieder funktioniert. Es scheint, dass das Problem darin lag, dass der Scheduler nach einem Systemneustart nicht ordnungsgemäß neu gestartet wurde.

Ich habe Scheduler durch SystemD ausgeführt. Der Webserver .service funktioniert einwandfrei. Ich stelle jedoch fest, dass der Scheduler. Dienst ständig neu gestartet wird. Es scheint, dass dort ein Problem ist, das ich lösen muss. Dieser Teil davon ist für jetzt gelöst.

Answer 2

Blick auf die Log-URL, überprüfen, ob sie mit einem Datum mit Sonderzeichen endet +:

&execution_date=2018-02-23T08:00:00+00:00

Diese here wurde behoben.

Sie können die + für -, ersetzen oder alle Sonderzeichen ersetzen, in meinem Fall:

&execution_date=2018-02-23T08%3A00%3A00%2B00%3A00

Dies geschieht here.

Der FileTaskHandler kann das Protokoll nicht von der lokalen Festplatte laden und versuchen, von Worker zu laden.

Eine andere Sache, die diesen Fehler verursachen könnte, ist der Ausschluss des Luftstrom/Log-Ordners oder der Unterordner darin.