Diagnostizieren und Beheben von Workflowfehlern in Azure Logic Apps

  • Artikel

Gilt für: Azure Logic Apps (Verbrauch + Standard)

Der Workflow Ihrer Logik-App generiert Informationen, die Ihnen beim Diagnostizieren und Debuggen von Problemen in Ihrer App helfen. Sie können Ihren Workflow diagnostizieren, indem Sie die Eingaben, Ausgaben und andere Informationen zu jedem Workflowschritt mithilfe des Azure-Portal überprüfen. Alternativ können Sie einem Workflow einige Schritte hinzufügen, um ein Laufzeit-Debugging durchzuführen.

Triggerverlauf überprüfen

Jede Workflowausführung beginnt mit einem Trigger, der entweder nach einem Zeitplan ausgelöst wird oder auf eine eingehende Anforderung oder ein Ereignis wartet. Der Triggerverlauf enthält sämtliche Auslöseversuche Ihres Workflows sowie Informationen zu den Eingaben und Ausgaben für jeden Versuch. Wenn der Trigger nicht ausgelöst wird, wenden Sie die folgenden Schritte an.

  1. Um den Status des Triggers in Ihrer Verbrauchslogik-App zu überprüfen, überprüfen Sie den Triggerverlauf. Um weitere Informationen zu dem Auslöseversuch anzuzeigen, wählen Sie das Triggerereignis aus, z. B.:

    Screenshot des Azure-Portals mit Triggerverlauf des Verbrauchs-Logik-App-Workflows.

  2. Überprüfen Sie die Eingaben des Triggers, um zu bestätigen, dass Sie erwartungsgemäß angezeigt werden. Wählen Sie im Bereich Verlauf unter Eingabelink den Link aus, der den Bereich Eingaben aufruft.

    Triggereingaben enthalten die Daten, die vom Trigger erwartet werden und die er zum Starten des Workflows benötigt. Wenn Sie diese Eingaben überprüfen, können Sie bestimmen, ob die Triggereingaben korrekt sind und ob die Bedingung erfüllt wurde, sodass der Workflow fortgesetzt werden kann.

    Screenshot der Triggereingaben des Verbrauchs-Logik-App-Workflows.

  3. Überprüfen Sie die Ausgaben des Triggers, falls vorhanden, um zu bestätigen, dass Sie erwartungsgemäß angezeigt werden. Wählen Sie im Bereich Verlauf unter Ausgabelink den Link aus, der den Bereich Ausgaben aufruft.

    Triggerausgaben enthalten die Daten, die der Trigger an den nächsten Schritt im Workflow übergibt. Das Überprüfen dieser Ausgaben kann Ihnen helfen zu bestimmen, ob die richtigen oder erwarteten Werte an den nächsten Schritt im Workflow übergeben wurden.

    Eine Fehlermeldung gibt beispielsweise an, dass der RSS-Feed nicht gefunden wurde:

    Screenshot der Triggerausgaben des Verbrauchs-Logik-App-Workflows.

    Tipp

    Sollten Sie Inhalte vorfinden, die Sie nicht verstehen, erfahren Sie hier mehr über unterschiedliche Inhaltstypen in Azure Logic Apps.

Überprüfen des Ausführungsverlaufs des Workflows

Bei jedem Auslösen des Triggers erstellt Azure Logic Apps eine Workflowinstanz und führt diese aus. Wenn eine Ausführung fehlschlägt, wenden Sie die folgenden Schritte an, um zu überprüfen, was geschehen ist. Sie können den Status, die Eingaben und Ausgaben für jeden Workflowschritt überprüfen.

  1. Um den Ausführungsstatus des Workflows in Ihrer Verbrauchslogik-App zu überprüfen, überprüfen Sie den Ausführungsverlauf. Weitere Informationen zu einer fehlgeschlagenen Ausführung, einschließlich aller Schritte in dieser Ausführung mit ihrem jeweiligen Status, erhalten Sie, indem Sie die fehlgeschlagene Ausführung auswählen.

    Screenshot des Azure-Portals mit Ausführungen des Verbrauchs-Logik-App-Workflows und einer ausgewählten fehlgeschlagenen Ausführung.

  2. Nachdem alle Schritte in der Ausführung angezeigt werden, wählen Sie jeden Schritt einzeln aus, um ihre Formen zu erweitern.

    Screenshot eines Verbrauchs-Logik-App-Workflows mit ausgewähltem fehlgeschlagenem Schritt.

  3. Überprüfen Sie die Eingaben, Ausgabe und alle Fehlermeldungen für den fehlgeschlagenen Schritt.

    Screenshot eines Verbrauchs-Logik-App-Workflows mit Details zum fehlgeschlagenen Schritt.

    Der folgende Screenshot zeigt beispielsweise die Ausgaben der fehlgeschlagenen RSS-Aktion.

    Screenshot eines Verbrauchs-Logik-App-Workflows mit Ausgaben des fehlgeschlagenen Schritts.

Durchführen von Laufzeit-Debugging

Zusätzlich zur Überprüfung des Triggers und des Ausführungsverlaufs können Sie einem Logik-App-Workflow Diagnoseschritte hinzufügen, die Sie beim Debuggen unterstützen. Sie können beispielsweise Schritte hinzufügen, die den Webhooktest-Dienst nutzen, um HTTP-Anforderungen untersuchen und ihre exakte Größe und Form sowie ihr Format ermitteln zu können.

  1. Wechseln Sie in einem Browser zur Webhooktest-Website, und kopieren Sie die generierte eindeutige URL.

  2. Fügen Sie in Ihrer Logik-App eine HTTP POST-Aktion mit dem Textinhalt hinzu, den Sie testen möchten (beispielsweise einen Ausdruck oder eine weitere Schrittausgabe).

  3. Fügen Sie Ihre URL von Webhook Tester in die HTTP POST-Aktion ein.

  4. Um zu überprüfen, wie Azure Logic Apps eine Anforderung generiert und formt, führen Sie den Logik-App-Workflow aus. Anschließend können Sie auf der Webhooktest-Website weitere Informationen erhalten.

Häufig gestellte Fragen (FAQ) zur Leistung

Warum ist die Dauer des Workflows länger als die Dauer aller Workflowaktionen insgesamt?

Bei der Ausführung von Aktionen entsteht ein Planungsaufwand, während zwischen den Aktionen Wartezeiten aufgrund der Back-End-Systemlast entstehen können. Die Dauer einer Workflowausführung umfasst diese Planungszeiten und Wartezeiten zusammen mit der Dauer aller Aktionen.

In der Regel wird mein Workflow innerhalb von 10 Sekunden abgeschlossen. Manchmal kann der Abschluss jedoch viel länger dauern. Wie kann ich sicherstellen, dass der Workflow immer innerhalb von 10 Sekunden beendet wird?

  • Es gibt keine SLA-Garantie für Latenz.

  • Die Verbrauchsworkflows werden in Azure Logic Apps für mehrere Mandanten ausgeführt, sodass sich die Arbeitslasten anderer Kunden negativ auf die Leistung Ihres Workflows auswirken können.

  • Damit Ihre Leistung vorhersehbarer ist, sollten Sie Standardworkflows erstellen, die in Azure Logic Apps für einen Mandanten ausgeführt werden. Sie haben mehr Kontrolle, um zur Leistungsverbesserung hoch- oder aufzuskalieren.

Bei meiner Aktion wird nach zwei Minuten ein Timeout wirksam. Wie kann ich den Timeoutwert erhöhen?

Der Aktionstimeoutwert kann nicht geändert werden und ist auf 2 Minuten festgelegt. Wenn Sie die HTTP-Aktion verwenden, und Sie besitzen den von der HTTP-Aktion aufgerufenen Dienst, können Sie Ihren Dienst ändern, um den 2-Minuten-Timeout mithilfe des asynchronen Musters zu vermeiden. Weitere Informationen hierzu finden Sie unter Ausführen zeitaufwändiger Aufgaben mit dem Abrufaktionsmuster.

Häufige Probleme bei Standardlogik-Apps

Nicht zugängliche Artefakte im Azure-Speicherkonto

Standardlogik-Apps speichern alle Artefakte in einem Azure-Speicherkonto. Wenn diese Artefakte nicht zugänglich sind, erhalten Sie eventuell die folgenden Fehler. Beispielsweise könnte das Speicherkonto selbst nicht zugänglich sein, oder das Speicherkonto befindet sich hinter einer Firewall, doch es wurde kein privater Endpunkt für die Speicherdienste eingerichtet.

Speicherort im Azure-Portal Fehler
Bereich „Übersicht“ - System.private.corelib:Zugriff auf den Pfad C:\home\site\wwwroot\hostj.son verweigert

- Azure.Storage.Blobs: This request is not authorized to perform this operation (Diese Anforderung ist zum Durchführen dieses Vorgangs nicht autorisiert.)
Bereich „Workflows“ - Die Hostlaufzeit kann nicht erreicht werden. Fehlerdetails, Code: „BadRequest“, Meldung: „Encountered an error (InternalServerError) from host runtime.“ (Fehler (InternalServerError) von der Hostlaufzeit)

- Die Hostlaufzeit kann nicht erreicht werden. Fehlerdetails, Code: „BadRequest“, Meldung: „Encountered an error (ServiceUnavailable) from host runtime.“ (Fehler (ServiceUnavailable) von der Hostlaufzeit)

- Die Hostlaufzeit kann nicht erreicht werden. Fehlerdetails, Code: „BadRequest“, Meldung: „Encountered an error (ServiceUnavailable) from host runtime.“ (Fehler (ServiceUnavailable) von der Hostlaufzeit)
Während des Erstellens und Ausführens von Workflows - Fehler beim Speichern des Workflows

- Fehler im Designer: GetCallFailed. Fehlgeschlagene Abrufvorgänge

- Fehler beim Aufruf von ajaxExtended

Optionen für die Problembehandlung

Die folgende Liste enthält mögliche Ursachen für diese Fehler sowie Schritte zur Problembehandlung.

  • Überprüfen Sie den Zugriff auf ein öffentliches Speicherkonto folgendermaßen:

    Wenn die Konnektivität einen Fehler aufweist, überprüfen Sie, ob der SAS-Schlüssel (Shared Access Signature) in der Verbindungszeichenfolge aktuell ist.

  • Überprüfen Sie den Zugriff auf ein Speicherkonto hinter einer Firewall folgendermaßen:

    • Wenn Firewalleinschränkungen im Speicherkonto aktiviert sind, überprüfen Sie, ob private Endpunkte für Blob-, File-, Table- und Queue-Speicherdienste eingerichtet sind.

    • Überprüfen Sie die Konnektivität des Speicherkontos mithilfe von Azure Storage-Explorer.

    Wenn Sie Konnektivitätsprobleme entdecken, fahren Sie mit den folgenden Schritten fort:

    1. Erstellen Sie im selben virtuellen Netzwerk, das mit Ihrer Logik-App integriert ist, einen virtuellen Azure-Computer, den Sie in ein anderes Subnetz einfügen können.

    2. Führen Sie in einer Eingabeaufforderung nslookup aus, um zu überprüfen, ob die Blob-, File-, Table- und Queue-Speicherdienste zu den erwarteten IP-Adressen aufgelöst werden.

      Syntax: nslookup [StorageaccountHostName] [OptionalDNSServer]

      Blob: nslookup {StorageaccountName}.blob.core.windows.net

      File: nslookup {StorageaccountName}.file.core.windows.net

      Table: nslookup {StorageaccountName}.table.core.windows.net

      Queue: nslookup {StorageaccountName}.queue.core.windows.net

      • Wenn der Speicherdienst über einen Dienstendpunkt verfügt, wird der Dienst zu einer öffentlichen IP-Adresse aufgelöst.

      • Wenn der Speicherdienst über einen privaten Endpunkt verfügt, wird der Dienst zu den jeweiligen privaten IP-Adressen des Netzwerkschnittstellencontrollers (NIC) aufgelöst.

    3. Wenn die vorherigen Domänennamenserver-Abfragen (DNS) erfolgreich aufgelöst werden, führen Sie die Befehle psping oder tcpping aus, um die Konnektivität zum Speicherkonto über Port 443 zu überprüfen:

      Syntax: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

      Blob: psping {StorageaccountName}.blob.core.windows.net:443

      File: psping {StorageaccountName}.file.core.windows.net:443

      Table: psping {StorageaccountName}.table.core.windows.net:443

      Queue: psping {StorageaccountName}.queue.core.windows.net:443

    4. Wenn jeder Speicherdienst von Ihrem virtuellen Azure-Computer aus aufgelöst werden kann, finden Sie das DNS, das vom virtuellen Computer zum Auflösen verwendet wird.

      1. Legen Sie die App-Einstellung WEBSITE_DNS_SERVER Ihrer Logik-App auf das DNS fest, und bestätigen Sie, dass das DNS funktioniert.

      2. Überprüfen Sie, ob die VNet-Integration in Ihrer Logik-App ordnungsgemäß mit dem entsprechenden virtuellen Netzwerk und Subnetz eingerichtet ist.

    5. Wenn Sie private Azure DNS-Zonen für die privaten Endpunktdienste Ihres Speicherkontos verwenden, überprüfen Sie, ob ein virtueller Netzwerklink mit dem integrierten virtuellen Netzwerk ihrer Logik-App erstellt wurde.

Weitere Informationen erhalten Sie unter Bereitstellen einer Standardlogik-App für ein Speicherkonto hinter einer Firewall mithilfe von Dienst- oder privaten Endpunkten.

Nächste Schritte