Ř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. Svůj pracovní postup můžete diagnostikovat kontrolou vstupů, výstupů a dalších informací pro každý krok pracovního postupu pomocí webu Azure Portal. Nebo můžete do pracovního postupu přidat několik kroků pro ladění za běhu.

Kontrola historie aktivačních událostí

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. Historie aktivačních událostí obsahuje všechny pokusy o aktivační událost, které váš pracovní postup provedl, a informace o vstupech a výstupech pro každý pokus o trigger. Pokud se trigger neaktivuje, vyzkoušejte 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í podle očekávání. V podokně Historie vyberte v části Odkaz Vstupy odkaz, který zobrazuje podokno Vstupy.

   Vstupy triggeru zahrnují data, která aktivační událost očekává a vyžaduje 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 byla splněna podmínka, aby pracovní postup mohl pokračovat.

   

3. Zkontrolujte výstupy triggerů( pokud existuje) a ověřte, že se zobrazují očekávaným způsobem. V podokně Historie v části Výstupy vyberte odkaz, který zobrazuje podokno Výstupy.

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

   Například chybová zpráva uvádí, že se informační kanál RSS nenašel:

   

   Tip

   Pokud najdete nějaký obsah, který nerozpozná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 ve standardní aplikaci logiky, 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í podle očekávání. V podokně Historie vyberte v části Odkaz Vstupy odkaz, který zobrazuje podokno Vstupy.

   Vstupy triggeru zahrnují data, která aktivační událost očekává a vyžaduje 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 byla splněna podmínka, aby pracovní postup mohl pokračovat.

   

3. Zkontrolujte výstupy triggerů( pokud existuje) a ověřte, že se zobrazují očekávaným způsobem. V podokně Historie v části Výstupy vyberte odkaz, který zobrazuje podokno Výstupy.

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

   Například chybová zpráva uvádí, že se informační kanál RSS nenašel:

   

   Tip

   Pokud najdete nějaký obsah, který nerozpozná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í ji. Pokud se spuštění nezdaří, vyzkoušejte následující kroky, abyste mohli zkontrolovat, co se během tohoto spuštění stalo. Stav, vstupy a výstupy můžete zkontrolovat pro každý krok pracovního 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 daném spuštění ve 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 všechny chybové zprávy pro neúspěšný krok.

   

   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 ve standardní aplikaci logiky, zkontrolujte historii spuštění. Pokud chcete zobrazit další informace o neúspěšném spuštění, včetně všech kroků v daném spuštění ve stavu, vyberte neúspěšné spuštění.

   

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

   

3. Zkontrolujte vstupy, výstupy a všechny chybové zprávy pro neúspěšný krok.

   

   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 do pracovního postupu aplikace logiky přidat diagnostické kroky spolu s kontrolou historie triggeru a spuštění. Můžete například přidat kroky, které používají službu Webhook Tester , abyste mohli zkontrolovat 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 základním obsahem, který chcete otestovat, například výraz nebo výstup jiného kroku.

3. Vložte adresu URL z testeru Webhooku 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 najdete na webu Webhook Tester.

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

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

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

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

• V latenci neexistuje žádná záruka SLA.

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

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

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

Hodnotu časového limitu akce nejde změnit a je pevná za 2 minuty. Pokud používáte akci HTTP a vlastníte službu volanou akcí HTTP, můžete službu změnit, abyste se vyhnuli 2minutovém vypršení časového limitu pomocí asynchronního vzoru. Další informace najdete v tématu Provádění dlouhotrvajících úloh se vzorem akce 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 v účtu úložiště Azure. Pokud tyto artefakty nejsou přístupné, můžou se zobrazit následující chyby. Samotný účet úložiště například nemusí být přístupný nebo je účet úložiště za bránou firewall, ale pro služby úložiště není nastavený žádný privátní koncový bod.

Umístění webu Azure Portal	Chyba
Podokno přehledu	- System.private.corelib:Přístup k cestě C:\home\site\wwwroot\host.json je 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 hostitelského modulu runtime. - Nelze se spojit s modulem runtime hostitele. Podrobnosti o chybě, kód: BadRequest, zpráva: Došlo k chybě (ServiceUnavailable) z hostitelského modulu runtime. - Nelze se spojit s modulem runtime hostitele. Podrobnosti o chybě, kód: BadRequest, zpráva: Došlo k chybě (BadGateway) z hostitelského modulu runtime.
Během vytváření a spouštění pracovního postupu	- Pracovní postup se nepovedlo uložit. - Chyba v návrháři: GetCallFailed. Neúspěšné operace načítání - AjaxExtended call failed

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

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

• U 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 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 s jedním tenantem.

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

  Důležité

  Pokud máte citlivé informace, například připojovací řetězec, které obsahují uživatelská jména a hesla, ujistěte se, že používáte nejbezpečnější dostupný tok ověřování. Například v pracovních postupech standardní aplikace logiky nejsou podporované zabezpečené datové typy, například securestring a secureobject. Microsoft doporučuje ověřit přístup k prostředkům Azure pomocí spravované identity , pokud je to možné, a přiřadit roli, která má minimální potřebná oprávnění.

  Pokud tato funkce není dostupná, nezapomeňte zabezpečit připojovací řetězec prostřednictvím jiných opatření, jako je například

Azure Key Vault, který můžete použít s nastavením aplikace. Pak můžete přímo odkazovat na zabezpečené řetězce, jako jsou připojovací řetězec a klíče. Podobně jako šablony ARM, kde můžete definovat proměnné prostředí v době nasazení, můžete definovat nastavení aplikace v definici pracovního postupu aplikace logiky. Pak můžete zaznamenávat dynamicky generované hodnoty infrastruktury, jako jsou koncové body připojení, řetězce úložiště a další. Další informace najdete v tématu Typy aplikací pro platformu Microsoft Identity Platform.

• U úč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, File, Table a Queue Storage 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. Na příkazovém řádku spusťte příkaz nslookup a zkontrolujte, jestli se služby Blob, File, Table a Queue Storage přeloží na očekávané IP adresy.

     Syntaxe: nslookup [StorageaccountHostName] [OptionalDNSServer]

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

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

     Stůl: nslookup {StorageaccountName}.table.core.windows.net

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

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

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

  3. Pokud se předchozí dotazy dns (domain name server) ú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]

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

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

     Stůl: psping {StorageaccountName}.table.core.windows.net:443

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

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

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

     2. Ověřte, že je integrace virtuální sítě správně nastavená s příslušnou virtuální sítí a podsítí v aplikaci logiky Standard.

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

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

Další kroky

• Monitorování aplikace logiky