Zpracování problémů s omezováním (429 – Chyby Příliš mnoho požadavků) v Azure Logic Apps
Platí pro: Azure Logic Apps (Consumption + Standard)
Pokud u pracovního postupu aplikace logiky dochází k omezování, což se stane, když počet požadavků překročí rychlost, s jakou může cíl zpracovat za určitou dobu, zobrazí se chyba HTTP 429 Příliš mnoho požadavků. Omezování může způsobovat problémy, jako je zpožděné zpracování dat, nižší výkon a rychlost, nebo chyby, například překročení zadaných zásad opakování.
Například následující akce SQL Serveru v pracovním postupu Consumption zobrazuje chybu 429, která hlásí problém s omezováním:
Následující části popisují běžné úrovně, na kterých může dojít k omezování pracovního postupu:
Omezování prostředků aplikace logiky
Azure Logic Apps má vlastní limity propustnosti. Pokud prostředek aplikace logiky tyto limity překročí, dojde k omezení prostředku aplikace logiky, nikoli jenom ke konkrétní instanci pracovního postupu nebo spuštění.
Pokud chcete najít události omezování na této úrovni, postupujte takto:
Na webu Azure Portal otevřete prostředek aplikace logiky.
V nabídce prostředků aplikace logiky v části Monitorování vyberte Metriky.
V části Název grafu vyberte Přidat metriku, která do grafu přidá další pruh metriky.
Na prvním panelu metrik v seznamu metrik vyberte Akce Omezené události. V seznamu Agregace vyberte Počet.
Na druhém panelu metrik v seznamu metrik vyberte Události s omezeními triggeru. V seznamu Agregace vyberte Počet.
Graf teď zobrazuje omezené události pro akce i triggery v pracovním postupu aplikace logiky. Další informace najdete v tématu Zobrazení metrik stavu a výkonu pracovního postupu v Azure Logic Apps.
Pokud chcete zvládnout omezování na této úrovni, máte následující možnosti:
Omezte počet instancí pracovního postupu, které se dají spustit současně.
Pokud je ve výchozím nastavení splněna podmínka triggeru pracovního postupu více než jednou najednou, pak se aktivuje více instancí tohoto triggeru a spustí se souběžně nebo paralelně. Každá instance triggeru se aktivuje před dokončením spuštění předchozí instance pracovního postupu.
I když je výchozí počet instancí aktivačních událostí, které lze souběžně spustit , neomezený, můžete toto číslo omezit zapnutím nastavení souběžnosti triggeru a v případě potřeby vybrat jiný limit než výchozí hodnota.
Povolte režim vysoké propustnosti.
Pracovní postup Consumption má výchozí limit počtu akcí, které se můžou spouštět během 5minutového intervalu. Pokud chcete tento limit zvýšit na maximální počet akcí, zapněte u prostředku aplikace logiky režim vysoké propustnosti.
Standardní pracovní postup nemá žádný limit počtu akcí, které se můžou spouštět v jakémkoli intervalu.
V triggerech zakažte chování rozdělení pole nebo Rozdělení na.
Pokud aktivační událost vrátí pole pro zbývající akce pracovního postupu ke zpracování, nastavení Rozdělit při triggeru rozdělí položky pole a spustí instanci pracovního postupu pro každou položku pole. Toto chování efektivně aktivuje více souběžných spuštění až do limitu Rozdělit při.
Pokud chcete řídit omezování, vypněte chování při rozdělení triggeru a požádejte pracovní postup zpracovat celé pole jediným voláním, a ne zpracovat jednu položku na volání.
Refaktoring akcí do několika menších pracovních postupů
Jak už bylo zmíněno dříve, pracovní postup aplikace logiky Consumption je omezený na výchozí počet akcí, které se můžou spouštět po dobu 5 minut. I když tento limit můžete zvýšit povolením režimu vysoké propustnosti, můžete také zvážit, jestli chcete rozdělit akce pracovního postupu do menších pracovních postupů tak, aby počet akcí spuštěných v každém pracovním postupu zůstal pod limitem. Tímto způsobem snížíte zatížení jednoho pracovního postupu a rozdělíte zatížení mezi více pracovních postupů. Toto řešení funguje lépe pro akce, které zpracovávají velké datové sady nebo spouští tolik souběžně spuštěných akcí, iterací smyčky nebo akcí uvnitř každé iterace smyčky, které překračují limit provádění akcí.
Například následující pracovní postup Consumption provede veškerou práci na získání tabulek z databáze SQL Serveru a získá řádky z každé tabulky. Smyčka Pro každou smyčku souběžně prochází každou tabulkou, aby akce Získat řádky vrátila řádky pro každou tabulku. Na základě objemu dat v těchto tabulkách mohou tyto akce překročit limit provádění akcí.
Po refaktoringu se původní pracovní postup rozdělí do nadřazeného pracovního postupu a podřízeného pracovního postupu.
Následující nadřazený pracovní postup získá tabulky z SQL Serveru a potom zavolá podřízený pracovní postup pro každou tabulku, aby získal řádky:
Nadřazený pracovní postup volá následující podřízený pracovní postup, který získá řádky pro každou tabulku:
Omezování spojnice
Každý konektor má vlastní limity omezování, které najdete na technické referenční stránce jednotlivých konektorů. Konektor Azure Service Bus má například omezení omezení, které umožňuje až 6 000 volání za minutu, zatímco konektor SQL Serveru má omezení, která se liší podle typu operace.
Některé triggery a akce, jako je HTTP, mají "zásadu opakování" , kterou můžete přizpůsobit na základě omezení zásad opakování pro implementaci zpracování výjimek. Tato zásada určuje, jestli a jak často trigger nebo akce opakují požadavek, když původní požadavek selže nebo vyprší časový limit a výsledkem je odpověď 408, 429 nebo 5xx. Proto když se spustí omezování a vrátí chybu 429, služba Logic Apps se řídí zásadami opakování, které jsou podporované.
Pokud chcete zjistit, jestli trigger nebo akce podporuje zásady opakování, zkontrolujte nastavení triggeru nebo akce. Pokud chcete zobrazit pokusy o opakování triggeru nebo akce, přejděte do historie spuštění aplikace logiky, vyberte spuštění, které chcete zkontrolovat, a rozbalte tuto aktivační událost nebo akci, abyste zobrazili podrobnosti o vstupech, výstupech a opakováních.
Následující příklad pracovního postupu Consumption ukazuje, kde najdete tyto informace pro akci HTTP:
I když historie opakování obsahuje informace o chybách, mohlo by dojít k potížím mezi omezováním konektoru a omezováním cíle. V takovém případě možná budete muset zkontrolovat podrobnosti odpovědi nebo provést některé výpočty intervalu omezování, abyste identifikovali zdroj.
V případě pracovních postupů aplikace logiky Consumption ve víceklientských azure Logic Apps dochází k omezování na úrovni připojení .
Pokud chcete zvládnout omezování na této úrovni, máte následující možnosti:
Nastavte více připojení pro jednu akci, aby pracovní postup mohl rozdělit data ke zpracování.
Zvažte, jestli můžete úlohu distribuovat rozdělením požadavků akce napříč několika připojeními ke stejnému cíli pomocí stejných přihlašovacích údajů.
Předpokládejme například, že váš pracovní postup získá tabulky z databáze SQL Serveru a pak získá řádky z každé tabulky. Na základě počtu řádků, které je potřeba zpracovat, můžete použít více připojení a více pro každou smyčku k rozdělení celkového počtu řádků na menší sady pro zpracování. Tento scénář používá dva pro každou smyčku k rozdělení celkového počtu řádků v polovině. První smyčka Pro každou smyčku používá výraz, který získá první polovinu. Druhá smyčka Pro každou smyčku používá jiný výraz, který získá druhou polovinu, například:
Výraz 1: Funkce
take()získá před kolekcí. Další informace najdete vtake()této funkci.@take(collection-or-array-name, div(length(collection-or-array-name), 2))Výraz 2: Funkce
skip()odebere přední část kolekce a vrátí všechny ostatní položky. Další informace najdete vskip()této funkci.@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Následující příklad pracovního postupu Consumption ukazuje, jak můžete použít tyto výrazy:
Nastavte pro každou akci jiné připojení.
Zvažte, jestli můžete úlohy distribuovat rozložením požadavků jednotlivých akcí na vlastní připojení, i když se akce připojují ke stejné službě nebo systému a používají stejné přihlašovací údaje.
Předpokládejme například, že váš pracovní postup získá tabulky z databáze SQL Serveru a získá každý řádek v každé tabulce. Můžete použít samostatná připojení, aby získání tabulek používalo jedno připojení, zatímco získání každého řádku používá jiné připojení.
Následující příklad ukazuje pracovní postup Consumption, který pro každou akci vytvoří a používá jiné připojení:
Změňte souběžnost nebo paralelismus ve smyčce For each.
Ve výchozím nastavení se iterace smyčky For each spustí ve stejnou dobu až do limitu souběžnosti. Pokud máte připojení, které se omezuje uvnitř smyčky "For each", můžete snížit počet iterací smyčky, které běží paralelně. Další informace najdete v následující dokumentaci:
Omezování cílové služby nebo systému
I když má konektor vlastní limity omezování, cílová služba nebo systém, který konektor volá, můžou mít také limity omezování. Některá rozhraní API na Microsoft Exchange Serveru mají například přísnější omezení omezení než konektor Office 365 Outlook.
Ve výchozím nastavení běží instance pracovního postupu aplikace logiky a všechny smyčky nebo větve uvnitř těchto instancí paralelně. Toto chování znamená, že více instancí může současně volat stejný koncový bod. Každá instance neví o existenci druhé instance, takže pokusy o opakování neúspěšných akcí můžou vytvořit podmínky časování, kdy se několik volání pokusí spustit současně, ale aby bylo možné úspěšně, musí tato volání dorazit do cílové služby nebo systému, než začne docházet k omezování.
Předpokládejme například, že máte pole s 100 položkami. Smyčku "For each" použijete k iteraci pole a zapnete řízení souběžnosti smyčky, abyste mohli omezit počet paralelních iterací na 20 nebo aktuální výchozí limit. Uvnitř této smyčky akce vloží položku z pole do databáze SQL Serveru, která povoluje pouze 15 volání za sekundu. Tento scénář má za následek problém s omezováním, protože backlog opakování se sestaví a nikdy se nespustí.
Následující tabulka popisuje časovou osu toho, co se stane ve smyčce, když je interval opakování akce 1 sekunda:
| Bod v čase | Počet spuštěných akcí | Počet akcí, které selžou | Počet opakovaných pokusů čekajících |
|---|---|---|---|
| T + 0 sekund | 20 vložení | 5 selhání kvůli limitu SQL | 5 opakování |
| T + 0,5 sekund | 15 vložení, kvůli předchozím 5 opakovaným pokusům čekajících | Všech 15 selhání, protože předchozí limit SQL stále platí po dobu dalších 0,5 sekund | 20 opakování (předchozí 5 + 15 nových) |
| T + 1 sekunda | 20 vložení | 5 selhání a předchozích 20 opakování kvůli limitu SQL | 25 opakování (předchozí 20 + 5 nových) |
Pokud chcete zvládnout omezování na této úrovni, máte následující možnosti:
Vytvořte jednotlivé pracovní postupy tak, aby každý z nich zpracovával jednu operaci.
Pokračovat v ukázkovém scénáři SQL Serveru v této části můžete vytvořit pracovní postup, který umístí položky pole do fronty, jako je fronta služby Azure Service Bus. Pak vytvoříte jiný pracovní postup, který provede pouze operaci vložení pro každou položku v této frontě. Tímto způsobem se spustí vždy jenom jedna instance pracovního postupu, která buď dokončí operaci vložení a přesune se na další položku ve frontě, nebo instance získá chyby 429, ale nepokouší se neprodukční opakování.
Vytvořte nadřazený pracovní postup, který volá podřízený nebo vnořený pracovní postup pro každou akci. Pokud nadřazený objekt potřebuje volat různé podřízené pracovní postupy na základě výsledku nadřazeného objektu, můžete použít akci podmínky nebo přepnout akci, která určuje, který podřízený pracovní postup se má volat. Tento model vám může pomoct snížit počet volání nebo operací.
Předpokládejme například, že máte dva pracovní postupy, každý s triggerem dotazování, který kontroluje váš e-mailový účet každou minutu pro konkrétní předmět, například "Úspěch" nebo "Selhání". Výsledkem tohoto nastavení je 120 volání za hodinu. Pokud místo toho vytvoříte jeden nadřazený pracovní postup, který se dotazuje každou minutu, ale zavolá podřízený pracovní postup, který se spustí na základě toho, jestli je předmět "Úspěch" nebo "Selhání", počet kontrol dotazování v tomto případě vyříznete na polovinu nebo 60.
Nastavení dávkového zpracování (Pouze pracovní postupy consumption)
Pokud cílová služba podporuje dávkové operace, můžete omezení řešit zpracováním položek ve skupinách nebo dávkách, nikoli jednotlivě. Pokud chcete implementovat řešení dávkového zpracování, vytvoříte pracovní postup aplikace logiky batch receiver a pracovní postup aplikace logiky batch sender. Odesílatel dávky shromažďuje zprávy nebo položky, dokud nebudou splněna zadaná kritéria, a pak tyto zprávy nebo položky odešle do jedné skupiny. Příjemce dávky přijme danou skupinu a zpracuje tyto zprávy nebo položky. Další informace najdete v tématu Dávkové zpracování zpráv ve skupinách.
Používejte verze webhooku pro triggery a akce místo verzí dotazování.
Proč? Trigger dotazování bude dál kontrolovat cílovou službu nebo systém v určitých intervalech. Velmi častý interval, například každou sekundu, může způsobit problémy s omezováním. Trigger nebo akce webhooku, jako je například webhook HTTP, ale vytvoří pouze jedno volání cílové služby nebo systému, ke kterému dochází v době odběru a požaduje, aby cíl trigger nebo akci upozornil pouze v případě, že dojde k události. Trigger nebo akce tak nemusí průběžně kontrolovat cíl.
Pokud tedy cílová služba nebo systém podporuje webhooky nebo poskytuje konektor s verzí webhooku, je tato možnost lepší než použití verze dotazování. Pokud chcete identifikovat triggery a akce webhooku, ověřte, že mají
ApiConnectionWebhooktyp nebo že nevyžadují, abyste zadali opakování. Další informace naleznete v tématu APIConnectionWebhook trigger a APIConnectionWebhook akce.