Problemen met werkstromen in Azure Logic Apps vaststellen en oplossen
Van toepassing op: Azure Logic Apps (Verbruik + Standard)
Uw werkstroom voor logische apps genereert informatie waarmee u problemen in uw app kunt vaststellen en opsporen. U kunt uw werkstroom diagnosticeren door de invoer, uitvoer en andere informatie voor elke stap in de werkstroom te controleren met behulp van Azure Portal. U kunt ook enkele stappen toevoegen aan een werkstroom voor runtime-foutopsporing.
Triggergeschiedenis controleren
Elke werkstroomuitvoering begint met een trigger, die wordt geactiveerd volgens een planning of wacht op een binnenkomende aanvraag of gebeurtenis. De triggergeschiedenis bevat alle triggerpogingen die uw werkstroom heeft uitgevoerd en informatie over de invoer en uitvoer voor elke triggerpoging. Als de trigger niet wordt geactiveerd, voert u de volgende stappen uit.
Als u de status van de trigger in de logische app Verbruik wilt controleren, bekijkt u de triggergeschiedenis. Als u meer informatie over de triggerpoging wilt weergeven, selecteert u die trigger-gebeurtenis, bijvoorbeeld:
Controleer de invoer van de trigger om te bevestigen dat deze worden weergegeven zoals verwacht. Selecteer in het deelvenster Geschiedenis onder Invoerkoppeling de koppeling, waarin het deelvenster Invoer wordt weergegeven.
Triggerinvoer bevat de gegevens die de trigger verwacht en vereist om de werkstroom te starten. Als u deze invoer controleert, kunt u bepalen of de triggerinvoer juist is en of aan de voorwaarde is voldaan, zodat de werkstroom kan worden voortgezet.
Controleer de uitvoer van triggers, indien van toepassing, om te bevestigen dat deze worden weergegeven zoals u verwacht. Selecteer in het deelvenster Geschiedenis onder De koppeling Uitvoer de koppeling, waarin het deelvenster Uitvoer wordt weergegeven.
Triggeruitvoer bevat de gegevens die de trigger doorgeeft aan de volgende stap in uw werkstroom. Door deze uitvoer te bekijken, kunt u bepalen of de juiste of verwachte waarden zijn doorgegeven aan de volgende stap in uw werkstroom.
Een foutbericht geeft bijvoorbeeld aan dat de RSS-feed niet is gevonden:
Tip
Als u inhoud vindt die u niet herkent, vindt u meer informatie over verschillende inhoudstypen in Azure Logic Apps.
De uitvoeringsgeschiedenis van de werkstroom controleren
Telkens wanneer de trigger wordt geactiveerd, maakt Azure Logic Apps een werkstroomexemplaren en wordt dat exemplaar uitgevoerd. Als een uitvoering mislukt, voert u de volgende stappen uit, zodat u kunt controleren wat er is gebeurd tijdens die uitvoering. U kunt de status, invoer en uitvoer voor elke stap in de werkstroom bekijken.
Als u de uitvoeringsstatus van de werkstroom in de logische app Verbruik wilt controleren, bekijkt u de uitvoeringsgeschiedenis. Als u meer informatie wilt over een mislukte uitvoering, inclusief alle stappen in die uitvoering in hun status, selecteert u de mislukte uitvoering.
Nadat alle stappen in de uitvoering zijn weergegeven, selecteert u elke stap om de shapes uit te vouwen.
Controleer de invoer, uitvoer en eventuele foutberichten voor de mislukte stap.
In de volgende schermopname ziet u bijvoorbeeld de uitvoer van de mislukte RSS-actie.
Fouten in runtime opsporen
Voor hulp bij foutopsporing kunt u diagnostische stappen toevoegen aan een werkstroom van een logische app, samen met het controleren van de trigger en de uitvoeringsgeschiedenis. U kunt bijvoorbeeld stappen toevoegen die gebruikmaken van de Webhook Tester-service , zodat u HTTP-aanvragen kunt inspecteren en de exacte grootte, vorm en indeling ervan kunt bepalen.
Ga in een browser naar de Websitehook Tester en kopieer de gegenereerde unieke URL.
Voeg in uw logische app een HTTP POST-actie toe met de hoofdtekstinhoud die u wilt testen, bijvoorbeeld een expressie of uitvoer van een andere stap.
Plak uw URL van Webhook Tester in de HTTP POST-actie.
Als u wilt controleren hoe Azure Logic Apps een aanvraag genereert en vormt, voert u de werkstroom van de logische app uit. Vervolgens kunt u de Websitehook Tester opnieuw bezoeken voor meer informatie.
Prestaties - veelgestelde vragen (FAQ)
Waarom duurt de uitvoering van de werkstroom langer dan de som van alle duur van de werkstroomactie?
Planningsoverhead bestaat bij het uitvoeren van acties, terwijl de wachttijd tussen acties kan optreden vanwege de belasting van het back-endsysteem. Een uitvoeringsduur van een werkstroom omvat deze planningstijden en wachttijden, samen met de som van alle actieduur.
Normaal gesproken wordt mijn werkstroom binnen 10 seconden voltooid. Maar soms kan voltooiing veel langer duren. Hoe kan ik ervoor zorgen dat de werkstroom altijd binnen 10 seconden is voltooid?
Er bestaat geen SLA-garantie op latentie.
Verbruikswerkstromen worden uitgevoerd op Azure Logic Apps met meerdere tenants, zodat de werkbelastingen van andere klanten de prestaties van uw werkstroom negatief beïnvloeden.
Voor voorspelbarere prestaties kunt u overwegen om Standard-werkstromen te maken, die worden uitgevoerd in Azure Logic Apps met één tenant. U hebt meer controle om omhoog of uit te schalen om de prestaties te verbeteren.
Mijn actie treedt na 2 minuten op. Hoe kan ik de time-outwaarde verhogen?
De time-outwaarde van de actie kan niet worden gewijzigd en is opgelost op 2 minuten. Als u de HTTP-actie gebruikt en u de eigenaar bent van de service die wordt aangeroepen door de HTTP-actie, kunt u uw service wijzigen om de time-out van 2 minuten te voorkomen met behulp van het asynchrone patroon. Zie Langlopende taken uitvoeren met het polling-actiepatroon voor meer informatie.
Veelvoorkomende problemen - Standaard logische apps
Ontoegankelijke artefacten in Een Azure-opslagaccount
Met standaard logische apps worden alle artefacten opgeslagen in een Azure-opslagaccount. Mogelijk krijgt u de volgende fouten als deze artefacten niet toegankelijk zijn. Het opslagaccount zelf is bijvoorbeeld mogelijk niet toegankelijk of het opslagaccount bevindt zich achter een firewall, maar er is geen privé-eindpunt ingesteld voor gebruik van de opslagservices.
Locatie van Azure Portal | Error |
---|---|
Overzichtsdeelvenster | - System.private.corelib:Toegang tot het pad 'C:\home\site\wwwroot\hostj.son is geweigerd - Azure.Storage.Blobs: deze aanvraag is niet gemachtigd om deze bewerking uit te voeren |
Deelvenster Werkstromen | - Kan de hostruntime niet bereiken. Foutdetails, Code: 'BadRequest', Bericht: 'Er is een fout opgetreden (InternalServerError) van hostruntime.' - Kan de hostruntime niet bereiken. Foutdetails, code: 'BadRequest', bericht: 'Er is een fout opgetreden (ServiceUnavailable) van hostruntime.' - Kan de hostruntime niet bereiken. Foutdetails, code: 'BadRequest', bericht: 'Er is een fout opgetreden (BadGateway) van hostruntime.' |
Tijdens het maken en uitvoeren van de werkstroom | - Kan werkstroom niet opslaan - Fout in de ontwerpfunctie: GetCallFailed. Mislukte ophaalbewerkingen - ajaxExtended-aanroep is mislukt |
Opties voor probleemoplossing
De volgende lijst bevat mogelijke oorzaken voor deze fouten en stappen voor het oplossen van problemen.
Controleer op de volgende manieren de toegang tot het opslagaccount voor een openbaar opslagaccount:
Controleer de connectiviteit van het opslagaccount met behulp van Azure Storage Explorer.
Bevestig in de app-instellingen van uw logische app-resource de verbindingsreeks van het opslagaccount in de app-instellingen, AzureWebJobsStorage en WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Raadpleeg de host- en app-instellingen voor logische apps in Azure Logic Apps met één tenant voor meer informatie.
Als de verbinding mislukt, controleert u of de SAS-sleutel (Shared Access Signature) in de verbindingsreeks het meest recent is.
Belangrijk
Wanneer u gevoelige informatie hebt, zoals verbindingsreeks s die gebruikersnamen en wachtwoorden bevatten, moet u ervoor zorgen dat u de veiligste verificatiestroom gebruikt die beschikbaar is. In standaardwerkstromen voor logische apps worden bijvoorbeeld beveiligde gegevenstypen, zoals
securestring
ensecureobject
, niet ondersteund. Microsoft raadt u aan om de toegang tot Azure-resources te verifiëren met een beheerde identiteit , indien mogelijk, en een rol toe te wijzen met de minimale bevoegdheid die nodig is.Als deze mogelijkheid niet beschikbaar is, moet u ervoor zorgen dat u verbindingsreeks s beveiligt via andere metingen, zoals
Azure Key Vault, die u kunt gebruiken met app-instellingen. U kunt vervolgens rechtstreeks verwijzen naar beveiligde tekenreeksen, zoals verbindingsreeks s en sleutels. Net als bij ARM-sjablonen, waar u omgevingsvariabelen tijdens de implementatie kunt definiëren, kunt u app-instellingen definiëren binnen de werkstroomdefinitie van uw logische app. Vervolgens kunt u dynamisch gegenereerde infrastructuurwaarden vastleggen, zoals verbindingseindpunten, opslagreeksen en meer. Zie Toepassingstypen voor het Microsoft Identity Platform voor meer informatie.
Controleer op de volgende manieren de toegang tot het opslagaccount voor een opslagaccount dat zich achter een firewall bevindt:
Als firewallbeperkingen zijn ingeschakeld voor het opslagaccount, controleert u of privé-eindpunten zijn ingesteld voor blob-, bestands-, tabel- en wachtrijopslagservices.
Controleer de connectiviteit van het opslagaccount met behulp van Azure Storage Explorer.
Als u verbindingsproblemen ondervindt, gaat u verder met de volgende stappen:
Maak in hetzelfde virtuele netwerk dat is geïntegreerd met uw logische app een virtuele Azure-machine, die u in een ander subnet kunt plaatsen.
Voer nslookup uit vanaf een opdrachtprompt om te controleren of de blob-, bestands-, tabel- en wachtrijopslagservices worden omgezet in de verwachte IP-adressen.
Syntaxis:
nslookup [StorageaccountHostName] [OptionalDNSServer]
Blob:
nslookup {StorageaccountName}.blob.core.windows.net
Bestand:
nslookup {StorageaccountName}.file.core.windows.net
Tafel:
nslookup {StorageaccountName}.table.core.windows.net
Rij:
nslookup {StorageaccountName}.queue.core.windows.net
Als de opslagservice een service-eindpunt heeft, wordt de service omgezet in een openbaar IP-adres.
Als de opslagservice een privé-eindpunt heeft, wordt de service omgezet in de respectieve NIC-privé-IP-adressen (Network Interface Controller).
Als de vorige DNS-query's (Domain Name Server) zijn omgezet, voert u de psping - of tcpping-opdrachten uit om de verbinding met het opslagaccount via poort 443 te controleren:
Syntaxis:
psping [StorageaccountHostName] [Port] [OptionalDNSServer]
Blob:
psping {StorageaccountName}.blob.core.windows.net:443
Bestand:
psping {StorageaccountName}.file.core.windows.net:443
Tafel:
psping {StorageaccountName}.table.core.windows.net:443
Rij:
psping {StorageaccountName}.queue.core.windows.net:443
Als elke opslagservice kan worden omgezet vanuit uw virtuele Azure-machine, zoekt u de DNS die wordt gebruikt door de virtuele machine voor omzetting.
Stel de WEBSITE_DNS_SERVER-app-instelling van uw logische app in op de DNS en controleer of de DNS werkt.
Controleer of VNet-integratie correct is ingesteld met het juiste virtuele netwerk en subnet in uw standaard logische app.
Als u privé-Azure DNS-zones gebruikt voor de privé-eindpuntservices van uw opslagaccount, controleert u of er een virtuele netwerkkoppeling is gemaakt naar het geïntegreerde virtuele netwerk van uw logische app.
Raadpleeg De logische standaard-app implementeren in een opslagaccount achter een firewall met behulp van service- of privé-eindpunten voor meer informatie.