Monitorování stavu standardních pracovních postupů v Azure Logic Apps s využitím kontroly stavu (Preview)

Platí pro: Azure Logic Apps (Standard)

Poznámka:

Tato funkce je ve verzi Preview a podléhá dodatečným podmínkám použití pro microsoft Azure Preview.

Pokud chcete svým pracovním postupům standardní aplikace logiky pomoct s vysokou dostupností a výkonem, nastavte ve vaší aplikaci logiky funkci Kontrola stavu pro monitorování stavu pracovního postupu. Tato funkce zajišťuje, aby vaše aplikace zůstala odolná, protože poskytuje následující výhody:

• Proaktivní monitorování, abyste mohli najít a řešit problémy dříve, než ovlivní vaše zákazníky.

• Vyšší dostupnost odebráním instancí, které nejsou v pořádku, z nástroje pro vyrovnávání zatížení v Azure

• Automatické obnovení nahrazením instancí, které nejsou v pořádku.

Jak funguje kontrola stavu ve službě Azure Logic Apps?

Kontrola stavu je funkce platformy Aplikace Azure Service, která přesměruje požadavky mimo instance, které nejsou v pořádku, a nahrazuje tyto instance, pokud nejsou v pořádku. Pro standardní aplikaci logiky můžete zadat cestu k pracovnímu postupu stavu, který vytvoříte pro tento účel, a pro platformu služby App Service, aby se v pravidelných intervalech příkaz ping. Například následující ukázka ukazuje základní minimální pracovní postup:

Po povolení kontroly stavu platforma App Service odešle příkaz ping na zadanou cestu pracovního postupu pro všechny instance aplikace logiky v 1minutových intervalech. Pokud aplikace logiky vyžaduje horizontální navýšení kapacity, Azure okamžitě vytvoří novou instanci. Platforma App Service znovu odešle příkazem ping cestu pracovního postupu, aby se ujistila, že je nová instance připravená.

Pokud pracovní postup spuštěný v instanci nereaguje na příkaz ping po 10 požadavcích, platforma App Service zjistí, že instance není v pořádku, a odebere instanci pro danou konkrétní aplikaci logiky z nástroje pro vyrovnávání zatížení v Azure. S minimálním dvěma požadavky můžete určit požadovaný počet neúspěšných požadavků, abyste zjistili, že instance není v pořádku. Další informace o přepsání výchozího chování najdete v tématu Konfigurace: Monitorování instancí služby App Service pomocí kontroly stavu.

Jakmile kontrola stavu odebere instanci, která není v pořádku, bude tato funkce pokračovat příkazem ping na instanci. Pokud instance reaguje stavovým kódem, který je v pořádku, včetně od 200 do 299, vrátí kontrola stavu instanci do nástroje pro vyrovnávání zatížení. Pokud však instance po dobu jedné hodiny není v pořádku, kontrola stavu nahradí instanci novou. Další informace najdete v tématu Co App Service dělá s kontrolami stavu.

Požadavky

• Účet a předplatné Azure. Pokud předplatné nemáte, zaregistrujte si bezplatný účet Azure.

• Prostředek aplikace standardní logiky s následujícími atributy:

  • Plán služby App Service, který se škáluje na dvě nebo více instancí.

  • Pracovní postup "health", který konkrétně spouští kontrolu stavu a následující prvky:

    • Začíná triggerem požadavku s názvem Při přijetí požadavku HTTP.

    • Zahrnuje akci Požadavku s názvem Odpověď. Nastavte tuto akci tak, aby se stavový kód vrátil v rozmezí od 200 do 299.

    Tento pracovní postup můžete také volitelně nechat spustit další kontroly, abyste měli jistotu, že závislé služby jsou dostupné a fungují podle očekávání. Osvědčeným postupem je zajistit, aby cesta kontroly stavu monitoruje kritické komponenty ve vašem pracovním postupu. Pokud například vaše aplikace závisí na systému databáze a zasílání zpráv, ujistěte se, že kontrola stavu má přístup k těmto komponentám.

Omezení

• Zadaná délka cesty musí mít méně než 65 znaků.

• Změny v zadané cestě pro kontrolu stavu způsobují restartování aplikace logiky. Pokud chcete snížit dopad na produkční aplikace, nastavte a používejte sloty nasazení.

• Kontrola stavu neprovádí přesměrování stavového kódu 302 , takže se vyhněte přesměrování a nezapomeňte vybrat platnou cestu, která ve vaší aplikaci existuje.

Nastavení kontroly stavu

1. Na webu Azure Portal přejděte k prostředku aplikace logiky Standard.

2. V nabídce aplikace logiky vyberte Diagnostikovat a řešit problémy.

3. Na stránce Diagnostika a řešení problémů vyhledejte a vyberte ve vyhledávacím poli funkci Kontrola stavu.

   

4. V části Funkce Kontrola stavu vyberte Zobrazit řešení.

5. V podokně, které se otevře, vyberte Konfigurovat a povolit funkci kontroly stavu.

6. Na kartě Kontrola stavu vedle kontroly stavu vyberte Povolit.

7. V části Cesta sondy stavu zadejte do pole Cesta platnou cestu URL pro váš pracovní postup, například:

   /api/{workflow-name}/triggers/{request-trigger-name}/invoke?api-version=2022-05-01

8. Uložte provedené změny. Na panelu nástrojů vyberte Uložit.

9. V prostředku aplikace logiky aktualizujte soubor host.json následujícím postupem:

   1. V nabídce aplikace logiky v části Vývojové nástroje vyberte Rozšířené nástroje>Přejít.

   2. Na panelu nástrojů KuduPlus v nabídce konzoly Ladění vyberte CMD.

   3. Přejděte do složky site/wwwroot a vedle souboru host.json vyberte Upravit.

   4. V editoru souborů host.json přidejte vlastnost Workflows.HealthCheckWorkflowName a název pracovního postupu stavu, abyste povolili ověřování a autorizaci kontroly stavu, například:

      "extensions": {
          "workflow": {
              "settings": {
                  "Workflows.HealthCheckWorkflowName" : "{workflow-name}"
              }
          }
      }
      

   5. Po dokončení vyberte Uložit.

Řešení problému

Po nastavení cesty stavu se pracovní postup stavu neaktivuje.

1. V nabídce aplikace logiky vyberte Diagnostikovat a řešit problémy.

2. V části Kategorie Řešení potíží vyberte Dostupnost a výkon.

   

3. Vyhledejte a zkontrolujte část stavového kódu.

   Pokud je stavový kód 401, zkontrolujte následující položky:

   • Ověřte, že se vlastnost Workflows.HealthCheckWorkflowName a název pracovního postupu stavu zobrazuje správně.

   • Ověřte, že zadaná cesta odpovídá názvu pracovního postupu a triggeru požadavku .

Běžné problémy se stavem

Prostředek aplikace logiky nemá žádné pracovní postupy, ale prostředek se stále škáluje na více instancí, což způsobuje náklady.

K tomuto chování může dojít, pokud prostředek aplikace logiky není v pořádku nebo obvykle, když prostředek nemá přístup k přidruženému účtu úložiště. Zkuste zkontrolovat, jestli má účet úložiště nastavení sítě, které blokuje přístup, nebo jestli máte zásadu brány firewall sítě, která blokuje přístup.

Prostředek aplikace logiky má pracovní postupy, ale nejsou spuštěné nebo běží hodně. Prostředek se ale stále škáluje na více instancí, což způsobuje náklady.

1. Zkontrolujte, jestli má prostředek přístup k přidruženému účtu úložiště.

   Má například účet úložiště síťové nastavení, které blokuje přístup? Máte zásadu síťové brány firewall, která blokuje přístup?

2. Pokud váš pracovní postup začíná aktivační událostí založenou na poskytovateli služeb, ujistěte se, že trigger úspěšně funguje podle očekávání.

   • Trigger založený na poskytovateli služeb, který selhal, může způsobit zbytečné škálování, což může výrazně zvýšit náklady.

     Běžným dohledem je například nastavení triggeru bez udělení oprávnění aplikace logiky nebo přístupu k cíli, jako je fronta služby Service Bus, kontejner objektů blob služby Storage atd.

   • Nezapomeňte tyto triggery vždy monitorovat, abyste mohli rychle zjišťovat a opravovat případné problémy.

Pracovní postup přerušovaně přestane zpracovávat zprávy po dobu hodin, ale většinou běží dobře.

Pokud vaše standardní aplikace logiky používá možnost hostování s názvem Plán služby pracovního postupu a není hostovaná ve službě App Service Environment, ujistěte se, že je zapnuté monitorování škálování modulu runtime a že instance always Ready jsou nastavené na alespoň 1.

1. Na webu Azure Portal vyhledejte a otevřete aplikaci logiky, pokud ještě není otevřená.

2. V nabídce aplikace logiky v části Nastavení vyberte Konfigurace.

3. Na kartě Nastavení modulu runtime pracovního postupu vedle možnosti Monitorování škálování modulu runtime vyberte Zapnuto.

4. Na panelu nástrojů stránky Konfigurace vyberte Uložit.

5. V nabídce aplikace logiky v části Nastavení vyberte Horizontální navýšení kapacity (plán služby App Service).

6. V části Horizontální navýšení kapacity aplikace se ujistěte, že hodnota Always Ready Instances není nastavená na 0.

Související obsah

• Monitorování a shromažďování diagnostických dat pro pracovní postupy
• Povolení a zobrazení rozšířené telemetrie pro standardní pracovní postupy
• Zobrazení metrik stavu a výkonu