Procedure consigliate e strumenti di diagnostica per Durable Functions

Questo articolo illustra in dettaglio alcune procedure consigliate quando si usano Durable Functions. Descrive anche vari strumenti per diagnosticare i problemi durante lo sviluppo, il test e l'uso di produzione.

Procedure consigliate

Usare la versione più recente dell'estensione Durable Functions e dell'SDK

Esistono due componenti usati da un'app per le funzioni per eseguire Durable Functions. Uno è Durable Functions SDK che consente di scrivere funzioni di orchestrazione, attività ed entità usando il linguaggio di programmazione di destinazione. L'altra è l'estensione Durable, ovvero il componente di runtime che esegue effettivamente il codice. Ad eccezione delle app in-process .NET, l'SDK e l'estensione vengono versionati in modo indipendente.

Rimanere aggiornati con l'estensione e l'SDK più recenti garantisce che l'applicazione trae vantaggio dai miglioramenti, dalle funzionalità e dalle correzioni di bug più recenti. L'aggiornamento alle versioni più recenti garantisce anche che Microsoft possa raccogliere i dati di telemetria di diagnostica più recenti per accelerare il processo di indagine quando si apre un caso di supporto con Azure.

  • Per istruzioni su come ottenere la versione più recente dell'estensione, vedere Aggiornare la versione dell'estensione durable functions.
  • Per assicurarsi di usare la versione più recente dell'SDK, controllare la gestione pacchetti della lingua in uso.

Rispettare i vincoli di codice di Durable Functions

Il comportamento di riproduzione del codice dell'agente di orchestrazione crea vincoli sul tipo di codice che è possibile scrivere in una funzione dell'agente di orchestrazione. Un esempio di vincolo è che la funzione dell'agente di orchestrazione deve usare API deterministiche in modo che ogni volta che viene riprodotta, produce lo stesso risultato.

Nota

Durable Functions Roslyn Analyzer è un analizzatore di codice in tempo reale che guida gli utenti C# a rispettare vincoli di codice specifici di Durable Functions. Vedere Durable Functions Roslyn Analyzer per istruzioni su come abilitarlo in Visual Studio e Visual Studio Code.

Acquisire familiarità con le impostazioni delle prestazioni del linguaggio di programmazione Funzioni di Azure

Usando le impostazioni predefinite, il runtime del linguaggio selezionato può imporre restrizioni di concorrenza rigorose per le funzioni. Ad esempio, consentendo l'esecuzione di 1 funzione alla volta in una determinata macchina virtuale. Queste restrizioni possono in genere essere ridotte ottimizzando le impostazioni di concorrenza e prestazioni della lingua. Se si vuole ottimizzare le prestazioni dell'applicazione Durable Functions, è necessario acquisire familiarità con queste impostazioni.

Di seguito è riportato un elenco non esaustivo di alcune delle lingue che spesso traggono vantaggio dall'ottimizzazione delle prestazioni e delle impostazioni di concorrenza e dalle relative linee guida per farlo.

Garantire nomi univoci dell'hub attività per app

Più app durable function possono condividere lo stesso account di archiviazione. Per impostazione predefinita, il nome dell'app viene usato come nome dell'hub attività, che garantisce che la condivisione accidentale degli hub attività non venga eseguita. Se è necessario configurare in modo esplicito i nomi dell'hub attività per le app in host.json, è necessario assicurarsi che i nomi siano univoci. In caso contrario, le app multiple saranno in competizione per i messaggi, il che potrebbe comportare un comportamento non definito, incluse le orchestrazioni che si bloccano in modo imprevisto nello stato In sospeso o In esecuzione.

L'unica eccezione è la distribuzione di copie della stessa app in più aree. In questo caso, è possibile usare lo stesso hub attività per le copie.

Seguire le indicazioni per la distribuzione delle modifiche al codice per l'esecuzione di agenti di orchestrazione

È inevitabile che le funzioni vengano aggiunte, rimosse e modificate per tutta la durata di un'applicazione. Esempi di modifiche di rilievo comuni includono la modifica delle firme di attività o delle funzioni di entità e la modifica della logica dell'agente di orchestrazione. Queste modifiche sono un problema quando influiscono sulle orchestrazioni ancora in esecuzione. Se distribuite in modo non corretto, le modifiche al codice potrebbero causare errori di orchestrazione con un errore non deterministico, rimanere bloccati a tempo indeterminato, riduzione delle prestazioni e così via. Fare riferimento alle strategie di mitigazione consigliate quando si apportano modifiche al codice che possono influire sull'esecuzione di orchestrazioni.

Mantenere gli input e gli output della funzione il più piccolo possibile

È possibile che si verifichino problemi di memoria se si forniscono input e output di grandi dimensioni da e verso le API durable functions.

Gli input e gli output nelle API Durable Functions vengono serializzati nella cronologia dell'orchestrazione. Ciò significa che gli input e gli output di grandi dimensioni possono, nel corso del tempo, contribuire notevolmente a una cronologia dell'agente di orchestrazione in crescita, che rischia di causare eccezioni di memoria durante la riproduzione.

Per ridurre l'impatto di input e output di grandi dimensioni nelle API, è possibile scegliere di delegare alcune operazioni agli agenti di orchestrazione secondari. Ciò consente di bilanciare il carico del carico di memoria della cronologia da un singolo agente di orchestrazione a più di quelli, mantenendo quindi il footprint di memoria delle singole cronologie.

Detto questo, la procedura consigliata per gestire dati di grandi dimensioni consiste nel mantenerli nell'archiviazione esterna e materializzare solo i dati all'interno delle attività, quando necessario. Quando si usa questo approccio, invece di comunicare i dati stessi come input e/o output delle API di Funzioni permanenti, è possibile passare un identificatore leggero che consente di recuperare i dati da una risorsa di archiviazione esterna quando necessario nelle attività.

Mantenere i dati di entità di piccole dimensioni

Proprio come per gli input e gli output nelle API durable Functions, se lo stato esplicito di un'entità è troppo grande, è possibile che si verifichino problemi di memoria. In particolare, uno stato entità deve essere serializzato e de-serializzato dall'archiviazione in qualsiasi richiesta, quindi gli stati di grandi dimensioni aggiungono la latenza di serializzazione a ogni chiamata. Pertanto, se un'entità deve tenere traccia di dati di grandi dimensioni, è consigliabile eseguire l'offload dei dati nell'archiviazione esterna e tenere traccia di un identificatore leggero nell'entità che consente di materializzare i dati dall'archiviazione quando necessario.

Ottimizzare le impostazioni di concorrenza di Durable Functions

Una singola istanza del ruolo di lavoro può eseguire più elementi di lavoro simultaneamente per aumentare l'efficienza. Tuttavia, l'elaborazione di troppi elementi di lavoro rischia simultaneamente di esaurire risorse come la capacità della CPU, le connessioni di rete e così via. In molti casi, questo non dovrebbe essere un problema perché il ridimensionamento e la limitazione degli elementi di lavoro vengono gestiti automaticamente. Detto questo, se si verificano problemi di prestazioni (ad esempio gli agenti di orchestrazione che richiedono troppo tempo per il completamento, sono bloccati in sospeso e così via) o si eseguono test delle prestazioni, è possibile configurare i limiti di concorrenza nel file di host.json.

Nota

Questo non sostituisce l'ottimizzazione delle prestazioni e delle impostazioni di concorrenza del runtime del linguaggio in Funzioni di Azure. Le impostazioni di concorrenza di Durable Functions determinano solo la quantità di lavoro che può essere assegnata a una determinata macchina virtuale alla volta, ma non determina il grado di parallelismo nell'elaborazione che funziona all'interno della macchina virtuale. Quest'ultimo richiede l'ottimizzazione delle impostazioni delle prestazioni del runtime del linguaggio.

Investire nei test di stress

Come per qualsiasi risultato correlato alle prestazioni, le impostazioni di concorrenza ideali e l'architettura dell'app dipendono in definitiva dal carico di lavoro dell'applicazione. È quindi consigliabile investire in un test delle prestazioni che simula il carico di lavoro previsto e usarlo per eseguire esperimenti di prestazioni e affidabilità per l'app.

Evitare dati sensibili in input, output ed eccezioni

Gli input e gli output (incluse le eccezioni) da e verso le API durable Functions vengono mantenuti in modo permanente nel provider di archiviazione preferito. Se tali input, output o eccezioni contengono dati sensibili (ad esempio segreti, stringa di connessione, informazioni personali e così via), chiunque disponga dell'accesso in lettura alle risorse del provider di archiviazione potrà ottenerli. Per gestire in modo sicuro i dati sensibili, è consigliabile che gli utenti recuperino tali dati all'interno delle funzioni di attività da Azure Key Vault o variabili di ambiente e non comunichino mai tali dati direttamente a agenti di orchestrazione o entità. Ciò dovrebbe aiutare a impedire la perdita di dati sensibili nelle risorse di archiviazione.

Nota

Queste indicazioni si applicano anche all'API dell'agente CallHttp di orchestrazione, che rende persistenti anche i payload di richiesta e risposta nell'archiviazione. Se gli endpoint HTTP di destinazione richiedono l'autenticazione, che può essere sensibile, è consigliabile che gli utenti implementino la chiamata HTTP stessa all'interno di un'attività o per usare il supporto predefinito dell'identità gestita offerto da CallHttp, che non rende persistenti le credenziali per l'archiviazione.

Suggerimento

Analogamente, evitare di registrare i dati contenenti segreti come chiunque abbia accesso in lettura ai log (ad esempio in Application Insights), sarà in grado di ottenere tali segreti.

Strumenti di diagnostica

Sono disponibili diversi strumenti per diagnosticare i problemi.

Durable Functions e Durable Task Framework Logs

Estensione Durable Functions

L'estensione Durable genera eventi di rilevamento che consentono di tracciare l'esecuzione end-to-end di un'orchestrazione. Questi eventi di rilevamento sono disponibili e sottoposti a query usando lo strumento Di analisi di Application Insights nel portale di Azure. La verbosità dei dati di rilevamento generati può essere configurata nella logger sezione (Funzioni 1.x) o logging (Funzioni 2.0) del file host.json. Vedere i dettagli di configurazione.

Durable Task Framework

A partire dalla versione 2.3.0 dell'estensione Durable, per la raccolta sono disponibili anche i log generati da Durable Task Framework (DTFx) sottostante. Vedere i dettagli su come abilitare questi log.

Azure portal

Diagnostica e risoluzione dei problemi

Diagnostica app per le funzioni di Azure è una risorsa utile in portale di Azure per il monitoraggio e la diagnosi di potenziali problemi nell'applicazione. Fornisce anche suggerimenti per risolvere i problemi in base alla diagnosi. Vedere Diagnostica dell'app per le funzioni di Azure.

Tracce di orchestrazione di Durable Functions

portale di Azure fornisce dettagli di traccia dell'orchestrazione per comprendere lo stato di ogni istanza di orchestrazione e tracciare l'esecuzione end-to-end. Quando si esamina l'elenco delle funzioni all'interno dell'app Funzioni di Azure, verrà visualizzata una colonna Monitoraggio che contiene collegamenti alle tracce. Per ottenere queste informazioni, è necessario che Applications Insights sia abilitato per l'app.

Estensione di Durable Functions Monitor

Si tratta di un'estensione di Visual Studio Code che fornisce un'interfaccia utente per il monitoraggio, la gestione e il debug delle istanze di orchestrazione.

Analizzatore Roslyn

Durable Functions Roslyn Analyzer è un analizzatore di codice in tempo reale che guida gli utenti C# a rispettare vincoli di codice specifici di Durable Functions. Vedere Durable Functions Roslyn Analyzer per istruzioni su come abilitarlo in Visual Studio e Visual Studio Code.

Supporto tecnico

Per domande e supporto, è possibile aprire un problema in uno dei repository GitHub seguenti. Quando si segnala un bug in Azure, incluse informazioni come gli ID istanza interessati, gli intervalli di tempo in formato UTC che mostrano il problema, il nome dell'applicazione (se possibile) e l'area di distribuzione velocizzano notevolmente le indagini.