Řešení potíží s chybami pracovního postupu a jejich diagnostika v Azure Logic Apps

Platí pro: Azure Logic Apps (Consumption + Standard)

Pracovní postup aplikace logiky generuje informace, které vám můžou pomoct s diagnostikou a laděním problémů v aplikaci. Pracovní postup můžete diagnostikovat tak, že zkontrolujete vstupy, výstupy a další informace pro každý krok pracovního postupu pomocí Azure Portal. Nebo můžete do pracovního postupu přidat několik kroků pro ladění za běhu.

Kontrola historie triggerů

Každé spuštění pracovního postupu začíná triggerem, který se buď aktivuje podle plánu, nebo čeká na příchozí požadavek nebo událost. V historii triggeru jsou uvedeny všechny pokusy o aktivační události provedené vaším pracovním postupem a informace o vstupech a výstupech jednotlivých pokusů o trigger. Pokud se trigger neaktivuje, zkuste následující kroky.

Využití

1. Pokud chcete zkontrolovat stav triggeru v aplikaci logiky Consumption, zkontrolujte historii triggerů. Pokud chcete zobrazit další informace o pokusu o trigger, vyberte tuto událost triggeru, například:

   

2. Zkontrolujte vstupy triggeru a ověřte, že se zobrazují očekávaným způsobem. V podokně Historie v části Vstupy vyberte odkaz, který zobrazuje podokno Vstupy .

   Vstupy triggeru zahrnují data, která aktivační událost očekává a vyžaduje ke spuštění pracovního postupu. Kontrola těchto vstupů vám může pomoct určit, jestli jsou vstupy triggeru správné a jestli byly splněné podmínky, aby mohl pracovní postup pokračovat.

   

3. Zkontrolujte případné výstupy triggerů a ověřte, že se zobrazují podle očekávání. V podokně Historie v části Odkaz Výstupy vyberte odkaz, který zobrazuje podokno Výstupy .

   Výstupy triggeru zahrnují data, která aktivační událost předá do dalšího kroku v pracovním postupu. Kontrola těchto výstupů vám může pomoct určit, jestli se do dalšího kroku pracovního postupu předají správné nebo očekávané hodnoty.

   Například chybová zpráva uvádí, že informační kanál RSS nebyl nalezen:

   

   Tip

   Pokud najdete nějaký obsah, který neznáte, přečtěte si další informace o různých typech obsahu v Azure Logic Apps.

Standard

1. Pokud chcete zkontrolovat stav triggeru v aplikaci logiky Standard, zkontrolujte historii triggerů. Pokud chcete zobrazit další informace o pokusu o trigger, vyberte tuto událost triggeru, například:

   

2. Zkontrolujte vstupy triggeru a ověřte, že se zobrazují očekávaným způsobem. V podokně Historie v části Vstupy vyberte odkaz, který zobrazuje podokno Vstupy .

   Vstupy triggeru zahrnují data, která aktivační událost očekává a vyžaduje ke spuštění pracovního postupu. Kontrola těchto vstupů vám může pomoct určit, jestli jsou vstupy triggeru správné a jestli byly splněné podmínky, aby mohl pracovní postup pokračovat.

   

3. Zkontrolujte případné výstupy triggerů a ověřte, že se zobrazují podle očekávání. V podokně Historie v části Odkaz Výstupy vyberte odkaz, který zobrazuje podokno Výstupy .

   Výstupy triggeru zahrnují data, která aktivační událost předá do dalšího kroku v pracovním postupu. Kontrola těchto výstupů vám může pomoct určit, jestli se do dalšího kroku pracovního postupu předají správné nebo očekávané hodnoty.

   Například chybová zpráva uvádí, že informační kanál RSS nebyl nalezen:

   

   Tip

   Pokud najdete nějaký obsah, který neznáte, přečtěte si další informace o různých typech obsahu v Azure Logic Apps.

Kontrola historie spuštění pracovního postupu

Pokaždé, když se trigger aktivuje, Azure Logic Apps vytvoří instanci pracovního postupu a spustí tuto instanci. Pokud se spuštění nezdaří, vyzkoušejte následující kroky, abyste mohli zkontrolovat, co se během tohoto spuštění stalo. Můžete zkontrolovat stav, vstupy a výstupy pro každý krok v pracovním postupu.

Využití

1. Pokud chcete zkontrolovat stav spuštění pracovního postupu v aplikaci logiky Consumption, zkontrolujte historii spuštění. Pokud chcete zobrazit další informace o neúspěšném spuštění, včetně všech kroků v jejich stavu, vyberte neúspěšné spuštění.

   

2. Jakmile se zobrazí všechny kroky v běhu, vyberte jednotlivé kroky a rozbalte jejich obrazce.

   

3. Zkontrolujte vstupy, výstupy a případné chybové zprávy neúspěšného kroku.

   

   Například následující snímek obrazovky ukazuje výstupy neúspěšné akce RSS.

   

Standard

1. Pokud chcete zkontrolovat stav spuštění pracovního postupu v aplikaci logiky Standard, zkontrolujte historii spuštění. Pokud chcete zobrazit další informace o neúspěšném spuštění, včetně všech kroků v jejich stavu, vyberte neúspěšné spuštění.

   

2. Jakmile se zobrazí všechny kroky spuštění, vyberte jednotlivé kroky a zkontrolujte jejich podrobnosti.

   

3. Zkontrolujte vstupy, výstupy a případné chybové zprávy neúspěšného kroku.

   

   Například následující snímek obrazovky ukazuje výstupy neúspěšné akce RSS.

   

Ladění za běhu

Pokud chcete pomoct s laděním, můžete přidat diagnostické kroky do pracovního postupu aplikace logiky spolu s kontrolou triggeru a historie spuštění. Můžete například přidat kroky, které používají službu Webhook Tester , abyste mohli kontrolovat požadavky HTTP a určit jejich přesnou velikost, tvar a formát.

1. V prohlížeči přejděte na web Webhook Tester a zkopírujte vygenerovanou jedinečnou adresu URL.

2. V aplikaci logiky přidejte akci HTTP POST s obsahem textu, který chcete otestovat, například výraz nebo výstup jiného kroku.

3. Vložte adresu URL z webhooku Tester do akce HTTP POST.

4. Pokud chcete zkontrolovat, jak Azure Logic Apps generuje a vytváří požadavek, spusťte pracovní postup aplikace logiky. Další informace si pak můžete znovu projít na web Webhooku Tester.

Výkon – nejčastější dotazy

Proč je doba spuštění pracovního postupu delší než součet všech dob trvání akcí pracovního postupu?

Při spouštění akcí existuje režijní náklady na plánování, zatímco čekací doba mezi akcemi může nastat kvůli zatížení back-endového systému. Doba trvání spuštění pracovního postupu zahrnuje tyto časy plánování a čekací doby spolu se součtem všech dob trvání akcí.

Pracovní postup se obvykle dokončí během 10 sekund. Někdy ale dokončení může trvat mnohem déle. Jak zajistím, aby se pracovní postup vždy dokončil během 10 sekund?

• Na latenci neexistuje žádná záruka smlouvy SLA.

• Pracovní postupy Consumption běží ve víceklientské službě Azure Logic Apps, takže úlohy jiných zákazníků můžou negativně ovlivnit výkon pracovního postupu.

• Pro předvídatelnější výkon můžete zvážit vytvoření standardních pracovních postupů, které běží v Azure Logic Apps pro jednoho tenanta. Pokud chcete zvýšit výkon, budete mít větší kontrolu nad vertikálním navýšením nebo navýšením kapacity.

Platnost akce po 2 minutách vyprší. Jak můžu zvýšit hodnotu časového limitu?

Hodnota časového limitu akce se nedá změnit a je pevně nastavená na 2 minuty. Pokud používáte akci HTTP a vlastníte službu volanou akcí HTTP, můžete službu změnit tak, aby se zabránilo vypršení časového limitu 2 minuty, pomocí asynchronního vzoru. Další informace najdete v tématu Provádění dlouhotrvajících úloh se vzorem akcí dotazování.

Běžné problémy – Standardní aplikace logiky

Nepřístupné artefakty v účtu úložiště Azure

Standardní aplikace logiky ukládají všechny artefakty do účtu úložiště Azure. Pokud tyto artefakty nejsou přístupné, můžou se zobrazit následující chyby. Například samotný účet úložiště nemusí být přístupný nebo se nachází za bránou firewall, ale není nastavený žádný privátní koncový bod pro použití služeb úložiště.

Azure Portal umístění	Chyba
Podokno přehledu	- System.private.corelib:Přístup k cestě C:\home\site\wwwroot\hostj.son byl odepřen. - Azure.Storage.Blobs: Tento požadavek nemá oprávnění k provedení této operace.
Podokno Pracovní postupy	- Nelze se spojit s modulem runtime hostitele. Podrobnosti o chybě, kód: BadRequest, zpráva: Došlo k chybě (InternalServerError) z modulu runtime hostitele. - Nelze se spojit s modulem runtime hostitele. Podrobnosti o chybě, kód: BadRequest, zpráva: Došlo k chybě (ServiceUnavailable) z modulu runtime hostitele. - Nelze se spojit s modulem runtime hostitele. Podrobnosti o chybě, kód: BadRequest, zpráva: Došlo k chybě (BadGateway) z modulu runtime hostitele.
Během vytváření a provádění pracovního postupu	- Nepovedlo se uložit pracovní postup. - Chyba v návrháři: GetCallFailed. Neúspěšné operace načítání - Volání ajaxExtended se nezdařilo

Možnosti řešení potíží

Následující seznam obsahuje možné příčiny těchto chyb a kroky, které vám pomůžou s jejich řešením.

• V případě veřejného účtu úložiště zkontrolujte přístup k účtu úložiště následujícími způsoby:

  • Pomocí Průzkumník služby Azure Storage zkontrolujte připojení účtu úložiště.

  • V nastavení aplikace prostředku vaší aplikace logiky potvrďte připojovací řetězec účtu úložiště v nastavení aplikace AzureWebJobsStorage a WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Další informace najdete v tématu Nastavení hostitele a aplikace pro aplikace logiky v Azure Logic Apps pro jednoho tenanta.

  Pokud připojení selže, zkontrolujte, jestli je klíč sdíleného přístupového podpisu (SAS) v připojovacím řetězci nejnovější.

• V případě účtu úložiště, který je za bránou firewall, zkontrolujte přístup k účtu úložiště následujícími způsoby:

  • Pokud jsou pro účet úložiště povolená omezení brány firewall, zkontrolujte, jestli jsou pro služby Blob Storage, File, Table a Queue nastavené privátní koncové body .

  • Pomocí Průzkumník služby Azure Storage zkontrolujte připojení účtu úložiště.

  Pokud zjistíte problémy s připojením, pokračujte následujícími kroky:

  1. Ve stejné virtuální síti, která je integrovaná s vaší aplikací logiky, vytvořte virtuální počítač Azure, který můžete umístit do jiné podsítě.

  2. Z příkazového řádku spusťte příkaz nslookup a zkontrolujte, jestli se služby Úložiště objektů blob, file, table a queue přeloží na očekávané IP adresy.

     Syntaxe: nslookup [StorageaccountHostName] [OptionalDNSServer]

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

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

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

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

     • Pokud má služba úložiště koncový bod služby, přeloží se na veřejnou IP adresu.

     • Pokud má služba úložiště privátní koncový bod, přeloží se na příslušné privátní IP adresy adaptéru síťového rozhraní.

  3. Pokud předchozí dotazy dns úspěšně přeloží, spusťte příkazy psping nebo tcpping a zkontrolujte připojení k účtu úložiště přes port 443:

     Syntaxe: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

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

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

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

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

  4. Pokud je z vašeho virtuálního počítače Azure možné přeložit každou službu úložiště, vyhledejte DNS, který virtuální počítač používá k překladu.

     1. Nastavte WEBSITE_DNS_SERVER aplikace logiky na DNS a ověřte, že DNS funguje úspěšně.

     2. Ověřte, že je integrace virtuální sítě správně nastavená s odpovídající virtuální sítí a podsítí ve vaší aplikaci logiky úrovně Standard.

  5. Pokud pro služby privátního koncového bodu svého účtu úložiště používáte privátní zóny Azure DNS , zkontrolujte, že se vytvořilo propojení virtuální sítě s integrovanou virtuální sítí vaší aplikace logiky.

Další informace najdete v tématu Nasazení standardní aplikace logiky do účtu úložiště za bránou firewall pomocí služby nebo privátních koncových bodů.

Další kroky

• Monitorování aplikace logiky