Felsöka och diagnostisera fel med arbetsflöden i Azure Logic Apps

  • Artikel

Gäller för: Azure Logic Apps (Consumption + Standard)

Logikappens arbetsflöde genererar information som kan hjälpa dig att diagnostisera och felsöka problem i din app. Du kan diagnostisera arbetsflödet genom att granska indata, utdata och annan information för varje steg i arbetsflödet med hjälp av Azure Portal. Eller så kan du lägga till några steg i ett arbetsflöde för körningsfelsökning.

Kontrollera utlösarhistorik

Varje arbetsflödeskörning börjar med en utlösare som antingen utlöses enligt ett schema eller väntar på en inkommande begäran eller händelse. I utlösarhistoriken visas alla utlösarförsök som arbetsflödet har gjort och information om indata och utdata för varje utlösarförsök. Om utlösaren inte utlöses kan du prova följande steg.

  1. Om du vill kontrollera utlösarens status i din förbrukningslogikapp granskar du utlösarhistoriken. Om du vill visa mer information om utlösarförsöket väljer du den utlösarhändelsen, till exempel:

    Skärmbild som visar Azure Portal med utlösarhistorik för förbrukningslogikappens arbetsflöde.

  2. Kontrollera utlösarens indata för att bekräfta att de visas som förväntat. I fönstret Historik går du till länken Indata och väljer länken, som visar fönstret Indata .

    Utlösarindata innehåller de data som utlösaren förväntar sig och som kräver att arbetsflödet startas. Genom att granska dessa indata kan du avgöra om utlösarindata är korrekta och om villkoret uppfylldes så att arbetsflödet kan fortsätta.

    Skärmbild som visar indata för förbrukningslogikappens arbetsflödesutlösare.

  3. Kontrollera eventuella utdata för utlösare för att bekräfta att de visas som förväntat. I fönstret Historik går du till länken Utdata och väljer länken, som visar fönstret Utdata .

    Utlösarutdata innehåller de data som utlösaren skickar till nästa steg i arbetsflödet. Genom att granska dessa utdata kan du avgöra om rätt eller förväntade värden har förts vidare till nästa steg i arbetsflödet.

    Ett felmeddelande anger till exempel att RSS-feeden inte hittades:

    Skärmbild som visar utdata för utdata från förbrukningslogikappens arbetsflöde.

    Tips

    Om du hittar innehåll som du inte känner igen kan du läsa mer om olika innehållstyper i Azure Logic Apps.

Kontrollera arbetsflödets körningshistorik

Varje gång utlösaren utlöses skapar Azure Logic Apps en arbetsflödesinstans och kör den instansen. Om en körning misslyckas kan du prova följande steg så att du kan granska vad som hände under körningen. Du kan granska status, indata och utdata för varje steg i arbetsflödet.

  1. Om du vill kontrollera arbetsflödets körningsstatus i logikappen Förbrukning granskar du körningshistoriken. Om du vill visa mer information om en misslyckad körning, inklusive alla steg i körningen i deras status, väljer du den misslyckade körningen.

    Skärmbild som visar Azure Portal med förbrukningslogikappens arbetsflödeskörningar och en misslyckad körning vald.

  2. När alla steg i körningen visas väljer du varje steg för att expandera formerna.

    Skärmbild som visar arbetsflödet för förbrukningslogikappen med det misslyckade steget valt.

  3. Granska indata, utdata och eventuella felmeddelanden för det misslyckade steget.

    Skärmbild som visar arbetsflödet för förbrukningslogikappen med felstegsinformation.

    Följande skärmbild visar till exempel utdata från den misslyckade RSS-åtgärden.

    Skärmbild som visar arbetsflödet för förbrukningslogikappen med misslyckade stegutdata.

Utför felsökning av körningen

Om du vill ha hjälp med felsökning kan du lägga till diagnostiksteg i ett logikapparbetsflöde, tillsammans med att granska utlösaren och körningshistoriken. Du kan till exempel lägga till steg som använder tjänsten Webhook Tester , så att du kan granska HTTP-begäranden och fastställa deras exakta storlek, form och format.

  1. I en webbläsare går du till webbplatsen Webhook Tester och kopierar den genererade unika URL:en.

  2. I logikappen lägger du till en HTTP POST-åtgärd med brödtextinnehållet som du vill testa, till exempel ett uttryck eller ett annat steg.

  3. Klistra in url:en från Webhook Tester i HTTP POST-åtgärden.

  4. Om du vill granska hur Azure Logic Apps genererar och bildar en begäran kör du logikappens arbetsflöde. Du kan sedan gå tillbaka till webbplatsen webhook-testare för mer information.

Prestanda – vanliga frågor och svar

Varför är varaktigheten för arbetsflödet längre än summan av alla varaktigheter för arbetsflödesåtgärden?

Det finns schemaläggningskostnader när åtgärder körs, medan väntetiden mellan åtgärder kan inträffa på grund av serverdelssystemets belastning. En varaktighet för arbetsflödeskörning omfattar dessa schemaläggningstider och väntetider tillsammans med summan av alla åtgärdsvaraktigheterna.

Vanligtvis slutförs mitt arbetsflöde inom 10 sekunder. Men ibland kan slutförandet ta mycket längre tid. Hur ser jag till att arbetsflödet alltid är klart inom 10 sekunder?

  • Det finns ingen SLA-garanti för svarstid.

  • Förbrukningsarbetsflöden körs på Azure Logic Apps för flera klientorganisationer, så andra kunders arbetsbelastningar kan påverka arbetsflödets prestanda negativt.

  • För mer förutsägbara prestanda kan du överväga att skapa standardarbetsflöden, som körs i Azure Logic Apps med en enda klientorganisation. Du får mer kontroll för att skala upp eller ut för att förbättra prestandan.

Min åtgärd överskrider tidsgränsen efter 2 minuter. Hur ökar jag tidsgränsvärdet?

Tidsgränsvärdet för åtgärden kan inte ändras och är fast vid 2 minuter. Om du använder HTTP-åtgärden och äger tjänsten som anropas av HTTP-åtgärden kan du ändra din tjänst för att undvika tidsgränsen på 2 minuter med hjälp av det asynkrona mönstret. Mer information finns i Utföra långvariga uppgifter med avsökningsåtgärdsmönstret.

Vanliga problem – standardlogikappar

Otillgängliga artefakter i Azure Storage-kontot

Standardlogikappar lagrar alla artefakter i ett Azure Storage-konto. Du kan få följande fel om dessa artefakter inte är tillgängliga. Till exempel kanske själva lagringskontot inte är tillgängligt, eller så finns lagringskontot bakom en brandvägg men ingen privat slutpunkt har konfigurerats för lagringstjänsterna att använda.

Azure Portal plats Fel
Översiktsfönster - System.private.corelib:Åtkomst till sökvägen 'C:\home\site\wwwroot\hostj.son nekas

- Azure.Storage.Blobs: Den här begäran har inte behörighet att utföra den här åtgärden
Fönstret Arbetsflöden - Det går inte att nå värdkörningen. Felinformation, Kod: "BadRequest", Meddelande: "Påträffade ett fel (InternalServerError) från värdkörningen."

- Det går inte att nå värdkörningen. Felinformation, Kod: "BadRequest", Meddelande: "Påträffade ett fel (ServiceUnavailable) från värdkörningen."

- Det går inte att nå värdkörningen. Felinformation, Kod: "BadRequest", Meddelande: "Påträffade ett fel (BadGateway) från värdkörningen."
När arbetsflödet skapas och körs - Det gick inte att spara arbetsflödet

- Fel i designern: GetCallFailed. Det gick inte att hämta åtgärder

- ajaxExtended-anropet misslyckades

Felsökningsalternativ

Följande lista innehåller möjliga orsaker till dessa fel och steg som hjälper dig att felsöka.

  • För ett offentligt lagringskonto kontrollerar du åtkomsten till lagringskontot på följande sätt:

    Om anslutningen misslyckas kontrollerar du om SAS-nyckeln (Signatur för delad åtkomst) i anslutningssträngen är den senaste.

  • För ett lagringskonto som finns bakom en brandvägg kontrollerar du åtkomsten till lagringskontot på följande sätt:

    Om du hittar anslutningsproblem fortsätter du med följande steg:

    1. I samma virtuella nätverk som är integrerat med logikappen skapar du en virtuell Azure-dator som du kan placera i ett annat undernät.

    2. Från en kommandotolk kör du nslookup för att kontrollera att blob-, fil-, tabell- och kölagringstjänsterna matchar de förväntade IP-adresserna.

      Syntax: nslookup [StorageaccountHostName] [OptionalDNSServer]

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

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

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

      Kö: nslookup {StorageaccountName}.queue.core.windows.net

      • Om lagringstjänsten har en tjänstslutpunkt matchar tjänsten en offentlig IP-adress.

      • Om lagringstjänsten har en privat slutpunkt matchar tjänsten de privata IP-adresserna för respektive nätverksgränssnittskontrollant (NIC).

    3. Om de tidigare DNS-frågorna (domain name server) löser problemet kör du psping - eller tcpping-kommandona för att kontrollera anslutningen till lagringskontot via port 443:

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

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

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

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

      Kö: psping {StorageaccountName}.queue.core.windows.net:443

    4. Om varje lagringstjänst kan matchas från din virtuella Azure-dator letar du reda på den DNS som används av den virtuella datorn för lösning.

      1. Ange logikappens WEBSITE_DNS_SERVER appinställning till DNS och bekräfta att DNS fungerar korrekt.

      2. Kontrollera att VNet-integreringen är korrekt konfigurerad med lämpligt virtuellt nätverk och undernät i standardlogikappen.

    5. Om du använder privata Azure DNS-zoner för lagringskontots privata slutpunktstjänster kontrollerar du att en virtuell nätverkslänk har skapats till logikappens integrerade virtuella nätverk.

Mer information finns i Distribuera standardlogikapp till ett lagringskonto bakom en brandvägg med hjälp av tjänst- eller privata slutpunkter.

Nästa steg