Freigeben über


Diagnostizieren und Beheben von Workflowfehlern in Azure Logic Apps

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 des Workflows. 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 ggf. die Ausgaben des Triggers, um zu bestätigen, dass sie wie erwartet 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 Workflows der Verbrauchslogik-App.

    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 des Workflows. 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 mit dem Workflow der Verbrauchslogik-App mit ausgewähltem Fehlerschritt.

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

    Screenshot des Workflows der Verbrauchslogik-App mit fehlgeschlagenen Schrittdetails.

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

    Screenshot des Workflows der Verbrauchslogik-App mit fehlgeschlagenen Ausgabeschritten.

Durchführen von Laufzeit-Debugging

Um beim Debuggen zu helfen, können Sie einem Logik-App-Workflow Diagnoseschritte hinzufügen und den Trigger- und Ausführungsverlauf überprüfen. 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, z. B. einen Ausdruck oder eine andere Schrittausgabe.

  3. Fügen Sie Ihre URL aus dem 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

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?

  • Für Latenz ist keine SLA-Garantie (Service Level Agreement) vorhanden.

  • Die Verbrauchsworkflows werden in mehrinstanzenfähige Azure Logic Apps 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 finden Sie unter Ausführen länger laufender Aufgaben mit dem Polling-Aktionsmuster.

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
Übersichtsbereich - System.private.corelib:Zugriff auf den Pfad 'C:\home\site\wwwroot\host.jsaktiviert' wird 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.

    Wichtig

    Wenn Sie über vertrauliche Informationen verfügen (z. B. Verbindungszeichenfolgen, die Benutzernamen und Kennwörter enthalten), stellen Sie sicher, dass Sie den sichersten Authentifizierungsflow verwenden. Beispielsweise werden in Logik-App-Standardworkflows sichere Datentypen wie securestring und secureobject nicht unterstützt. Microsoft empfiehlt, den Zugriff auf Azure-Ressourcen mit einer verwalteten Identität nach Möglichkeit zu authentifizieren und eine Rolle zuzuweisen, die über die geringsten Berechtigungen verfügt.

    Wenn diese Funktion nicht verfügbar ist, stellen Sie sicher, dass Verbindungszeichenfolgen über andere Maßnahmen wie Azure Key Vault gesichert werden, die Sie mit App-Einstellungen verwenden können. Sie können dann direkt auf sichere Zeichenfolgen verweisen (z. B. Verbindungszeichenfolgen und Schlüssel). Ähnlich wie bei ARM-Vorlagen, bei denen Sie Umgebungsvariablen zum Bereitstellungszeitpunkt definieren können, können Sie App-Einstellungen in der Workflowdefinition für Ihre Logik-App definieren. Anschließend können Sie dynamisch generierte Infrastrukturwerte erfassen (z. B. Verbindungsendpunkte oder Speicherzeichenfolgen). Weitere Informationen finden Sie unter Anwendungstypen für die Microsoft Identity Platform.

  • Ü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 an einer Eingabeaufforderung nslookup aus, um zu überprüfen, ob die Blob-, Datei-, Tabellen- und Warteschlangenspeicherdienste in die erwarteten IP-Adressen aufgelöst werden.

      Syntax: nslookup [StorageaccountHostName] [OptionalDNSServer]

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

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

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

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

      • Wenn der Speicherdienst über einen Dienstendpunkt verfügt, wird der Dienst auf eine öffentliche 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 zuvor durchgeführten DNS-Abfragen (Domain Name Server) erfolgreich aufgelöst werden, führen Sie die psping oder tcpping Befehle aus, um die Verbindung mit dem Speicherkonto über Port 443 zu testen.

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

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

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

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

      Warteschlange: 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. Vergewissern Sie sich, dass die Integration des virtuellen Netzwerks ordnungsgemäß mit dem entsprechenden virtuellen Netzwerk und Subnetz in Ihrer Standardlogik-App eingerichtet ist.

    5. Wenn Sie private Azure DNS-Zonen für die privaten Endpunktdienste Ihres Speicherkontos verwenden, überprüfen Sie, ob eine virtuelle Netzwerkverbindung 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.