Status bewaken voor Standaardwerkstromen in Azure Logic Apps met statuscontrole (preview)

Van toepassing op: Azure Logic Apps (Standard)

Notitie

Deze mogelijkheid is in preview en is onderworpen aan de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews.

Als u wilt dat uw standaardwerkstromen voor logische apps worden uitgevoerd met hoge beschikbaarheid en prestaties, stelt u de functie Statuscontrole in op uw logische app om de werkstroomstatus te bewaken. Deze functie zorgt ervoor dat uw app tolerant blijft door de volgende voordelen te bieden:

• Proactieve bewaking, zodat u problemen kunt vinden en oplossen voordat ze van invloed zijn op uw klanten.

• Verbeterde beschikbaarheid door beschadigde exemplaren uit de load balancer in Azure te verwijderen.

• Automatisch herstel door beschadigde exemplaren te vervangen.

Hoe werkt health check in Azure Logic Apps?

Health Check is een Azure-app Service-platformfunctie waarmee aanvragen worden omgeleid van beschadigde exemplaren en die exemplaren worden vervangen als ze beschadigd blijven. Voor een standaard logische app kunt u een pad opgeven naar een 'statuswerkstroom' die u voor dit doel maakt en zodat het App Service-platform regelmatig pingt. In het volgende voorbeeld ziet u bijvoorbeeld de basiswerkstroom voor minimale werkstromen:

Nadat u Health Check hebt ingeschakeld, pingt het App Service-platform het opgegeven werkstroompad voor alle exemplaren van logische apps met intervallen van 1 minuut. Als de logische app uitschalen vereist, maakt Azure onmiddellijk een nieuw exemplaar. Het App Service-platform pingt het werkstroompad opnieuw om ervoor te zorgen dat het nieuwe exemplaar gereed is.

Als een werkstroom die wordt uitgevoerd op een exemplaar niet reageert op de ping na 10 aanvragen, bepaalt het App Service-platform dat het exemplaar beschadigd is en verwijdert het exemplaar voor die specifieke logische app uit de load balancer in Azure. Met een minimum van twee aanvragen kunt u het vereiste aantal mislukte aanvragen opgeven om te bepalen dat een exemplaar niet in orde is. Zie Configuratie: App Service-exemplaren bewaken met statuscontrole voor meer informatie over het overschrijven van standaardgedrag.

Nadat de statuscontrole het beschadigde exemplaar heeft verwijderd, blijft de functie het exemplaar pingen. Als het exemplaar reageert met een statuscode die in orde is, inclusief 200 tot 299, retourneert de statuscontrole het exemplaar naar de load balancer. Als het exemplaar echter één uur in orde blijft, vervangt Health Check het exemplaar door een nieuwe. Zie Wat App Service doet met statuscontroles voor meer informatie.

Vereisten

• Een Azure-account en -abonnement. Als u nog geen abonnement hebt, meld u dan aan voor een gratis Azure-account.

• Een standaardresource voor logische apps met de volgende kenmerken:

  • Een App Service-plan dat wordt geschaald naar twee of meer exemplaren.

  • Een 'statuswerkstroom' die specifiek de statuscontrole uitvoert en de volgende elementen:

    • Begint met de aanvraagtrigger met de naam Wanneer een HTTP-aanvraag wordt ontvangen.

    • Bevat de actie Aanvraag met de naam Antwoord. Stel deze actie in om een statuscode tussen 200 en 299 te retourneren.

    U kunt deze werkstroom desgewenst ook andere controles laten uitvoeren om ervoor te zorgen dat afhankelijke services beschikbaar zijn en werken zoals verwacht. Als best practice moet u ervoor zorgen dat het pad Statuscontrole kritieke onderdelen in uw werkstroom bewaakt. Als uw app bijvoorbeeld afhankelijk is van een database- en berichtensysteem, moet u ervoor zorgen dat Health Check toegang heeft tot deze onderdelen.

Beperkingen

• De opgegeven padlengte mag uit minder dan 65 tekens bestaan.

• Wijzigingen in het opgegeven pad voor Statuscontrole zorgen ervoor dat uw logische app opnieuw wordt opgestart. Als u de impact op productie-apps wilt verminderen, moet u implementatiesites instellen en gebruiken.

• Statuscontrole volgt geen omleidingen voor de 302-statuscode . Vermijd omleidingen en zorg ervoor dat u een geldig pad selecteert dat in uw app aanwezig is.

Statuscontrole instellen

1. Ga in Azure Portal naar de resource van uw standaard logische app.

2. Selecteer in het menu van de logische app de optie Problemen vaststellen en oplossen.

3. Zoek en selecteer de functie Statuscontrole in het zoekvak op de pagina Problemen vaststellen en oplossen.

   

4. Selecteer Oplossing weergeven in de sectie Statuscontrole.

5. Selecteer in het deelvenster dat wordt geopend de functie Configureren en statuscontrole inschakelen.

6. Selecteer Inschakelen op het tabblad Statuscontrole naast Statuscontrole.

7. Voer onder Pad in het vak Pad een geldig URL-pad in voor uw werkstroom, bijvoorbeeld:

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

8. Sla uw wijzigingen op. Selecteer Opslaan op de werkbalk.

9. Werk in de resource van uw logische app het host.json-bestand bij door de volgende stappen uit te voeren:

   1. Selecteer Advanced Tools Go in het menu van de logische app onder Ontwikkelhulpprogramma's>.

   2. Selecteer CMD in het consolemenu Foutopsporing op de werkbalk KuduPlus.

   3. Blader naar de site-/wwwroot-map en selecteer naast het bestand host.json Bewerken.

   4. Voeg in de host.json bestandseditor de eigenschap Workflows.HealthCheckWorkflowName en de naam van uw statuswerkstroom toe om verificatie en autorisatie voor statuscontrole in te schakelen, bijvoorbeeld:

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

   5. Selecteer Opslaan wanneer u klaar bent.

Probleemoplossing

Nadat ik het statuspad heb ingesteld, wordt mijn statuswerkstroom niet geactiveerd.

1. Selecteer in het menu van de logische app de optie Problemen vaststellen en oplossen.

2. Selecteer onder Categorieën voor probleemoplossing de optie Beschikbaarheid en prestaties.

   

3. Zoek en controleer de sectie statuscode.

   Als de statuscode 401 is, controleert u de volgende items:

   • Controleer of de eigenschap Workflows.HealthCheckWorkflowName en de naam van uw statuswerkstroom correct worden weergegeven.

   • Controleer of het opgegeven pad overeenkomt met de naam van de werkstroom en aanvraagtrigger.

Veelvoorkomende gezondheidsproblemen

Mijn logische app-resource heeft geen werkstromen, maar de resource wordt nog steeds uitgeschaald naar meerdere exemplaren, waardoor er kosten in rekening worden gebracht.

Dit gedrag kan optreden als de resource van de logische app niet in orde is of normaal gesproken wanneer de resource geen toegang heeft tot het gekoppelde opslagaccount. Controleer of het opslagaccount een netwerkinstelling heeft waarmee de toegang wordt geblokkeerd of of u een netwerkfirewallbeleid hebt waarmee de toegang wordt geblokkeerd.

Mijn resource voor logische apps heeft werkstromen, maar ze worden niet veel uitgevoerd of uitgevoerd. De resource wordt echter nog steeds uitgeschaald naar meerdere exemplaren, waardoor er kosten in rekening worden gebracht.

1. Controleer of de resource toegang heeft tot het gekoppelde opslagaccount.

   Heeft het opslagaccount bijvoorbeeld een netwerkinstelling waarmee de toegang wordt geblokkeerd? Hebt u een netwerkfirewallbeleid waarmee de toegang wordt geblokkeerd?

2. Als uw werkstroom begint met een trigger op basis van een serviceprovider, moet u ervoor zorgen dat de trigger naar behoren werkt.

   • Een trigger op basis van een mislukte serviceprovider kan onnodig schalen maken, waardoor de kosten aanzienlijk kunnen worden verhoogd.

     Een algemeen toezicht is bijvoorbeeld het instellen van een trigger zonder uw logische app toestemming of toegang te geven tot de bestemming, zoals een Service Bus-wachtrij, opslagblobcontainer, enzovoort.

   • Zorg ervoor dat u dergelijke triggers altijd bewaakt, zodat u onmiddellijk eventuele problemen kunt detecteren en oplossen.

Mijn werkstroom stopt af en toe met het verwerken van berichten gedurende uren, maar wordt meestal goed uitgevoerd.

Als uw logische standaard-app gebruikmaakt van de hostingoptie Workflow Service Plan en niet wordt gehost in een App Service Environment, moet u ervoor zorgen dat Bewaking van runtimeschaal is ingeschakeld en dat Always Ready Instances is ingesteld op ten minste 1.

1. Zoek en open uw logische app in Azure Portal, als deze nog niet is geopend.

2. Selecteer Configuratie in het menu van de logische app onder Instellingen.

3. Selecteer op het tabblad Runtime-instellingen van de werkstroom, naast Bewaking van runtimeschaal, de optie Aan.

4. Selecteer Opslaan op de werkbalk Configuratiepagina.

5. Selecteer in het menu van de logische app onder Instellingen de optie Uitschalen (App Service-plan).

6. Zorg ervoor dat onder App Uitschalen de waarde Always Ready Instances niet is ingesteld op 0.

Gerelateerde inhoud

• Diagnostische gegevens voor werkstromen bewaken en verzamelen
• Verbeterde telemetrie voor standaardwerkstromen inschakelen en weergeven
• Metrische gegevens over status en prestaties weergeven