Delen via

Status bewaken voor Standaardwerkstromen in Azure Logic Apps met statuscontrole

Van toepassing op: Azure Logic Apps (Standard)

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:

Schermopname van de werkstroom van de standaard logische app die moet worden gebruikt als de statuswerkstroom.

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.

Prerequisites

  • 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.

Limitations

  • 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.

  • Gezondheidscontrole volgt geen doorverwijzingen voor de 302-statuscode. Vermijd dus omleidingen en zorg ervoor dat u een 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 statuscontrole in het menu van de logische app onder Bewaking. Selecteer Inschakelen op de pagina Statuscontrole op het tabblad Statuscontrole.

    Schermopname van Azure Portal, pagina voor statuscontrole en geselecteerde optie voor Inschakelen.

  3. 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

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

  5. 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.

Troubleshooting

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.

    Schermopname van Azure Portal, pagina voor Problemen vaststellen en oplossen, en de geselecteerde optie voor 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, moet u ervoor zorgen dat runtimeschaalbewaking is ingeschakeld en dat Always Ready Instances is ingesteld op ten minste 1.

  1. Open uw logische app in Azure Portal.

  2. Selecteer Configuratie in de zijbalk van de logische app onder Instellingen.

  3. Op het tabblad Runtime-instellingen van de werkstroom, naast Bewaking van runtimeschaal, selecteer de optie Aan en selecteer Toepassen.

  4. Selecteer in de zijbalk van de logische app onder App Service-plan de optie Uitschalen.

  5. Zorg ervoor dat onder App Uitschalen de waarde Always Ready Instances niet is ingesteld op0.

Als uw logische standaard-app wordt gehost in App Service Environment, zorg ervoor dat Always on is ingeschakeld.

  1. Zoek en open uw logische app in Azure Portal.

  2. Selecteer Configuratie in de zijbalk van de logische app onder Instellingen.

  3. Selecteer Altijd inschakelen op het tabblad Algemene instellingen en selecteer Vervolgens Toepassen.

Verwante inhoud

  • Last updated on