Risolvere i problemi e diagnosticare gli errori del flusso di lavoro nelle App per la logica di Azure
Si applica a: App per la logica di Azure (a consumo e standard)
Il flusso di lavoro dell'app per la logica genera informazioni che consentono di diagnosticare ed eseguire il debug dei problemi nell'app. È possibile diagnosticare il flusso di lavoro esaminando gli input, gli output e altre informazioni per ogni passaggio del flusso di lavoro usando il portale di Azure. In alternativa, è possibile aggiungere alcuni passaggi a un flusso di lavoro per il debug di runtime.
Controllare la cronologia dei trigger
Ogni esecuzione del flusso di lavoro inizia con un trigger, che viene attivato in base a una pianificazione o attende una richiesta o un evento in ingresso. La cronologia dei trigger elenca tutti i tentativi di trigger effettuati dal flusso di lavoro e le informazioni sugli input e sugli output per ogni tentativo di trigger. Se il trigger non viene attivato, provare i passaggi seguenti.
Per controllare lo stato del trigger nell'app per la logica a consumo, esaminare la cronologia dei trigger. Per visualizzare altre informazioni sul tentativo di trigger, selezionare l'evento trigger, ad esempio:
Controllare gli input del trigger per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia, sotto la voce Collegamento input selezionare il collegamento che mostra il riquadro Inputs.
Gli input dei trigger includono i dati previsti dal trigger e richiedono l'avvio del flusso di lavoro. La revisione di questi input consente di determinare se gli input del trigger sono corretti e se la condizione è stata soddisfatta in modo che il flusso di lavoro possa continuare.
Controllare gli output dei trigger, se presenti, per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia, sotto la voce Collegamento output selezionare il collegamento che mostra il riquadro Outputs.
Gli output dei trigger includono i dati passati dal trigger al passaggio successivo nel flusso di lavoro. La revisione di questi output consente di determinare se i valori corretti o previsti sono passati al passaggio successivo del flusso di lavoro.
Ad esempio, un messaggio di errore indica che il feed RSS non è stato trovato:
Suggerimento
Se si trovano contenuti non riconosciuti, vedere altre informazioni sui diversi tipi di contenuto in App per la logica di Azure.
Controllare la cronologia di esecuzione del flusso di lavoro
Ogni volta che il trigger viene attivato, App per la logica di Azure crea un'istanza del flusso di lavoro ed esegue tale istanza. Se un'esecuzione ha esito negativo, provare i passaggi seguenti per esaminare ciò che è successo durante l'esecuzione. È possibile esaminare lo stato, gli input e gli output per ogni passaggio del flusso di lavoro.
Per controllare lo stato di esecuzione del flusso di lavoro nell'app per la logica a consumo, esaminare la cronologia delle esecuzioni. Per visualizzare altre informazioni su un'esecuzione non riuscita, inclusi tutti i passaggi in esecuzione nello stato, selezionare l'esecuzione non riuscita.
Dopo aver visualizzato tutti i passaggi dell'esecuzione, selezionare ogni passaggio per espanderne le forme.
Esaminare gli input, gli output e gli eventuali messaggi di errore per il passaggio non riuscito.
Ad esempio, lo screenshot seguente mostra gli output dell'azione RSS non riuscita.
Eseguire il debug al runtime
Per semplificare il debug, è possibile aggiungere passaggi di diagnostica a un flusso di lavoro dell'app per la logica, oltre a esaminare la cronologia dei trigger e delle esecuzioni. Ad esempio, è possibile aggiungere passaggi che usano il servizio Tester webhook, in modo da poter esaminare le richieste HTTP e determinare le dimensioni esatte, la forma e il formato.
In un browser passare al sito Webhook Tester e copiare l'URL univoco generato.
Nell'app per la logica aggiungere un'azione HTTP POST con qualsiasi contenuto del corpo da verificare, ad esempio un'espressione o l'output di un altro passaggio.
Incollare l'URL da Webhook Tester nell'azione HTTP POST.
Per esaminare come App per la logica di Azure genera e crea una richiesta, eseguire il flusso di lavoro dell'app per la logica. Per altre informazioni, è quindi possibile rivedere il sito tester webhook.
Prestazioni : domande frequenti
Perché la durata dell'esecuzione del flusso di lavoro è superiore alla somma di tutte le durate dell'azione del flusso di lavoro?
L'overhead di pianificazione si verifica durante l'esecuzione di azioni, mentre il tempo di attesa tra le azioni può verificarsi a causa del carico del sistema back-end. Una durata dell'esecuzione del flusso di lavoro include questi tempi di pianificazione e tempi di attesa insieme alla somma di tutte le durate dell'azione.
In genere, il flusso di lavoro viene completato entro 10 secondi. Ma, a volte, il completamento può richiedere molto più tempo. Come è possibile assicurarsi che il flusso di lavoro venga sempre completato entro 10 secondi?
Non esiste alcuna garanzia di contratto di servizio sulla latenza.
I flussi di lavoro a consumo vengono eseguiti in App per la logica di Azure multi-tenant, quindi i carichi di lavoro di altri clienti potrebbero influire negativamente sulle prestazioni del flusso di lavoro.
Per prestazioni più prevedibili, è possibile prendere in considerazione la creazione di flussi di lavoro Standard, che vengono eseguiti in App per la logica di Azure a tenant singolo. Si avrà un maggiore controllo per aumentare o aumentare le prestazioni.
La mia azione scade dopo 2 minuti. Come è possibile aumentare il valore di timeout?
Il valore di timeout dell'azione non può essere modificato e viene risolto a 2 minuti. Se si usa l'azione HTTP e si è proprietari del servizio chiamato dall'azione HTTP, è possibile modificare il servizio per evitare il timeout di 2 minuti usando il modello asincrono. Per altre informazioni, vedere Eseguire attività a esecuzione prolungata con il modello di azione di polling.
Problemi comuni - App per la logica standard
Artefatti inaccessibili nell'account di archiviazione di Azure
Le app per la logica standard archiviano tutti gli artefatti in un account di archiviazione di Azure. Se questi artefatti non sono accessibili, è possibile che vengano visualizzati gli errori seguenti. Ad esempio, l'account di archiviazione stesso potrebbe non essere accessibile o l'account di archiviazione si trova dietro un firewall, ma non è configurato alcun endpoint privato per l'uso dei servizi di archiviazione.
posizione portale di Azure | Error |
---|---|
Riquadro Panoramica | - System.private.corelib:Accesso al percorso 'C:\home\site\wwwroot\hostj.son negato - Azure.Storage.Blobs: questa richiesta non è autorizzata a eseguire questa operazione |
Riquadro Flussi di lavoro | - Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (InternalServerError) dal runtime host.' - Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (ServiceUnavailable) dal runtime host'. - Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (BadGateway) dal runtime host'. |
Durante la creazione e l'esecuzione del flusso di lavoro | - Impossibile salvare il flusso di lavoro - Errore nella finestra di progettazione: GetCallFailed. Operazioni di recupero non riuscite - chiamata ajaxExtended non riuscita |
Opzioni di risoluzione dei problemi
L'elenco seguente include possibili cause di questi errori e passaggi per la risoluzione dei problemi.
Per un account di archiviazione pubblico, controllare l'accesso all'account di archiviazione nei modi seguenti:
Controllare la connettività dell'account di archiviazione usando Archiviazione di Azure Explorer.
Nelle impostazioni dell'app dell'app per la logica verificare il stringa di connessione dell'account di archiviazione nelle impostazioni dell'app, AzureWebJobsStorage e WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Per altre informazioni, vedere Impostazioni host e app per le app per la logica in App per la logica di Azure a tenant singolo.
Se la connettività non riesce, verificare se la chiave di firma di accesso condiviso (SAS) nella stringa di connessione è la più recente.
Importante
Quando si dispone di informazioni riservate, ad esempio stringa di connessione che includono nomi utente e password, assicurarsi di usare il flusso di autenticazione più sicuro disponibile. Ad esempio, nei flussi di lavoro dell'app per la logica Standard, i tipi di dati sicuri, ad esempio
securestring
esecureobject
, non sono supportati. Microsoft consiglia di autenticare l'accesso alle risorse di Azure con un'identità gestita, quando possibile, e assegnare un ruolo con privilegi minimi necessari.Se questa funzionalità non è disponibile, assicurarsi di proteggere i stringa di connessione tramite altre misure, ad esempio
Azure Key Vault, che è possibile usare con le impostazioni dell'app. È quindi possibile fare riferimento direttamente a stringhe sicure, ad esempio stringa di connessione e chiavi. Analogamente ai modelli arm, in cui è possibile definire le variabili di ambiente in fase di distribuzione, è possibile definire le impostazioni dell'app all'interno della definizione del flusso di lavoro dell'app per la logica. È quindi possibile acquisire valori di infrastruttura generati dinamicamente, ad esempio endpoint di connessione, stringhe di archiviazione e altro ancora. Per altre informazioni, vedere Tipi di applicazione per Microsoft Identity Platform.
Per un account di archiviazione protetto da un firewall, controllare l'accesso all'account di archiviazione nei modi seguenti:
Se le restrizioni del firewall sono abilitate nell'account di archiviazione, verificare se gli endpoint privati sono configurati per i servizi blob, file, tabelle e archiviazione code.
Controllare la connettività dell'account di archiviazione usando Archiviazione di Azure Explorer.
Se si riscontrano problemi di connettività, procedere con la procedura seguente:
Nella stessa rete virtuale integrata con l'app per la logica creare una macchina virtuale di Azure, che è possibile inserire in una subnet diversa.
Da un prompt dei comandi eseguire nslookup per verificare che i servizi blob, file, tabelle e archiviazione code vengano risolti negli indirizzi IP previsti.
Sintassi:
nslookup [StorageaccountHostName] [OptionalDNSServer]
BLOB:
nslookup {StorageaccountName}.blob.core.windows.net
File:
nslookup {StorageaccountName}.file.core.windows.net
Tavolo:
nslookup {StorageaccountName}.table.core.windows.net
Coda:
nslookup {StorageaccountName}.queue.core.windows.net
Se le query DNS (Domain Name Server) precedenti vengono risolte correttamente, eseguire i comandi psping o tcpping per controllare la connettività all'account di archiviazione sulla porta 443:
Sintassi:
psping [StorageaccountHostName] [Port] [OptionalDNSServer]
BLOB:
psping {StorageaccountName}.blob.core.windows.net:443
File:
psping {StorageaccountName}.file.core.windows.net:443
Tavolo:
psping {StorageaccountName}.table.core.windows.net:443
Coda:
psping {StorageaccountName}.queue.core.windows.net:443
Se ogni servizio di archiviazione è risolvibile dalla macchina virtuale di Azure, trovare il DNS usato dalla macchina virtuale per la risoluzione.
Impostare l'impostazione dell'app per la logica WEBSITE_DNS_SERVER sul DNS e verificare che il DNS funzioni correttamente.
Verificare che l'integrazione della rete virtuale sia configurata correttamente con la rete virtuale e la subnet appropriate nell'app per la logica Standard.
Se si usano zone DNS di Azure private per i servizi endpoint privati dell'account di archiviazione, verificare che sia stato creato un collegamento di rete virtuale alla rete virtuale integrata dell'app per la logica.
Per altre informazioni, vedere Distribuire un'app per la logica Standard in un account di archiviazione dietro un firewall usando endpoint privati o di servizio.