Dela via

Felsöka och diagnostisera fel i Azure Logic Apps

  • Artikel

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

Arbetsflödet för logikappen 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-portalen. 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. Utlösarhistoriken visar 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 logikappen Förbrukning 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-portalen med förbrukningslogikappens arbetsflödesutlösarhistorik.

  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 inkluderar de data som utlösaren förväntar sig och kräver för att starta arbetsflödet. Genom att granska dessa indata kan du avgöra om utlösarindata är korrekta och om villkoret har uppfyllts så att arbetsflödet kan fortsätta.

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

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

    Utlösarutdata inkluderar 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 skickas vidare till nästa steg i arbetsflödet.

    Ett felmeddelande anger till exempel att RSS-flödet inte hittades:

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

    Dricks

    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 den 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 läser 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-portalen med arbetsflödet för förbrukningslogikappen 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 misslyckad steginformation.

    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

För att hjälpa till med felsökning kan du lägga till diagnostiska steg 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 stegutdata.

  3. Klistra in url:en från Webhook-testaren 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 Tester för mer information.

Prestanda – vanliga frågor och svar

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

Schemaläggningskostnaderna finns när åtgärder körs, medan väntetiden mellan åtgärderna kan inträffa på grund av serverdelssystemets belastning. En varaktighet för arbetsflödeskörning innehåller 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 innehavare, så andra kunders arbetsbelastningar kan påverka arbetsflödets prestanda negativt.

  • För mer förutsägbara prestanda kan du överväga att skapa Standard-arbetsflöden som körs i Azure Logic Apps med en enda klientorganisation. Du får mer kontroll över 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 åtgärdas till 2 minuter. Om du använder HTTP-åtgärden och äger tjänsten som anropas av HTTP-åtgärden kan du ändra tjänsten 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 mönstret för avsökningsåtgärden.

Vanliga problem – Standardlogikappar

Otillgängliga artefakter i Azure Storage-kontot

Standardlogikappar lagrar alla artefakter i ett Azure-lagringskonto. Du kan få följande fel om dessa artefakter inte är tillgängliga. Lagringskontot i sig kanske till exempel inte är tillgängligt eller så finns lagringskontot bakom en brandvägg, men ingen privat slutpunkt har konfigurerats för de lagringstjänster som ska användas.

Azure-portalens 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 niska veze är den senaste.

    Viktigt!

    När du har känslig information, till exempel niska veze som innehåller användarnamn och lösenord, bör du använda det säkraste tillgängliga autentiseringsflödet. I standardarbetsflöden för logikappar stöds till exempel inte säkra datatyper, till exempel securestring och secureobject. Microsoft rekommenderar att du autentiserar åtkomst till Azure-resurser med en hanterad identitet när det är möjligt och tilldelar en roll som har minsta möjliga behörighet.

    Om den här funktionen inte är tillgänglig måste du skydda niska veze genom andra åtgärder, till exempel

Azure Key Vault, som du kan använda med appinställningar. Du kan sedan direkt referera till säkra strängar, till exempel niska veze och nycklar. På samma sätt som ARM-mallar, där du kan definiera miljövariabler vid distributionen, kan du definiera appinställningar i logikappens arbetsflödesdefinition. Du kan sedan samla in dynamiskt genererade infrastrukturvärden, till exempel anslutningsslutpunkter, lagringssträngar med mera. Mer information finns i Programtyper för Microsoft platforma za identitete.

  • 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 tjänsterna Blob, File, Table och Queue Storage matchar de förväntade IP-adresserna.

      Syntax: nslookup [StorageaccountHostName] [OptionalDNSServer]

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

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

      Bord: 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 matchas tjänsten med respektive privata IP-adresser för nätverksgränssnittsstyrenheten (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]

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

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

      Bord: 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. Ställ in logikappens WEBSITE_DNS_SERVER appinställning till DNS och bekräfta att DNS fungerar.

      2. Bekräfta 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 länk till det virtuella nätverket 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änsten eller privata slutpunkter.

Nästa steg