Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Problembehandlung: CloudWatch Protokolle und CloudTrail Fehler Die Themen auf dieser Seite enthalten Lösungen für CloudWatch Amazon-Logs und AWS CloudTrail Fehler, die in einer Amazon Managed Workflows for Apache Airflow Airflow-Umgebung auftreten können. **Contents** + [Logs (Protokolle)](#troubleshooting-view-logs) + [Ich kann meine Task-Logs nicht finden, oder ich habe einen `Reading remote log from Cloudwatch log_group` Fehler erhalten](#t-task-logs) + [Aufgaben schlagen fehl, wenn keine Protokolle vorhanden sind](#t-task-failing-no-logs) + [Ich erhalte eine Fehlermeldung in `ResourceAlreadyExistsException` CloudTrail](#t-cloudtrail) + [Ich erhalte eine `Invalid request` Fehlermeldung in CloudTrail](#t-cloudtrail-bucket) + [Ich erhalte `Cannot locate a 64-bit Oracle Client library: "libclntsh.so: cannot open shared object file: No such file or directory` Apache Airflow Airflow-Logs](#t-plugins-logs) + [Ich erhalte in meinen Scheduler-Protokollen die Meldung psycopg2, dass der Server die Verbindung unerwartet geschlossen hat](#scheduler-postgres-library) + [Ich komme `Executor reports task instance %s finished (%s) although the task says its %s` in meine DAG-Verarbeitungsprotokolle](#long-running-tasks) + [Ich komme `Could not read remote logs from log_group: airflow-*{*environmentName}-Task log_stream:* {*DAG_ID}/*{*TASK_ID}/*{*time}/*{*n}.log.` in meine Task-Logs](#t-task-fail-permission) ## Logs (Protokolle) Im folgenden Thema werden die Fehler beschrieben, die beim Zugriff auf Apache Airflow Airflow-Protokolle auftreten können. ### Ich kann meine Task-Logs nicht finden, oder ich habe einen `Reading remote log from Cloudwatch log_group` Fehler erhalten Amazon MWAA hat Apache Airflow so konfiguriert, dass Protokolle direkt von und in Amazon Logs gelesen und geschrieben werden. CloudWatch Wenn ein Mitarbeiter eine Aufgabe nicht starten oder keine Protokolle schreiben kann, verweisen Sie auf den Fehler: ``` *** Reading remote log from Cloudwatch log_group: airflow-{{environmentName}}-Task log_stream: {{DAG_ID}}/{{TASK_ID}}/{{timestamp}}/{{n}}.log.Could not read remote logs from log_group: airflow-{{environmentName}}-Task log_stream: {{DAG_ID}}/{{TASK_ID}}/{{time}}/{{n}}.log. ``` + Wir empfehlen die folgenden Schritte: 1. Stellen Sie sicher, dass Sie Task-Logs auf der `INFO` Ebene für Ihre Umgebung aktiviert haben. Weitere Informationen finden Sie unter [Zugreifen auf Airflow-Protokolle in Amazon CloudWatch](monitoring-airflow.md). 1. Stellen Sie sicher, dass die [Umgebungsausführungsrolle](mwaa-create-role.md) über die richtigen Berechtigungsrichtlinien verfügt. 1. Stellen Sie sicher, dass Ihr Operator oder Ihre Aufgabe ordnungsgemäß funktioniert, über ausreichende Ressourcen zum Parsen der DAG verfügt und über die entsprechenden Python-Bibliotheken zum Laden verfügt. Um zu überprüfen, ob Sie über die richtigen Abhängigkeiten verfügen, versuchen Sie, Importe zu entfernen, bis Sie den gefunden haben, der das Problem verursacht. Wir empfehlen, Ihre Python-Abhängigkeiten mit zu testen [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images). ### Aufgaben schlagen fehl, wenn keine Protokolle vorhanden sind Wenn Aufgaben in einem Workflow fehlschlagen und Sie keine Protokolle für die fehlgeschlagenen Aufgaben finden können, überprüfen Sie, ob Sie den `queue` Parameter in Ihren Standardargumenten festlegen, wie im Folgenden aufgeführt. ``` from airflow import DAG from airflow.operators.bash_operator import BashOperator from airflow.utils.dates import days_ago # Setting queue argument to default. default_args = { "start_date": days_ago(1), "queue": "default" } with DAG(dag_id="any_command_dag", schedule_interval=None, catchup=False, default_args=default_args) as dag: cli_command = BashOperator( task_id="bash_command", bash_command="{{ dag_run.conf['command'] }}" ) ``` Um das Problem zu beheben, entfernen Sie es `queue` aus Ihrem Code und rufen Sie die DAG erneut auf. ### Ich erhalte eine Fehlermeldung in `ResourceAlreadyExistsException` CloudTrail ``` "errorCode": "ResourceAlreadyExistsException", "errorMessage": "The specified log stream already exists", "requestParameters": { "logGroupName": "airflow-MyAirflowEnvironment-DAGProcessing", "logStreamName": "scheduler_cross-account-eks.py.log" } ``` Bestimmte Python-Anforderungen, z. B. ein `apache-airflow-backport-providers-amazon` Rollback der `watchtower` Bibliothek, mit der Amazon MWAA kommuniziert, CloudWatch auf eine ältere Version. Wir empfehlen die folgenden Schritte: + Fügen Sie die folgende Bibliothek zu Ihrer `requirements.txt` ``` watchtower==1.0.6 ``` ### Ich erhalte eine `Invalid request` Fehlermeldung in CloudTrail ``` Invalid request provided: Provided role does not have sufficient permissions for s3 location airflow-xxx-xxx/dags ``` Wenn Sie eine Amazon MWAA-Umgebung und einen Amazon S3 S3-Bucket mit derselben CloudFormation Vorlage erstellen, müssen Sie Ihrer CloudFormation Vorlage einen `DependsOn` Abschnitt hinzufügen. Die beiden Ressourcen (*MWAA-Umgebung und MWAA-Ausführungsrichtlinie**) haben eine Abhängigkeit* von. CloudFormation Wir empfehlen die folgenden Schritte: + Fügen Sie Ihrer Vorlage die folgende **DependsOn** Anweisung hinzu. CloudFormation ``` ... MaxWorkers: 5 NetworkConfiguration: SecurityGroupIds: - !GetAtt SecurityGroup.GroupId SubnetIds: !Ref subnetIds WebserverAccessMode: PUBLIC_ONLY DependsOn: MwaaExecutionPolicy MwaaExecutionPolicy: Type: AWS::IAM::ManagedPolicy Properties: Roles: - !Ref MwaaExecutionRole PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: airflow:PublishMetrics Resource: ... ``` Ein Beispiel finden Sie unter[Schnellstartanleitung für Amazon Managed Workflows für Apache Airflow](quick-start.md). ### Ich erhalte `Cannot locate a 64-bit Oracle Client library: "libclntsh.so: cannot open shared object file: No such file or directory` Apache Airflow Airflow-Logs + Wir empfehlen die folgenden Schritte: 1. Wenn Sie Apache Airflow v2 verwenden, fügen Sie es `core.lazy_load_plugins : False` als Apache Airflow Airflow-Konfigurationsoption hinzu. Weitere Informationen finden Sie unter [Verwenden von Konfigurationsoptionen zum Laden von Plugins in 2.](configuring-env-variables.md#configuring-2.0-airflow-override) ### Ich erhalte in meinen Scheduler-Protokollen die Meldung psycopg2, dass der Server die Verbindung unerwartet geschlossen hat Wenn Sie eine Fehlermeldung ähnlich der folgenden erhalten, sind Ihrem Apache Airflow Scheduler möglicherweise die Ressourcen ausgegangen. ``` 2021-06-14T10:20:24.581-05:00 sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) server closed the connection unexpectedly 2021-06-14T10:20:24.633-05:00 This probably means the server terminated abnormally 2021-06-14T10:20:24.686-05:00 before or while processing the request. ``` Wir empfehlen die folgenden Schritte: + Erwägen Sie ein Upgrade auf Apache Airflow v2.0.2, mit dem Sie bis zu 5 Scheduler angeben können. ### Ich komme `Executor reports task instance %s finished (%s) although the task says its %s` in meine DAG-Verarbeitungsprotokolle Wenn Sie eine Fehlermeldung ähnlich der folgenden erhalten, haben Ihre lang andauernden Aufgaben möglicherweise das Zeitlimit für Aufgaben auf Amazon MWAA erreicht. Amazon MWAA hat ein Limit von 12 Stunden für jede einzelne Airflow-Aufgabe, um zu verhindern, dass Aufgaben in der Warteschlange hängen bleiben und Aktivitäten wie Autoscaling blockiert werden. ``` Executor reports task instance %s finished (%s) although the task says its %s. (Info: %s) Was the task killed externally ``` Wir empfehlen die folgenden Schritte: + Erwägen Sie, die Aufgabe in mehrere, kürzer laufende Aufgaben aufzuteilen. Airflow verwendet in der Regel ein Modell, bei dem die Bediener asynchron arbeiten. Es ruft Aktivitäten auf externen Systemen auf und Apache Airflow Sensors fragt ab, ob der Vorgang abgeschlossen ist. Wenn ein Sensor ausfällt, kann er sicher erneut versucht werden, ohne dass die Funktionalität des Bedieners beeinträchtigt wird. ### Ich komme `Could not read remote logs from log_group: airflow-*{*environmentName}-Task log_stream:* {*DAG_ID}/*{*TASK_ID}/*{*time}/*{*n}.log.` in meine Task-Logs Wenn Sie eine Fehlermeldung ähnlich der folgenden erhalten, enthält die Ausführungsrolle für Ihre Umgebung möglicherweise keine Berechtigungsrichtlinie zum Erstellen von Protokollstreams für Aufgabenprotokolle. ``` Could not read remote logs from log_group: airflow-*{*environmentName}-Task log_stream:* {*DAG_ID}/*{*TASK_ID}/*{*time}/*{*n}.log. ``` Wir empfehlen die folgenden Schritte: + Ändern Sie die Ausführungsrolle für Ihre Umgebung mithilfe einer der Beispielrichtlinien unter[Amazon MWAA-Ausführungsrolle](mwaa-create-role.md). Möglicherweise haben Sie in Ihrer `requirements.txt` Datei auch ein Provider-Paket angegeben, das mit Ihrer Apache Airflow Airflow-Version nicht kompatibel ist. Wenn Sie beispielsweise Apache Airflow v2.0.2 verwenden, haben Sie möglicherweise ein Paket angegeben, z. B. das [apache-airflow-providers-databricks](https://airflow.apache.org/docs/apache-airflow-providers-databricks/stable/index.html)Paket, das nur mit Airflow 2.1\+ kompatibel ist. Wir empfehlen die folgenden Schritte: 1. Wenn Sie Apache Airflow v2.0.2 verwenden, ändern Sie die `requirements.txt` Datei und fügen Sie sie hinzu. `apache-airflow[databricks]` Dadurch wird die richtige Version des Databricks-Pakets installiert, die mit Apache Airflow v2.0.2 kompatibel ist. 1. Testen Sie Ihre DAGs benutzerdefinierten Plugins und Python-Abhängigkeiten lokal mit [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.