Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Risoluzione dei problemi in Lambda Negli argomenti seguenti vengono forniti suggerimenti per la risoluzione dei problemi relativi a errori e problemi che potrebbero verificarsi durante l'utilizzo della console, degli strumenti o dell'API Lambda. Se scopri un problema che non è elencato qui di seguito, puoi utilizzare il pulsante **Feedback** in questa pagina per segnalarlo. Per ulteriori suggerimenti sulla risoluzione dei problemi e per risposte a domande comuni relative al supporto, visitare il [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Per ulteriori informazioni sul debug e la risoluzione dei problemi delle applicazioni Lambda, consulta [Debug](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) in Serverless Land. **Topics** + [Risoluzione dei problemi relativi alle configurazioni in Lambda](troubleshooting-configuration.md) + [Risoluzione dei problemi relativi alle implementazioni in Lambda](troubleshooting-deployment.md) + [Risoluzione dei problemi di invocazione in Lambda](troubleshooting-invocation.md) + [Risoluzione dei problemi di esecuzione in Lambda](troubleshooting-execution.md) + [Risolvi i problemi di mappatura delle sorgenti degli eventi in Lambda](troubleshooting-event-source-mapping.md) + [Risoluzione dei problemi di rete in Lambda](troubleshooting-networking.md) # Risoluzione dei problemi relativi alle configurazioni in Lambda Le impostazioni di configurazione delle funzioni possono avere un impatto sulle prestazioni e sul comportamento complessivi della funzione Lambda. Queste potrebbero non causare errori di funzionamento effettivi, ma possono causare timeout e risultati imprevisti. Negli argomenti seguenti vengono forniti suggerimenti per la risoluzione dei problemi relativi a problemi comuni che potrebbero verificarsi relativi alle impostazioni di configurazione delle funzioni Lambda. **Topics** + [Configurazioni della memoria](#memory-config) + [Configurazioni collegate alla CPU](#cpu-bound-config) + [Timeout](#timeouts) + [Perdita di memoria tra invocazioni](#memory-leakage) + [Risultati asincroni restituiti a una invocazione successiva](#asynchronous-results) ## Configurazioni della memoria È possibile configurare una funzione Lambda per utilizzare quantità compresa tra 128 MB e 10.240 MB. Per impostazione predefinita, a qualsiasi funzione creata nella console viene assegnata la quantità di memoria minima. Molte funzioni Lambda offrono prestazioni ottimali con questa impostazione minima. Tuttavia, se si importano librerie di codici di grandi dimensioni o si completano attività che richiedono molta memoria, 128 MB non sono sufficienti. Se le funzioni funzionano molto più lentamente del previsto, il primo passaggio consiste nell'aumentare l'impostazione della memoria. Per le funzioni collegate alla memoria, ciò risolve il collo di bottiglia e può migliorare le prestazioni della tua funzione. ## Configurazioni collegate alla CPU Per le operazioni a elaborazione intensiva, se le prestazioni della funzione Lambda sono più lente del previsto, ciò potrebbe essere dovuto al fatto che la funzione è vincolata alla CPU. In questo caso, la capacità di calcolo della funzione non può tenere il passo con il lavoro. Sebbene Lambda non consenta di modificare direttamente la configurazione della CPU, la CPU viene controllata indirettamente tramite le impostazioni della memoria. Il servizio Lambda alloca proporzionalmente più CPU virtuale man mano che si alloca più memoria. Con 1,8 GB di memoria, una funzione Lambda ha un'intera vCPU allocata e, al di sopra di questo livello, ha accesso a più di un core vCPU. Con 10.240 MB, ha 6 vCPU disponibili. In questi casi, è possibile migliorare le prestazioni aumentando l'allocazione di memoria, anche se la funzione non utilizza tutta la memoria. ## Timeout I [timeout](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) per le funzioni Lambda possono essere impostati tra 1 e 900 secondi (15 minuti). Per impostazione predefinita, la console Lambda imposta questo valore su 3 secondi. Il valore di timeout è una valvola di sicurezza che garantisce che le funzioni non funzionino all'infinito. Una volta raggiunto il valore di timeout, Lambda interrompe la chiamata della funzione. Se un valore di timeout viene impostato vicino alla durata media di una funzione, aumenta il rischio che la funzione scada inaspettatamente. La durata di una funzione può variare in base alla quantità di trasferimento ed elaborazione dei dati e alla latenza dei servizi con cui interagisce la funzione. Alcune cause comuni di timeout includono: + Quando si scaricano dati da bucket S3 o altri archivi di dati, il download è più grande o richiede più tempo della media. + Una funzione invia una richiesta a un altro servizio, che impiega più tempo a rispondere. + I parametri forniti a una funzione richiedono una maggiore complessità computazionale della funzione, il che fa sì che l'invocazione richieda più tempo. Nel testare l'applicazione, assicurati che i test riflettano accuratamente la dimensione e la quantità di dati e valori realistici dei parametri. È importante sottolineare che utilizza set di dati al limite massimo di quanto ragionevolmente previsto per il carico di lavoro. Laddove possibile, implementa limiti massimi nel tuo carico di lavoro. In questo esempio, l'applicazione potrebbe utilizzare un limite di dimensione massima per ogni tipo di file. È quindi possibile testare le prestazioni dell'applicazione per una gamma di dimensioni di file previste, fino ai limiti massimi inclusi. ## Perdita di memoria tra invocazioni Le variabili e gli oggetti globali memorizzati nella fase INIT di una invocazione Lambda mantengono il loro stato tra le invocazioni a caldo. Vengono ripristinate completamente solo quando l'ambiente di esecuzione viene eseguito per la prima volta (noto anche come "avvio a freddo"). Tutte le variabili memorizzate nell'handler vengono distrutte quando l'handler viene terminato. È consigliabile utilizzare la fase INIT per configurare connessioni al database, caricare librerie, creare cache e caricare risorse immutabili. Quando utilizzi librerie di terze parti per più invocazioni nello stesso ambiente di esecuzione, assicurati di consultare la relativa documentazione per l'utilizzo in un ambiente di elaborazione serverless. Alcune librerie di connessione e registrazione al database possono salvare risultati di invocazione intermedi e altri dati. Ciò fa sì che l'utilizzo della memoria di queste librerie aumenti con le successive invocazioni a caldo. Nei casi in cui la memoria cresce rapidamente, è possibile che la funzione Lambda esaurisca la memoria, anche se il codice personalizzato elimina le variabili correttamente. Questo problema riguarda le invocazioni che si verificano in ambienti di esecuzione a caldo. Ad esempio, il seguente codice crea una perdita di memoria tra le invocazioni. La funzione Lambda consuma memoria aggiuntiva ad ogni invocazione aumentando le dimensioni di un array globale: ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` Configurata con 128 MB di memoria, dopo aver richiamato questa funzione 1.000 volte, la scheda Monitoraggio della funzione Lambda mostra le tipiche modifiche nelle invocazioni, nella durata e nel conteggio degli errori quando si verifica una perdita di memoria: ![\[operazioni di debug (figura 4)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **Invocazioni**: un tasso di transazione costante viene interrotto periodicamente man mano che le invocazioni impiegano più tempo per essere completate. Durante lo stato stazionario, la perdita di memoria non consuma tutta la memoria allocata alla funzione. Man mano che le prestazioni peggiorano, il sistema operativo utilizza la memoria locale per adattarla alla crescente quantità di memoria richiesta dalla funzione, il che comporta un minor numero di transazioni completate. 1. **Durata**: prima che la funzione esaurisca la memoria, termina le invocazioni a una velocità costante di due millisecondi. Man mano che si verifica la paginazione, la durata aumenta di un ordine di grandezza. 1. **Numero di errori**: quando la perdita di memoria supera la memoria allocata, alla fine la funzione subisce errori dovuti al superamento del timeout di calcolo o l'ambiente di esecuzione arresta la funzione. Dopo l'errore, il servizio Lambda riavvia l'ambiente di esecuzione, il che spiega perché in tutti e tre i grafici i parametri tornano allo stato originale. L'espansione dei parametri di CloudWatch per la durata fornisce maggiori dettagli per le statistiche sulla durata minima, massima e media: ![\[operazioni di debug (figura 5)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-5.png) Per trovare gli errori generati nelle 1.000 invocazioni, puoi utilizzare il linguaggio di query di CloudWatch Insights. La seguente query esclude i log informativi per riportare solo gli errori: ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` Se eseguita sul gruppo di log per questa funzione, ciò dimostra che i timeout erano responsabili degli errori periodici: ![\[operazioni di debug (figura 6)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-6.png) ## Risultati asincroni restituiti a una invocazione successiva Per il codice di funzione che utilizza modelli asincroni, è possibile che i risultati di callback di una invocazione vengano restituiti in una invocazione futura. Questo esempio utilizza Node.js ma la stessa logica può essere applicata ad altri runtime utilizzando modelli asincroni. La funzione utilizza la tradizionale sintassi di callback in JavaScript. Richiama una funzione asincrona con un contatore incrementale che tiene traccia del numero di invocazioni: ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` Quando vengono richiamati più volte in successione, i risultati dei callback si verificano nelle invocazioni successive: ![\[operazioni di debug (figura 7)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. Il codice richiama la funzione doWork, fornendo una funzione di callback come ultimo parametro. 1. Il completamento della funzione doWork richiede un certo periodo di tempo prima di richiamare il callback. 1. La registrazione della funzione indica che la chiamata termina prima che la funzione DoWork termini l'esecuzione. Inoltre, dopo l'avvio di un'iterazione, vengono elaborati i callback delle iterazioni precedenti, come mostrato nei log. In JavaScript, i callback asincroni vengono gestiti con un [ciclo di eventi](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop). Altri runtime utilizzano meccanismi diversi per gestire la simultaneità. Quando l'ambiente di esecuzione della funzione termina, il servizio Lambda blocca l'ambiente fino all'invocazione successiva. Dopo la ripresa, JavaScript continua a elaborare il ciclo di eventi, che in questo caso include un callback asincrono da una invocazione precedente. Senza questo contesto, può sembrare che la funzione esegua codice senza motivo e restituisca dati arbitrari. In effetti, è davvero un artefatto del modo in cui la simultaneità di runtime e gli ambienti di esecuzione interagiscono. Ciò crea la possibilità che i dati privati di una invocazione precedente vengano visualizzati in una invocazione successiva. Esistono due modi per prevenire o rilevare questo comportamento. Innanzitutto, JavaScript fornisce le [parole chiave async e await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) per semplificare lo sviluppo asincrono e inoltre forza l'esecuzione del codice ad attendere il completamento di una chiamata asincrona. La funzione precedente può essere riscritta utilizzando questo approccio nel modo seguente: ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` L'utilizzo di questa sintassi impedisce all'handler di uscire prima che la funzione asincrona sia terminata. In questo caso, se il callback impiega più tempo del timeout della funzione Lambda, la funzione genererà un errore invece di restituire il risultato del callback in una invocazione successiva: ![\[operazioni di debug (figura 8)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. Il codice richiama la funzione doWork asincrona utilizzando la parola chiave await nell'handler. 1. Il completamento della funzione doWork richiede un certo periodo di tempo prima di risolvere la promessa. 1. La funzione scade perché doWork impiega più tempo del limite di timeout consentito e il risultato del callback non viene restituito in una invocazione successiva. Di solito, è necessario accertarsi che tutti i processi in background e le callback nel codice vengano completate prima che il codice sia terminato. Se ciò non è possibile nel tuo caso d'uso, puoi utilizzare un identificatore per assicurarti che il callback appartenga all'invocazione corrente. A tale scopo, è possibile utilizzare l'*awsRequestId* fornito dall'oggetto del contesto. Passando questo valore al callback asincrono, è possibile confrontare il valore passato con il valore corrente per rilevare se il callback ha avuto origine da un'altra invocazione: ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[operazioni di debug (figura 9)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. L'handler della funzione Lambda accetta il parametro context, che fornisce l'accesso a un ID di richiesta di invocazione univoco. 1. awsRequestId viene passato alla funzione doWork. Nel callback, l'ID viene confrontato con l'awsRequestId dell'invocazione corrente. Se questi valori sono diversi, il codice può agire di conseguenza. # Risoluzione dei problemi relativi alle implementazioni in Lambda Quando si aggiorna la funzione, Lambda distribuisce la modifica avviando nuove istanze della funzione con il codice o le impostazioni aggiornati. Gli errori di distribuzione impediscono l'utilizzo della nuova versione e possono derivare da problemi relativi al pacchetto di distribuzione, al codice, alle autorizzazioni o agli strumenti. Quando distribuisci gli aggiornamenti alla tua funzione direttamente con l'API Lambda o con un client come AWS CLI il, puoi vedere gli errori di Lambda direttamente nell'output. Se utilizzi servizi come AWS CloudFormation, o AWS CodeDeploy AWS CodePipeline, cerca la risposta di Lambda nei log o nel flusso di eventi per quel servizio. Negli argomenti seguenti vengono forniti suggerimenti per la risoluzione dei problemi relativi a errori e problemi che potrebbero verificarsi durante l'utilizzo della console, degli strumenti o dell'API Lambda. Se scopri un problema che non è elencato qui di seguito, puoi utilizzare il pulsante **Feedback** in questa pagina per segnalarlo. Per ulteriori suggerimenti sulla risoluzione dei problemi e per risposte a domande comuni relative al supporto, visitare il [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Per ulteriori informazioni sul debug e la risoluzione dei problemi delle applicazioni Lambda, consulta [Debug](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) in Serverless Land. **Topics** + [Generale: autorizzazione negata/Impossibile caricare tale file](#troubleshooting-deployment-denied) + [Generale: si verifica un errore quando si chiama il UpdateFunctionCode](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3: codice di errore. PermanentRedirect](#troubleshooting-deployment-PermanentRedirect) + [Generale: impossibile trovare, impossibile caricare, impossibile importare, classe non trovata, file o directory non trovati](#troubleshooting-deployment-functionHandler1) + [Generale: handler di metodi non definito](#troubleshooting-deployment-functionHandler2) + [Generale: il limite di memorizzazione del codice Lambda è stato superato](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda: conversione dei livelli non riuscita](#troubleshooting-deployment-LayerConversionFailed) + [Lambda: o InvalidParameterValueException RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda: quote di simultaneità e memoria](#troubleshooting-deployment-quotas) + [Lambda: configurazione alias non valida per la concorrenza fornita](#troubleshooting-deployment-provisioned-concurrency) ## Generale: autorizzazione negata/Impossibile caricare tale file **Errore: EACCES:** *autorizzazione negata*, apri '/ .js' var/task/index **Errore:** *cannot load such file -- function (impossibile caricare tale file - funzione)* **Errore:** *[Errno 13*] Autorizzazione negata: '/ .py' var/task/function Il runtime Lambda necessita dell'autorizzazione per leggere i file nel pacchetto di distribuzione. Nella notazione ottale delle autorizzazioni Linux, Lambda richiede 644 permessi per i file non eseguibili (rw-r--r--) e 755 permessi () per le directory e i file eseguibili. rwxr-xr-x In Linux e macOS, utilizza il comando `chmod` per modificare le autorizzazioni file su file e directory nel pacchetto di implementazione. Ad esempio, per assegnare a un file non eseguibile le autorizzazioni corrette, utilizza il comando seguente. ``` chmod 644 ``` Per modificare le autorizzazioni file in Windows, consulta [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) nella documentazione di Microsoft Windows. **Nota** Se non concedi a Lambda le autorizzazioni necessarie per accedere alle directory nel pacchetto di distribuzione, Lambda imposta le autorizzazioni per tali directory su 755 (). rwxr-xr-x ## Generale: si verifica un errore quando si chiama il UpdateFunctionCode **Errore:** *si è verificato un errore (RequestEntityTooLargeException) durante la chiamata dell' UpdateFunctionCode operazione* Quando carichi un pacchetto di distribuzione o un archivio di livelli direttamente in Lambda, la dimensione del file ZIP è limitata a 50 MB. Per caricare un file di dimensioni maggiori, archivialo in Amazon S3 e utilizza i parametri S3Bucket e S3Key. **Nota** Quando caricate un file direttamente con AWS SDK o in altro modo AWS CLI, il file ZIP binario viene convertito in base64, il che ne aumenta le dimensioni di circa il 30%. Per consentire questa operazione e la dimensione di altri parametri nella richiesta, il limite effettivo della dimensione della richiesta Lambda applicabile è maggiore. Per questo motivo, il limite di 50 MB è approssimativo. ## Amazon S3: codice di errore. PermanentRedirect **Errore:** *si è verificato un errore durante GetObject. Codice di errore S3: PermanentRedirect. Messaggio di errore S3: il bucket si trova in questa regione: us-east-2. Utilizza questa regione per riprovare la richiesta* Quando carichi il pacchetto di distribuzione di una funzione da un bucket Amazon S3, il bucket deve trovarsi nella stessa regione della funzione. Questo problema può verificarsi quando specifichi un oggetto Amazon S3 in una chiamata o utilizzi il pacchetto e distribuisci i comandi nella o AWS CLI CLI. [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) AWS SAM Crea un bucket artefatto di distribuzione per ogni regione in cui sviluppi applicazioni. ## Generale: impossibile trovare, impossibile caricare, impossibile importare, classe non trovata, file o directory non trovati **Errore:** *impossibile trovare il modulo "function"* **Errore:** *cannot load such file -- function (impossibile caricare tale file - funzione)* **Errore:** *impossibile importare il modulo "function"* **Errore:** *classe non trovata: Function.Handler* **Errorefork/exec /var/task/function:** *nessun file o directory di questo tipo* **Errore:** *impossibile caricare il tipo "Function.Handler" dal gruppo "Function".* Il nome del file o della classe nella configurazione dell'handler della funzione non corrisponde al codice. Per ulteriori informazioni, consulta la sezione seguente. ## Generale: handler di metodi non definito **Errore:** *index.handler non è definito o non esportato* **Errore:** *Handler "handler" mancante sul modulo "function"* **Errore:** *metodo `handler' non definito* per \$1<:0x000055b76ccebf98> LambdaHandler **Errore:** *Nessun metodo pubblico denominato HandleRequest con firma del metodo appropriata trovato sulla classe function.Handler* **Errore:** *impossibile trovare il metodo "HandleRequest" nel tipo "Function.Handler" dal gruppo "Function"* Il nome del metodo dell'handler nella configurazione dell'handler della funzione non corrisponde al codice. Ogni runtime definisce una convenzione di denominazione per i gestori, ad esempio. *filename* *methodname*. L'handler è il metodo nel codice della funzione che il runtime esegue quando viene invocata la funzione. Per alcune lingue, Lambda fornisce una libreria con un'interfaccia che prevede un metodo handler per avere un nome specifico. Per informazioni dettagliate sulla denominazione dell'handler per ogni lingua, consulta i seguenti argomenti. + [Compilazione di funzioni Lambda con Node.js](lambda-nodejs.md) + [Compilazione di funzioni Lambda con Python](lambda-python.md) + [Compilazione di funzioni Lambda con Ruby](lambda-ruby.md) + [Compilazione di funzioni Lambda con Java](lambda-java.md) + [Compilazione di funzioni Lambda con Go](lambda-golang.md) + [Compilazione di funzioni Lambda con C\$1](lambda-csharp.md) + [Creazione di funzioni Lambda con PowerShell](lambda-powershell.md) ## Generale: il limite di memorizzazione del codice Lambda è stato superato **Errore:** *limite di archiviazione del codice superato*. Lambda archivia il codice della funzione in un bucket S3 interno riservato al tuo account. A ogni AWS account vengono assegnati 75 GB di spazio di archiviazione in ogni regione. Lo spazio di archiviazione del codice include lo spazio di archiviazione totale utilizzato sia dalle funzioni che dai livelli Lambda. Se raggiungi la quota, ricevi un messaggio *CodeStorageExceededException*quando tenti di implementare nuove funzioni. Gestisci lo spazio di archiviazione disponibile ripulendo le vecchie versioni delle funzioni, rimuovendo il codice inutilizzato o utilizzando i livelli Lambda. Inoltre, è buona norma [utilizzare AWS account separati per carichi di lavoro separati per](concepts-application-design.md#multiple-accounts) facilitare la gestione delle quote di archiviazione. Puoi visualizzare l'utilizzo totale dello storage nella console Lambda, nel sottomenu **Dashboard**: ![\[monitoraggio dell'osservabilità (figura 26)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda: conversione dei livelli non riuscita **Errore:** *conversione dei livelli Lambda non riuscita. Per consigli sulla risoluzione di questo problema, consulta la pagina Risoluzione dei problemi di implementazione in Lambda nella Guida per l'utente di Lambda.* Quando si configura una funzione Lambda con un livello, Lambda unisce il livello con il codice della funzione. Se questo processo non viene completato, Lambda restituisce questo errore. Se lo fa, procedere come indicato di seguito: + Eliminare tutti i file inutilizzati dal livello + Eliminare tutti i collegamenti simbolici nel tuo livello + Rinominare tutti i file che hanno lo stesso nome di una directory in uno qualsiasi dei livelli della funzione ## Lambda: o InvalidParameterValueException RequestEntityTooLargeException **Errore:InvalidParameterValueException:** *Lambda non è riuscita a configurare le variabili di ambiente perché le variabili di ambiente fornite hanno superato il limite di 4 KB. Stringa misurata: \$1"A1":" u Y5 7ATNx5bsm... SFe cyPiPn* **ErroreRequestEntityTooLargeException:** *la richiesta* deve essere inferiore a 5120 byte per l'operazione UpdateFunctionConfiguration La dimensione massima dell'oggetto variabili memorizzato nella configurazione della funzione non deve superare 4096 byte. Sono inclusi nomi chiave, valori, virgolette, virgole e parentesi. Anche la dimensione totale del corpo della richiesta HTTP è limitata. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` In questo esempio, l'oggetto è di 39 caratteri e quando archiviato occupa 39 byte (senza spazi) come stringa `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`. I caratteri ASCII standard nei valori delle variabili di ambiente utilizzano un byte ciascuno. I caratteri ASCII e Unicode estesi possono utilizzare tra 2 e 4 byte per carattere. ## Lambda: InvalidParameterValueException **Errore:InvalidParameterValueException:** *Lambda non è riuscita a configurare le variabili di ambiente perché le variabili di ambiente che hai fornito contengono chiavi riservate che attualmente non sono supportate per la modifica*. Lambda riserva alcune chiavi di variabili di ambiente per uso interno. Ad esempio, `AWS_REGION` viene utilizzata dal runtime per determinare la regione corrente e non può essere sovrascritta. Altre variabili, come `PATH`, sono utilizzate dal runtime ma possono essere estese nella configurazione della funzione. Per un elenco completo, consultare [Variabili di ambiente di runtime definite](configuration-envvars.md#configuration-envvars-runtime). ## Lambda: quote di simultaneità e memoria **Errore:** la funzione *specificata ConcurrentExecutions per la funzione riduce il numero di account al di UnreservedConcurrentExecution sotto del valore minimo* **Errore:** il *valore MemorySize '' non è riuscito a soddisfare il vincolo: il membro deve avere un valore inferiore o uguale* a 3008 Questi errori si verificano quando superi le [quote](gettingstarted-limits.md) di simultaneità o memoria per il tuo account. AWS I nuovi account hanno quote di concorrenza e memoria ridotte. Per risolvere gli errori relativi alla simultaneità, puoi [richiedere un aumento della quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). Non è possibile richiedere un aumento della quota. + **Simultaneità:** se provi a creare una funzione utilizzando la simultaneità riservata o con provisioning o se la tua richiesta di simultaneità per funzione ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) supera la quota di simultaneità del tuo account potresti ricevere un errore. + **Memoria:** se la quantità di memoria allocata per la funzione supera la quota di memoria dell'account si verificano degli errori. ## Lambda: configurazione alias non valida per la concorrenza fornita **Errore: configurazione degli alias** *non valida* per la concorrenza fornita Questo errore si verifica quando si tenta di aggiornare il codice o la configurazione di una funzione Lambda mentre un alias con concorrenza assegnata indica una versione con problemi. Lambda preinizializza gli ambienti di esecuzione per la concorrenza preimpostata e, se questi ambienti non possono essere inizializzati correttamente a causa di errori di codice, vincoli di risorse o stack e alias interessati, l'implementazione fallisce. Se riscontri questo problema, procedi nel seguente modo: 1. **Ripristina l'alias:** aggiorna temporaneamente l'alias in modo che punti alla versione funzionante in precedenza. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Correggi il codice di inizializzazione Lambda:** assicurati che il codice di inizializzazione eseguito all'esterno del gestore non contenga eccezioni non rilevate e inizializza i client e le connessioni. 1. **Reimplementa la sicurezza: implementa il codice** fisso e pubblica una nuova versione. Quindi, aggiorna l'alias in modo che punti alla versione fissa. Facoltativamente, riattiva la concorrenza [fornita, se necessario](provisioned-concurrency.md). Se lo utilizzi AWS CloudFormation, aggiorna la definizione dello stack `FunctionVersion:!GetAtt version.Version` in modo che l'alias punti alla versione funzionante: ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Risoluzione dei problemi di invocazione in Lambda Quando si richiama una funzione Lambda, Lambda convalida la richiesta e verifica la capacità di ridimensionamento prima di inviare l'evento alla funzione o, per la invocazione asincrona, alla coda eventi. Gli errori di invocazione possono essere causati da problemi relativi ai parametri di richiesta, alla struttura degli eventi, alle impostazioni delle funzioni, alle autorizzazioni utente, alle autorizzazioni delle risorse o alle restrizioni. Se invochi direttamente la funzione, visualizzi eventuali errori di invocazione nella risposta da Lambda. Se si richiama la funzione in modo asincrono, con un mapping di origine eventi o tramite un altro servizio, è possibile che vengano riscontrati errori nei log, nella coda DLQ o in una destinazione in caso di errore. Le opzioni di gestione degli errori e il comportamento dei tentativi variano a seconda di come si richiama la funzione e del tipo di errore. Per un elenco di tipi di errore che l'operazione `Invoke` può restituire, consulta [Invoke (Invoca)](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). **Topics** + [Lambda: timeout della funzione durante la fase di inizializzazione (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM: lambda: InvokeFunction non autorizzato](#troubleshooting-invocation-noauth) + [Lambda: impossibile trovare un bootstrap (Runtime) valido. InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda: l'operazione non può essere eseguita ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda: la funzione è bloccata in sospeso](#troubleshooting-invocation-pending) + [Lambda: una funzione sta usando tutta la simultaneità](#troubleshooting-invocation-allconcurrency) + [Generale: impossibile richiamare la funzione con altri account o servizi](#troubleshooting-invocation-cannotinvoke) + [Generale: il richiamo della funzione è in loop](#troubleshooting-invocation-loop) + [Lambda: routing alias con simultaneità fornita](#troubleshooting-invocation-alias) + [Lambda: avvii a freddo con simultaneità fornita](#troubleshooting-invocation-coldstart) + [Lambda: avvii a freddo con nuove versioni](#troubleshooting-invocation-newversion) + [Lambda: uscita imprevista di Node.js in fase di esecuzione (Runtime). NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS: la funzione non è in grado di montare il file system EFS](#troubleshooting-invocation-efsmount) + [EFS: la funzione non è in grado di connettersi al file system EFS](#troubleshooting-invocation-efsconnect) + [EFS: la funzione non è in grado di montare il file system EFS a causa del timeout](#troubleshooting-invocation-efstimeout) + [Lambda: Lambda ha rilevato un processo IO che stava impiegando troppo tempo](#troubleshooting-invocation-ioprocess) + [Contenitore: errori CodeArtifactUserException](#troubleshooting-deployment-container-artifact) + [Contenitore: InvalidEntrypoint errori](#troubleshooting-deployment-container-entrypoint) ## Lambda: timeout della funzione durante la fase di inizializzazione (Sandbox.Timedout) **Errore:** *Timeout dell'attività dopo 3 secondi* Quando la fase [Init](lambda-runtime-environment.md#runtimes-lifecycle-ib) scade, Lambda inizializza nuovamente l'ambiente di esecuzione rieseguendo la fase `Init` all'arrivo della successiva richiesta di invocazione. Questa operazione è chiamata [inizializzazione soppressa](lambda-runtime-environment.md#suppressed-init). Tuttavia, se la funzione è configurata con una [durata di timeout](configuration-timeout.md) breve (in genere circa 3 secondi), l'init soppresso potrebbe non essere completato durante il periodo di timeout assegnato, causando un nuovo timeout della fase `Init`. In alternativa, l'init soppresso viene completato ma non lascia abbastanza tempo per il completamento della fase [Invoke](lambda-runtime-environment.md#runtimes-lifecycle-invoke), causando il timeout della fase `Invoke`. Per ridurre gli errori di timeout, utilizza una delle seguenti strategie: + **Aumenta la durata del timeout della funzione**: estendi il [timeout](configuration-timeout.md) per dare più tempo per il completamento delle fasi `Init` e `Invoke`. + **Aumenta l'allocazione della memoria della funzione**: una maggiore [quantità di memoria](configuration-memory.md) significa anche una maggiore allocazione proporzionale della CPU, che può velocizzare entrambe le fasi `Init` e `Invoke`. + **Ottimizza il codice di inizializzazione della funzione**: riduci il tempo necessario per l'inizializzazione per garantire che le fasi `Init` e `Invoke` possano essere completate entro il timeout configurato. ## IAM: lambda: InvokeFunction non autorizzato **Errore: User:** *arn:aws:iam: :123456789012:user/developer non è autorizzato a eseguire:* lambda: on resource: my-function InvokeFunction L'utente, o il ruolo che assumi, deve disporre dell'autorizzazione per invocare una funzione. Questo requisito si applica anche alle funzioni Lambda e ad altre risorse di calcolo che richiamano funzioni. Aggiungi il **AWSLambdaruolo della policy AWS gestita al tuo utente o aggiungi una politica personalizzata che consenta** l'azione sulla funzione di destinazione. `lambda:InvokeFunction` **Nota** Il nome dell'azione IAM (`lambda:InvokeFunction`) si riferisce all'operazione dell'API di Lambda `Invoke`. Per ulteriori informazioni, consulta [Gestione delle autorizzazioni in AWS Lambda](lambda-permissions.md). ## Lambda: impossibile trovare un bootstrap (Runtime) valido. InvalidEntrypoint) **Errore:** *impossibile trovare bootstrap validi: [/var/task/bootstrap /opt/bootstrap]* Questo errore si verifica in genere quando la root del pacchetto di implementazione non contiene un file eseguibile denominato `bootstrap`. Ad esempio, se desideri implementare una funzione `provided.al2023` con un file .zip, il file `bootstrap` deve trovarsi nella root del file .zip, non in una directory. ## Lambda: l'operazione non può essere eseguita ResourceConflictException **ErroreResourceConflictException:** *l'operazione non può essere eseguita in questo momento. La funzione è attualmente nello stato seguente: Pending (In sospeso)* Quando si connette una funzione a un VPC al momento della creazione, la funzione entra in uno stato `Pending` mentre Lambda crea le interfacce di rete elastica. Durante questo periodo, non è possibile richiamare o modificare la funzione. Se si connette la funzione a un VPC dopo la creazione, è possibile richiamarla mentre l'aggiornamento è in sospeso, ma non è possibile modificarne il codice o la configurazione. Per ulteriori informazioni, consulta [Stati funzione Lambda](functions-states.md). ## Lambda: la funzione è bloccata in sospeso **Errore:** *una funzione è bloccata nello stato `Pending` per diversi minuti.* Se una funzione è bloccata nello stato `Pending` per più di sei minuti, invoca una delle seguenti operazioni API per sbloccarla. + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda annulla l'operazione in sospeso e imposta la funzione allo stato `Failed`. Puoi tentare, quindi, un altro aggiornamento. ## Lambda: una funzione sta usando tutta la simultaneità **Problema:** *una funzione utilizza tutta la simultaneità disponibile, causando la limitazione di altre funzioni.* Per dividere la concorrenza disponibile del tuo AWS account in una AWS regione in pool, utilizza la [concorrenza riservata](configuration-concurrency.md). La simultaneità riservata garantisce che una funzione possa sempre scalare alla relativa simultaneità assegnata e che non scalerà oltre la simultaneità assegnata. ## Generale: impossibile richiamare la funzione con altri account o servizi **Problema:** *è possibile invocare la funzione direttamente, ma questa non viene eseguita quando un altro servizio o account la invoca.* Puoi concedere [ad altri servizi](lambda-services.md) e account l'autorizzazione a invocare una funzione nella [policy basata sulle risorse](access-control-resource-based.md) della funzione. Se l'invoker si trova in un altro account, tale utente deve anche disporre dell'[autorizzazione per invocare le funzioni](access-control-identity-based.md). ## Generale: il richiamo della funzione è in loop **Problema:** *la funzione viene richiamata continuamente in un loop.* Ciò si verifica in genere quando la funzione gestisce le risorse nello stesso AWS servizio che la attiva. Ad esempio, è possibile creare una funzione che memorizza un oggetto in un bucket Amazon Simple Storage Service (Amazon S3) configurato con una [notifica che richiama nuovamente la funzione](with-s3.md). Per interrompere l'esecuzione della funzione, riduci la [simultaneità](lambda-concurrency.md) a zero, il che limita tutte le invocazioni future. Quindi identificare il percorso del codice o l'errore di configurazione che ha causato la chiamata ricorsiva. Lambda rileva e interrompe automaticamente i loop ricorsivi per alcuni servizi e. AWS SDKs Per ulteriori informazioni, consulta [Usa il rilevamento di un ciclo ricorsivo Lambda per prevenire loop infiniti](invocation-recursion.md). ## Lambda: routing alias con simultaneità fornita **Problema:** *invocazioni spillover di concorrenza con provisioning durante il routing degli alias.* Lambda utilizza un modello probabilistico semplice per distribuire il traffico tra le due versioni delle funzioni. A livelli di traffico bassi, è possibile che si verifichi una variazione elevata tra la percentuale di traffico configurata e quella effettiva in ciascuna versione. Se la tua funzione utilizza la concorrenza con provisioning, puoi evitare [invocazioni spillover](monitoring-metrics-types.md#invocation-metrics) configurando un numero maggiore di istanze di concorrenza sottoposte a provisioning durante il periodo in cui il routing degli alias è attivo. ## Lambda: avvii a freddo con simultaneità fornita **Problema:** *si verificano avvii a freddo dopo che è stata abilitata la simultaneità fornita.* Quando il numero di esecuzioni simultanee su una funzione è minore o uguale al [livello configurato di simultaneità fornita](provisioned-concurrency.md), non dovrebbero verificarsi avvii a freddo. Per confermare se la simultaneità fornita funziona normalmente, effettuare le seguenti operazioni: + [Verificare che la simultaneità fornita sia abilitata](provisioned-concurrency.md) sulla versione o sull'alias della funzione. **Nota** La simultaneità fornita non è configurabile nella [versione non pubblicata della funzione](configuration-versions.md) (\$1LATEST). + Assicurarsi che i trigger richiamino la versione o l'alias della funzione corretti. Ad esempio, se si utilizza Amazon API Gateway, verificare che API Gateway richiami la versione o l'alias della funzione con la simultaneità fornita, non \$1LATEST. Per confermare che viene utilizzata la concorrenza fornita, puoi controllare la metrica di [ProvisionedConcurrencyInvocations Amazon CloudWatch ](monitoring-concurrency.md#provisioned-concurrency-metrics). Un valore diverso da zero indica che la funzione sta elaborando le chiamate in ambienti di esecuzione inizializzati. + [Verifica se la concorrenza delle funzioni supera il livello configurato di concorrenza fornita controllando la metrica. ProvisionedConcurrencySpilloverInvocations CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics) Un valore diverso da zero indica che tutta la simultaneità fornita è in uso e che si è verificata una chiamata con un avvio a freddo. + Verifica la [frequenza di chiamata](gettingstarted-limits.md#api-requests) (richieste al secondo). Le funzioni con simultaneità fornita hanno un tasso massimo di 10 richieste al secondo per ogni simultaneità fornita. Ad esempio, una funzione configurata con 100 simultaneità fornita può gestire 1.000 richieste al secondo. Se la frequenza di chiamata supera le 1.000 richieste al secondo, è possibile che si verifichino alcuni avvii a freddo. ## Lambda: avvii a freddo con nuove versioni **Problema:** *si verificano avvii a freddo durante la distribuzione di nuove versioni della funzione.* Quando si aggiorna un alias di funzione, Lambda sposta automaticamente la simultaneità fornita alla nuova versione in base ai pesi configurati sull'alias. **Errore: KMSDisabled** *Eccezione: Lambda non è riuscita a decrittografare le variabili di ambiente perché la chiave KMS utilizzata è disabilitata. Controlla le impostazioni delle chiavi KMS della funzione.* Questo errore può verificarsi se la chiave AWS Key Management Service (AWS KMS) è disabilitata o se la concessione che consente a Lambda di utilizzare la chiave viene revocata. Se l'autorizzazione manca, configurare la funzione per utilizzare una chiave diversa. Quindi, riassegnare la chiave personalizzata per ricreare l'autorizzazione. ## Lambda: uscita imprevista di Node.js in fase di esecuzione (Runtime). NodejsExit) **Problema:** il *client di runtime Lambda ha rilevato un codice di uscita Node.js imprevisto*. Questo errore si verifica quando la funzione termina prima che tutte le promesse siano state risolte, ad esempio a causa di un bug del codice. Può verificarsi anche quando Node.js rileva una situazione di stallo che impedisce la risoluzione di Promises. Questo errore riguarda solo i gestori in stile asincrono, non i gestori in stile callback. **Runtime interessati: Node.js** 18 e versioni successive. **Per risolvere questo problema:** 1. Controlla il codice della tua funzione per verificare se ci sono promesse non mantenute nei gestori asincroni. 1. Assicurati che tutte le promesse siano correttamente risolte (risolte o rifiutate) prima del completamento della funzione. 1. Esamina il codice per verificare eventuali condizioni di gara nelle operazioni asincrone. [Per ulteriori informazioni sui codici di uscita di Node.js e sulla terminazione del processo, consultate la documentazione di Node.js.](https://nodejs.org/docs/latest/api/process.html#exit-codes) ## EFS: la funzione non è in grado di montare il file system EFS **Errore: EFSMountFailureException:** *La funzione non è riuscita a montare il file system EFS con il punto di accesso arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd*. La richiesta di montaggio al [file system](configuration-filesystem.md) della funzione è stata rifiutata. Verificare le autorizzazioni della funzione e verificare che il file system e il punto di accesso esistano e siano pronti per l'uso. ## EFS: la funzione non è in grado di connettersi al file system EFS **Errore: EFSMountConnectivityException:** *La funzione non è riuscita a connettersi al file system Amazon EFS con punto di accesso arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd. Controlla la configurazione di rete e riprova.* La funzione non è in grado di stabilire una connessione al [file system](configuration-filesystem.md) della funzione con il protocollo NFS (porta TCP 2049). Controllare la [configurazione del gruppo di sicurezza e del routing](https://docs.aws.amazon.com/efs/latest/ug/network-access.html) per le sottoreti del VPC. Se riscontri questi errori dopo aver aggiornato le impostazioni di configurazione VPC della funzione, prova a smontare e rimontare il file system. ## EFS: la funzione non è in grado di montare il file system EFS a causa del timeout **Errore: EFSMountTimeoutException:** *La funzione non è riuscita a montare il file system EFS con il punto di accesso \$1arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd*\$1 a causa del timeout di montaggio. La funzione è stata in grado di connettersi al [file system](configuration-filesystem.md) della funzione, ma l'operazione di montaggio è scaduta. Riprovare dopo un po' di tempo e considerare di limitare la [simultaneità](configuration-concurrency.md) della funzione per ridurre il carico sul file system. ## Lambda: Lambda ha rilevato un processo IO che stava impiegando troppo tempo *EFSIOException: questa istanza della funzione è stata interrotta perché Lambda ha rilevato un processo di I/O che impiegava troppo tempo.* Si è verificato il timeout di una chiamata precedente e Lambda non è stata in grado di terminare l'handler della funzione. Questo problema può verificarsi quando un file system collegato esaurisce i crediti di burst e il throughput di base è insufficiente. Per aumentare il throughput, è possibile aumentare le dimensioni del file system o utilizzare il throughput assegnato. ## Contenitore: errori CodeArtifactUserException **Errore:** *messaggio CodeArtifactUserPendingException di errore* L'ottimizzazione CodeArtifact è in sospeso. La funzione passa allo [stato attivo](functions-states.md) quando Lambda completa l'ottimizzazione. Codice di risposta HTTP: 409. **Errore: messaggio CodeArtifactUserDeletedException ** *di errore* CodeArtifact È programmata per essere eliminata. Codice di risposta HTTP: 409. **Errore:** *messaggio CodeArtifactUserFailedException di errore* Lambda non è riuscito a ottimizzare il codice. Correggere il codice e caricarlo di nuovo. Codice di risposta HTTP: 409. ## Contenitore: InvalidEntrypoint errori **Errore:** *Runtime. ExitError o «errorType»: «Runtime. InvalidEntrypoint«* Verificare che l'elemento ENTRYPOINT dell'immagine container includa il percorso assoluto come posizione. Verificare inoltre che l'immagine non contenga un collegamento simbolico come ENTRYPOINT. **Errore:** *stai utilizzando un CloudFormation modello e il contenitore ENTRYPOINT viene sovrascritto con un valore nullo o vuoto*. Esamina la risorsa nel [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html)modello. CloudFormation Se si dichiara una `ImageConfig` risorsa nel modello, è necessario fornire valori non vuoti per tutte e tre le proprietà. # Risoluzione dei problemi di esecuzione in Lambda Quando il runtime Lambda esegue il codice della funzione, l'evento potrebbe essere elaborato su un'istanza della funzione che ha elaborato eventi per un determinato periodo o potrebbe richiedere l'inizializzazione di una nuova istanza. Gli errori possono verificarsi durante l'inizializzazione della funzione, quando il codice dell'handler elabora l'evento o quando la funzione restituisce (o non riesce a restituire) una risposta. Gli errori di esecuzione delle funzioni possono essere causati da problemi relativi al codice, alla configurazione delle funzioni, alle risorse downstream o alle autorizzazioni. Se si invoca direttamente la funzione, si ricevono errori di funzione nella risposta da Lambda. Se si richiama la funzione in modo asincrono, con un mapping di origine eventi o tramite un altro servizio, è possibile che vengano riscontrati errori nei log, nella coda DLQ o in una destinazione in caso di errore. Le opzioni di gestione degli errori e il comportamento dei tentativi variano a seconda di come si richiama la funzione e del tipo di errore. Quando il codice della funzione o il runtime Lambda restituiscono un errore, il codice di stato nella risposta da Lambda è 200 OK. La presenza di un errore nella risposta è indicata da un'intestazione denominata `X-Amz-Function-Error`. I codici di stato serie 400 e 500 sono riservati agli [errori di chiamata](troubleshooting-invocation.md). **Topics** + [Lambda: debug remoto con Visual Studio Code](#troubleshooting-execution-remote-debugging) + [Lambda: l'esecuzione richiede troppo tempo](#troubleshooting-execution-toolong) + [Lambda: payload per eventi imprevisti](#troubleshooting-execution-unexpected-payload) + [Lambda: dimensioni del carico utile inaspettatamente grandi](#troubleshooting-execution-large-payload) + [Lambda: errori di codifica e decodifica JSON](#troubleshooting-execution-json-encoding) + [Lambda: i log o le tracce non vengono visualizzati](#troubleshooting-execution-logstraces) + [Lambda: non vengono visualizzati tutti i log della mia funzione](#troubleshooting-execution-missinglogs) + [Lambda: la funzione restituisce prima del termine dell'esecuzione](#troubleshooting-execution-unfinished) + [Lambda: esecuzione di una versione o di un alias di funzione non intenzionali](#unintended-function) + [Lambda: rilevamento di loop infiniti](#infinite-loops) + [Generale: indisponibilità del servizio downstream](#downstream-unavailability) + [AWS SDK: versioni e aggiornamenti](#troubleshooting-execution-versions) + [Python: caricamento librerie errato](#troubleshooting-execution-libraries) + [Java: la funzione impiega più tempo per elaborare gli eventi dopo l'aggiornamento a Java 17 da Java 11](#troubleshooting-execution-java-perf) + [Kafka: gestione degli errori e nuovi tentativi di configurazione](#troubleshooting-kafka-error-handling) ## Lambda: debug remoto con Visual Studio Code **Problema:** *difficoltà nella risoluzione dei problemi relativi al comportamento complesso della funzione Lambda nell'ambiente reale AWS * Lambda fornisce una funzionalità di debug remoto tramite. AWS Toolkit for Visual Studio Code Per istruzioni generali e di configurazione, vedi. [Esecuzione da remoto del debug delle funzioni Lambda con Visual Studio Code](debugging.md) Per istruzioni dettagliate sulla risoluzione dei problemi, sui casi d'uso avanzati e sulla disponibilità delle regioni, consulta il [debug remoto delle funzioni Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) nella Guida per l'utente. AWS Toolkit for Visual Studio Code ## Lambda: l'esecuzione richiede troppo tempo **Problema:** *l'esecuzione della funzione richiede troppo tempo.* Se l'esecuzione del codice richiede molto più tempo in Lambda rispetto al computer locale, potrebbe essere limitato dalla memoria o dalla potenza di elaborazione disponibile per la funzione. [Configurare la funzione con memoria aggiuntiva](configuration-memory.md) per aumentare sia la memoria sia la CPU. ## Lambda: payload per eventi imprevisti **Problema:** *errori di funzione relativi a un formato JSON non valido o a* una convalida dei dati inadeguata. Tutte le funzioni Lambda ricevono un payload di eventi nel primo parametro dell'handler. Il payload dell'evento è una struttura JSON che può contenere array ed elementi nidificati. Il formato JSON non valido può verificarsi se fornito da servizi upstream che non utilizzano un processo affidabile per il controllo delle strutture JSON. Ciò si verifica quando i servizi concatenano stringhe di testo o incorporano input dell'utente che non sono stati eliminati. JSON viene inoltre spesso serializzato per il passaggio da un servizio all'altro. Analizza sempre le strutture JSON sia come producer che come consumer di JSON per assicurarti che la struttura sia valida. Analogamente, il mancato controllo degli intervalli di valori nel payload dell'evento può causare errori. Nell'esempio seguente viene illustrata una funzione che calcola le ritenute d'acconto: ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` Questa funzione utilizza lo stipendio e l'aliquota fiscale del payload dell'evento per eseguire il calcolo. Tuttavia, il codice non riesce a verificare se gli attributi sono presenti. Inoltre, non riesce a controllare i tipi di dati o a garantire i limiti, ad esempio garantendo che la percentuale fiscale sia compresa tra 0 e 1. Di conseguenza, i valori al di fuori di questi limiti producono risultati privi di senso. Un tipo errato o un attributo mancante causa un errore di runtime. Crea test per assicurarti che la tua funzione gestisca dimensioni di payload maggiori. La dimensione massima per il payload di un evento Lambda è 1 MB. A seconda del contenuto, payload più grandi possono significare più elementi passati alla funzione o più dati binari incorporati in un attributo JSON. In entrambi i casi, ciò può comportare una maggiore elaborazione per una funzione Lambda. Payload più grandi possono anche causare dei timeout. Ad esempio, una funzione Lambda elabora un record ogni 100 ms e ha un timeout di 3 secondi. L'elaborazione ha esito positivo per 0-29 elementi nel payload. Tuttavia, se il payload contiene più di 30 elementi, la funzione scade e genera un errore. Per evitare ciò, assicurati che siano impostati dei timeout per gestire il tempo di elaborazione aggiuntivo per il numero massimo di elementi previsto. ## Lambda: dimensioni del carico utile inaspettatamente grandi **Problema:** *le funzioni si stanno esaurendo o causano errori* a causa di carichi utili di grandi dimensioni. I payload più grandi possono causare timeout ed errori. Ti consigliamo di creare test per garantire che la funzione gestisca i payload più elevati previsti e per assicurarti che il timeout della funzione sia impostato correttamente. Inoltre, alcuni payload di eventi possono contenere puntatori ad altre risorse. Ad esempio, una funzione Lambda con 128 MB di memoria può eseguire l'elaborazione delle immagini su un file JPG archiviato come oggetto in S3. La funzione funziona come previsto con file di immagine più piccoli. Tuttavia, quando viene fornito un file JPG più grande come input, la funzione Lambda genera un errore dovuto all'esaurimento della memoria. Per evitare ciò, i casi di test dovrebbero includere esempi tratti dai limiti superiori delle dimensioni dei dati previste. Il codice dovrebbe anche convalidare le dimensioni del payload. ## Lambda: errori di codifica e decodifica JSON **Problema: NoSuchKey ** *eccezione durante* l'analisi degli input JSON. Assicurati di elaborare correttamente gli attributi JSON. Ad esempio, per gli eventi generati da S3, l'`s3.object.key`attributo contiene un nome chiave dell'oggetto con codifica URL. Molte funzioni elaborano questo attributo come testo per caricare l'oggetto S3 di riferimento: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` Questo codice funziona con il nome della chiave `james.jpg` ma genera un errore `NoSuchKey` quando il nome è `james beswick.jpg`. Poiché la codifica URL converte gli spazi e gli altri caratteri in un nome chiave, è necessario assicurarsi che le funzioni decodifichino le chiavi prima di utilizzare questi dati: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda: i log o le tracce non vengono visualizzati **Problema:** *i log non vengono visualizzati in Logs*. CloudWatch **Problema:** *le tracce non vengono visualizzate* in. AWS X-Ray La tua funzione richiede l'autorizzazione per chiamare CloudWatch Logs e X-Ray. Aggiornare il [ruolo di esecuzione](lambda-intro-execution-role.md) per concedere a esso l'autorizzazione. Aggiungere le policy gestite seguenti per abilitare i registri e l'analisi. + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** Quando aggiungi le autorizzazioni alla funzione, aggiorni anche il relativo codice o la configurazione. Questa operazione forza l'arresto e la sostituzione delle istanze della funzione in esecuzione che hanno credenziali obsolete. **Nota** Potrebbero essere necessari da 5 a 10 minuti prima che i log vengano visualizzati dopo una chiamata di funzione. ## Lambda: non vengono visualizzati tutti i log della mia funzione **Problema:** i registri delle *funzioni non sono presenti in CloudWatch Logs, anche se* le mie autorizzazioni sono corrette Se Account AWS raggiungi i [limiti di quota dei CloudWatch log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html), CloudWatch rallenta la registrazione delle funzioni. Quando ciò accade, alcuni dei log generati dalle tue funzioni potrebbero non apparire in Logs. CloudWatch Se la funzione emette i log a una velocità troppo elevata per consentire a Lambda di elaborarli, ciò può anche far sì che gli output di log non vengano visualizzati in Logs. CloudWatch Quando Lambda non riesce a inviare i log CloudWatch alla velocità con cui vengono prodotti dalla funzione, li elimina per evitare che l'esecuzione della funzione rallenti. Aspettatevi di osservare costantemente i log eliminati quando la velocità effettiva dei log supera 2 per un singolo flusso di log. MB/s Se la funzione è configurata per utilizzare [log in formato JSON,](monitoring-cloudwatchlogs-logformat.md) Lambda tenta di inviare un [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped)evento a CloudWatch Logs quando elimina i log. Tuttavia, quando CloudWatch limita la registrazione della funzione, questo evento potrebbe non raggiungere CloudWatch Logs, quindi non vedrai sempre un record quando Lambda elimina i log. Per verificare se hai Account AWS raggiunto i limiti di quota di CloudWatch Logs, procedi come segue: 1. Apri la [console Service Quotas](https://console.aws.amazon.com/servicequotas). 1. Nel pannello di navigazione, scegli **Servizi AWS ** (servizi AWS ). 1. Dall'elenco dei **AWS servizi**, cerca Amazon CloudWatch Logs. 1. Nell'elenco **Service Quotas**, scegli le quote `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second` e `PutLogEvents throttle limit in transactions per second` per visualizzarne l'utilizzo. Puoi anche impostare CloudWatch allarmi per avvisarti quando l'utilizzo del tuo account supera un limite specificato per queste quote. Per ulteriori informazioni, consulta [Creare un CloudWatch allarme basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html). Se i limiti di quota predefiniti per CloudWatch i registri non sono sufficienti per il tuo caso d'uso, puoi [richiedere un aumento della quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). ## Lambda: la funzione restituisce prima del termine dell'esecuzione **Problema: (Node.js)** *La funzione restituisce prima che il codice finisca l'esecuzione* Molte librerie, incluso l' AWS SDK, funzionano in modo asincrono. Quando si effettua una chiamata di rete o si esegue un'altra operazione che richiede l'attesa di una risposta, le librerie restituiscono un oggetto chiamato promessa che tiene traccia dell'avanzamento dell'operazione in background. Per attendere che la promessa si risolva in una risposta, utilizzare la parola chiave `await`. Questo blocca l'esecuzione del codice dell'handler fino a quando la promessa non viene risolta in un oggetto che contiene la risposta. Se non è necessario utilizzare i dati della risposta nel codice, è possibile restituire la promessa direttamente al runtime. Alcune librerie non restituiscono promesse ma possono essere racchiuse in codice che lo fa. Per ulteriori informazioni, consulta [Definire l'handler delle funzioni Lambda in Node.js](nodejs-handler.md). ## Lambda: esecuzione di una versione o di un alias di funzione non intenzionali **Problema: la versione o l'alias** *della funzione non sono stati richiamati* Quando si pubblicano nuove funzioni Lambda nella console o in uso AWS SAM, la versione più recente del codice è rappresentata da. `$LATEST` Per impostazione predefinita, le chiamate che non specificano una versione o un alias indirizzano automaticamente alla `$LATEST` versione del codice della funzione. Se si utilizzano versioni o alias di funzioni specifiche, si tratta in aggiunta a versioni pubblicate immutabili di una funzione. `$LATEST` Durante la risoluzione dei problemi relativi a queste funzioni, verificate innanzitutto che il chiamante abbia richiamato la versione o l'alias previsti. È possibile farlo controllando i registri delle funzioni. La versione della funzione che è stata richiamata viene sempre mostrata nella riga di registro START: ![\[operazioni di debug (figura 1)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda: rilevamento di loop infiniti **Problema:** *modelli di loop infiniti relativi alle funzioni Lambda* Esistono due tipi di cicli infiniti nelle funzioni Lambda. Il primo è all'interno della funzione stessa, causato da un ciclo che non esce mai. L'invocazione termina solo quando la funzione scade. È possibile identificarli monitorando i timeout e quindi correggendo il comportamento di loop. Il secondo tipo di loop è tra le funzioni Lambda e altre AWS risorse. Si verificano quando un evento proveniente da una risorsa come un bucket S3 richiama una funzione Lambda, che quindi interagisce con la stessa risorsa di origine per attivare un altro evento. Ciò richiama nuovamente la funzione, che crea un'altra interazione con lo stesso bucket S3 e così via. Questi tipi di loop possono essere causati da diverse fonti di AWS eventi, tra cui code Amazon SQS e tabelle DynamoDB. Puoi utilizzare il rilevamento [ricorsivo](invocation-recursion.md) dei loop per identificare questi modelli. ![\[operazioni di debug (figura 2)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-2.png) Puoi evitare questi loop assicurandoti che le funzioni Lambda scrivano su risorse che non sono le stesse della risorsa che consuma. Se devi pubblicare nuovamente i dati sulla risorsa che consuma, assicurati che i nuovi dati non attivino lo stesso evento. In alternativa, utilizza il [filtro degli eventi.](invocation-eventfiltering.md) Ad esempio, ecco due soluzioni proposte per loop infiniti con risorse S3 e DynamoDB: + Se riscrivi nello stesso bucket S3, usa un prefisso o suffisso diverso dal trigger dell'evento. + Se scrivi elementi nella stessa tabella DynamoDB, includi un attributo su cui può filtrare una funzione Lambda che utilizza. Se Lambda trova l'attributo, non genererà un'altra chiamata. ## Generale: indisponibilità del servizio downstream **Problema:** *i servizi downstream su cui si basa la funzione Lambda* non sono disponibili Per le funzioni Lambda che richiamano endpoint di terze parti o altre risorse downstream, assicurati che siano in grado di gestire gli errori e i timeout del servizio. Queste risorse a valle possono avere tempi di risposta variabili o diventare non disponibili a causa di interruzioni del servizio. A seconda dell'implementazione, questi errori downstream possono apparire come timeout Lambda o eccezioni se la risposta all'errore del servizio non viene gestita all'interno del codice della funzione. Ogni volta che una funzione dipende da un servizio a valle, ad esempio una chiamata API, implementa la gestione degli errori e la logica dei tentativi appropriati. Per i servizi critici, la funzione Lambda deve pubblicare metriche o log su. CloudWatch Ad esempio, se un'API di pagamento di terze parti non è disponibile, la funzione Lambda può registrare queste informazioni. Puoi quindi impostare CloudWatch allarmi per inviare notifiche relative a questi errori. Poiché Lambda è in grado di scalare rapidamente, i servizi downstream non serverless potrebbero avere difficoltà a gestire i picchi di traffico. Esistono tre approcci comuni per gestire questo problema: + **Memorizzazione nella cache**: valuta la possibilità di memorizzare nella cache il risultato dei valori restituiti da servizi di terze parti se non vengono modificati frequentemente. Puoi memorizzare questi valori in una variabile globale nella tua funzione o in un altro servizio. Ad esempio, i risultati di una query sull'elenco di prodotti da un'istanza Amazon RDS potrebbero essere salvati per un periodo di tempo all'interno della funzione per evitare query ridondanti. + **Accodamento**: durante il salvataggio o l'aggiornamento dei dati, aggiungi una coda Amazon SQS tra la funzione Lambda e la risorsa. La coda mantiene i dati in modo duraturo mentre il servizio a valle elabora i messaggi. + **Proxy**: laddove in genere vengono utilizzate connessioni di lunga durata, ad esempio per le istanze Amazon RDS, utilizza un livello proxy per raggruppare e riutilizzare tali connessioni. Per i database relazionali, [Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) è un servizio progettato per aiutare a migliorare la scalabilità e la resilienza nelle applicazioni basate su Lambda. ## AWS SDK: versioni e aggiornamenti **Problema:** *l' AWS SDK incluso nel runtime non è la versione più recente* **Problema:** *l' AWS SDK incluso nel runtime si aggiorna automaticamente* I runtime per i linguaggi interpretati includono una versione dell' AWS SDK. Lambda aggiorna periodicamente questi runtime per utilizzare la versione SDK più recente. Per trovare la versione dell'SDK inclusa nel runtime, consulta le seguenti sezioni: + [Versioni SDK incluse nel runtime (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [Versioni SDK incluse nel runtime (Python)](lambda-python.md#python-sdk-included) + [Versioni SDK incluse nel runtime (Ruby)](lambda-ruby.md#ruby-sdk-included) Per utilizzare una versione più recente dell' AWS SDK o per bloccare le funzioni su una versione specifica, puoi raggruppare la libreria con il codice della funzione o creare [un layer Lambda](chapter-layers.md). Per informazioni dettagliate sulla creazione di un pacchetto di distribuzione con dipendenze, vedere i seguenti argomenti: ------ #### [ Node.js ] [Distribuisci funzioni Lambda in Node.js con archivi di file .zip](nodejs-package.md) ------ #### [ Python ] [Utilizzo di archivi di file .zip per le funzioni Lambda in Python](python-package.md) ------ #### [ Ruby ] [Distribuire le funzioni Ruby Lambda con gli archivi di file .zip](ruby-package.md) ------ #### [ Java ] [Distribuisci funzioni Lambda per Java con archivi di file .zip o JAR](java-package.md) ------ #### [ Go ] [Distribuisci funzioni Lambda per Go con gli archivi di file .zip](golang-package.md) ------ #### [ C\$1 ] [Crea e implementa le funzioni Lambda C\$1 con gli archivi di file .zip](csharp-package.md) ------ #### [ PowerShell ] [Distribuzione delle funzioni Lambda di PowerShell con gli archivi di file .zip](powershell-package.md) ------ ## Python: caricamento librerie errato **Problema:** (Python) *alcune librerie non vengono caricate correttamente dal pacchetto di distribuzione* Le librerie con moduli di estensione scritti in C o C \$1\$1 devono essere compilate in un ambiente con la stessa architettura del processore di Lambda (Amazon Linux). Per ulteriori informazioni, consulta [Utilizzo di archivi di file .zip per le funzioni Lambda in Python](python-package.md). ## Java: la funzione impiega più tempo per elaborare gli eventi dopo l'aggiornamento a Java 17 da Java 11 **Problema:** (Java) *la funzione impiega più tempo per elaborare gli eventi dopo l'aggiornamento a Java 17 da Java 11* Ottimizza il compilatore utilizzando il parametro `JAVA_TOOL_OPTIONS`. I runtime Lambda per Java 17 e versioni successive modificano le opzioni predefinite del compilatore. La modifica migliora i tempi di avvio a freddo per le funzioni di breve durata, ma il comportamento precedente è più adatto alle funzioni ad alta intensità di calcolo e di lunga durata. Imposta `JAVA_TOOL_OPTIONS` su `-XX:-TieredCompilation` per ripristinare il comportamento di Java 11. Per ulteriori informazioni sul parametro `JAVA_TOOL_OPTIONS`, vedi [Informazioni sulla variabile di ambiente `JAVA_TOOL_OPTIONS`](java-customization.md#java-tool-options). ## Kafka: gestione degli errori e nuovi tentativi di configurazione **Problema:** la *mappatura delle sorgenti degli eventi Kafka non riesce a configurare le impostazioni dei nuovi tentativi o le destinazioni in caso di errore* Le configurazioni Kafka Retry e le destinazioni in caso di errore sono disponibili solo per le mappature delle sorgenti degli eventi con la modalità provisioning abilitata. Assicurati di aver effettuato la configurazione prima di tentare di impostare configurazioni di nuovo `MinimumPollers` tentativo. `ProvisionedPollerConfig` Errori di configurazione comuni: + **Tentativi infiniti con batch bisect**: non è possibile abilitare `BisectBatchOnFunctionError` quando `MaximumRetryAttempts` è impostato su -1 (infinito). Imposta un limite di tentativi finito o disabilita il batch bisettale. + **Ricorsione dello stesso argomento**: l'argomento sulla destinazione di Kafka in caso di errore non può essere lo stesso di nessuno degli argomenti di origine. Scegliete un nome diverso per l'argomento a lettere morte. + Formato di **destinazione Kafka non valido: utilizza il `kafka://` formato** per specificare un argomento di Kafka come destinazione in caso di errore. + **kafka: problemi di WriteData autorizzazione:** assicurati che il tuo ruolo di esecuzione disponga delle autorizzazioni per l'argomento di destinazione. `kafka-cluster:WriteData` L'argomento non esiste, eccezioni di timeout o problemi di limitazione dell'API di scrittura potrebbero richiedere un aumento dei limiti dell'account. # Risolvi i problemi di mappatura delle sorgenti degli eventi in Lambda I problemi in Lambda relativi alla [mappatura dell'origine di un evento](invocation-eventsourcemapping.md) possono essere più complessi perché implicano il debug su più servizi. Inoltre, il comportamento dell'origine degli eventi può variare in base all'origine esatta dell'evento utilizzata. Questa sezione elenca i problemi comuni relativi alla mappatura delle sorgenti degli eventi e fornisce indicazioni su come identificarli e risolverli. **Nota** Questa sezione utilizza un'origine eventi Amazon SQS a scopo illustrativo, ma i principi si applicano ad altre mappature delle fonti degli eventi che mettono in coda i messaggi per le funzioni Lambda. ## Identificazione e gestione della limitazione In Lambda, la limitazione si verifica quando si raggiunge il limite di concorrenza della funzione o dell'account. Considera il seguente esempio, in cui esiste una funzione Lambda che legge i messaggi da una coda Amazon SQS. Questa funzione Lambda simula invocazioni di 30 secondi e ha una dimensione batch di 1. Ciò significa che la funzione elabora solo 1 messaggio ogni 30 secondi: ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` Con un tempo di invocazione così lungo, i messaggi iniziano ad arrivare in coda più rapidamente di quanto vengano elaborati. Se la simultaneità non riservata dell'account è 100, Lambda è scalabile fino a 100 esecuzioni simultanee, quindi si verifica una limitazione. Puoi vedere questo modello nei parametri di CloudWatch per la funzione: ![\[operazioni di debug (figura 10)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-10.png) I parametri di CloudWatch per la funzione non mostrano errori, ma il grafico delle esecuzioni simultanee mostra che è stata raggiunta la simultaneità massima. Di conseguenza, il grafico **Limitazioni** mostra la limitazione in atto. Puoi rilevare la limitazione utilizzando gli allarmi CloudWatch e impostare un allarme ogni volta che il parametro di limitazione per una funzione è maggiore di 0. Dopo aver identificato il problema della limitazione, hai a disposizione alcune opzioni per la risoluzione: + Richiedere un aumento della simultaneità al Supporto AWS in questa regione. + Identificare i problemi di prestazioni della funzione per migliorare la velocità di elaborazione e di conseguenza il throughput. + Aumentare la dimensione del batch della funzione, in modo che a ogni invocazione della funzione vengano elaborati più messaggi. ## Errori nella funzione di elaborazione Se la funzione di elaborazione genera errori, i messaggi vengono restituiti alla coda SQS. Il servizio Lambda impedisce la scalabilità della funzione per evitare errori su larga scala. I seguenti parametri SQS in CloudWatch indicano un problema con l'elaborazione delle code: ![\[operazioni di debug (figura 11)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-11.png) Aumentano sia l'età dei primi messaggi che il numero di messaggi visibili, mentre nessun messaggio viene eliminato. La coda continua a crescere ma i messaggi non vengono elaborati. I parametri CloudWatch per l'elaborazione della funzione Lambda indicano anche che esiste un problema: ![\[operazioni di debug (figura 12)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-12.png) Il parametro **numero errori** è diverso da zero ed è in aumento, mentre le **esecuzioni simultanee** si sono ridotte e la limitazione è stata interrotta. Ciò dimostra che il servizio Lambda ha interrotto la scalabilità a causa di errori. I log CloudWatch per la funzione forniscono dettagli sul tipo di errore. È possibile risolvere questo problema identificando la funzione che causa l'errore, quindi trovando e risolvendo l'errore. Una volta corretto l'errore e implementato il nuovo codice, i parametri di CloudWatch mostrano come viene ripristinata l'elaborazione: ![\[operazioni di debug (figura 13)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/debugging-ops-figure-13.png) Qui, il **numero di errori** scende a zero e la **percentuale di successo** torna al 100%. Il servizio Lambda ricomincia a scalare la funzione, come mostrato nel grafico delle **esecuzioni simultanee**. ## Identificazione e gestione della contropressione Se un produttore di eventi genera costantemente messaggi per una coda SQS più velocemente di quanto una funzione Lambda possa elaborare la gestione, si verifica una contropressione. In questo caso, il monitoraggio SQS mostra l'età del primo messaggio che cresce in modo lineare, insieme al numero approssimativo di messaggi visibili. Puoi rilevare la contropressione nelle code utilizzando gli allarmi CloudWatch. I passaggi per risolvere la contropressione dipendono dal carico di lavoro. Se l'obiettivo principale è aumentare la capacità di elaborazione e il throughput mediante la funzione Lambda: + Richiedere un aumento della simultaneità al Supporto AWS nella regione specifica. + Aumentare la dimensione del batch della funzione, in modo che a ogni invocazione della funzione vengano elaborati più messaggi. # Risoluzione dei problemi di rete in Lambda Per impostazione predefinita, Lambda esegue le funzioni in un Virtual Private Cloud (VPC) interno con connettività ai servizi AWS e a Internet. Per accedere alle risorse di rete locali, è possibile [configurare la funzione in modo che si connetta a un VPC nel proprio account](configuration-vpc.md). Quando si utilizza questa funzionalità, è possibile gestire l'accesso a Internet della funzione e la connettività di rete con risorse Amazon Virtual Private Cloud (Amazon VPC). Gli errori di connettività di rete possono derivare da problemi relativi alla configurazione di routing del VPC, alle regole del gruppo di sicurezza, alle autorizzazioni dei ruoli AWS Identity and Access Management (IAM) o alla traduzione degli indirizzi di rete (NAT) del VPC o dalla disponibilità di risorse come indirizzi IP o interfacce di rete. A seconda del problema, potrebbe verificarsi un errore o un timeout specifico se una richiesta non riesce a raggiungere la sua destinazione. **Topics** + [VPC: la funzione perde l'accesso a Internet o scade](#troubleshooting-networking-cfn) + [VPC: la connessione TCP o UDP fallisce a intermittenza](#troubleshooting-networking-tcp-udp) + [VPC: è necessario accedere alla funzione Servizi AWS senza utilizzare Internet](#troubleshooting-networking-access) + [VPC: raggiunto il limite dell'interfaccia di rete elastica](#troubleshooting-networking-limit) + [EC2: Interfaccia di rete elastica con tipo «lambda»](#troubleshooting-networking-eni) + [DNS: impossibile connettersi agli host con UNKNOWNHOSTEXCEPTION](#troubleshooting-networking-dns-tcp) ## VPC: la funzione perde l'accesso a Internet o scade **Problema:** *la funzione Lambda perde l'accesso a Internet dopo la connessione a un VPC.* **Errore:** *Errore: collegare ETIMEDUT 176.32.98.189:443* **Errore:** *Errore: timeout dell'attività dopo 10,00 secondi* **Errore: Tempo di lettura scaduto ReadTimeoutError***. (timeout di lettura = 15*) Quando si collega una funzione a un VPC, tutte le richieste in uscita passano attraverso il VPC. Per connettersi a Internet, configurare il VPC per inviare il traffico in uscita dalla sottorete della funzione a un gateway NAT in una sottorete pubblica. Per ulteriori informazioni e le configurazioni VPC di esempio, vedere [Abilitare l'accesso a Internet per funzioni Lambda connesse a un VPC](configuration-vpc-internet.md). Se alcune delle tue connessioni TCP stanno scadendo, verifica [VPC: la connessione TCP o UDP fallisce a intermittenza](#troubleshooting-networking-tcp-udp) se la sottorete utilizza una lista di controllo degli accessi alla rete (NACL). Altrimenti, ciò è probabilmente dovuto alla frammentazione dei pacchetti. Le funzioni Lambda non sono in grado di gestire le richieste TCP frammentate in entrata, poiché Lambda non supporta la frammentazione IP per TCP o ICMP. ## VPC: la connessione TCP o UDP fallisce a intermittenza **Nota** Questo problema si applica solo se la sottorete utilizza una lista di controllo dell'[accesso alla rete](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics) (ACL). La rete ACLs non è necessaria per consentire a Lambda di connettersi alle sottoreti. **Problema:** *Lambda perde in modo intermittente la connessione alle sottoreti VPC, per le quali hai configurato una lista di controllo dell'accesso alla rete* (ACL). Per le funzioni Lambda abilitate per VPC AWS , [crea un ENIs](configuration-vpc.md#configuration-vpc-enis) iperpiano nell'account del cliente e utilizza `1024` porte temporanee `65535` per connettere Lambda al VPC del cliente. Se si utilizza la rete ACLs nella sottorete di destinazione, è necessario consentire l'intervallo di porte sia per TCP che per UDP. `1024` `65535` Non consentire questo intervallo completo di porte può causare errori di connessione intermittenti. ## VPC: è necessario accedere alla funzione Servizi AWS senza utilizzare Internet **Problema:** è *necessario accedere alla funzione Lambda Servizi AWS senza utilizzare Internet*. Per connettere una funzione Servizi AWS da una sottorete privata senza accesso a Internet, usa gli endpoint VPC. ## VPC: raggiunto il limite dell'interfaccia di rete elastica **Errore ENILimitReachedException:** *è stato raggiunto il limite dell'interfaccia elastica di rete per il VPC della funzione*. Quando si connette una funzione Lambda a un VPC, Lambda crea un'interfaccia di rete elastica per ogni combinazione di sottorete e gruppo di sicurezza collegato alla funzione. La quota di servizio predefinita è 250 interfacce di rete per VPC. Per richiedere un aumento di una quota, è possibile utilizzare la [console Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26). ## EC2: Interfaccia di rete elastica con tipo «lambda» **Codice di errore:** *Client. OperationNotPermitted* **Messaggio di errore:** *il gruppo di sicurezza non può essere modificato per questo tipo di interfaccia* Riceverai questo errore se cerchi di modificare un'interfaccia di rete elastica (ENI) gestita da Lambda. `ModifyNetworkInterfaceAttribute` non è incluso nell'API Lambda per le operazioni di aggiornamento su interfacce di rete elastiche create da Lambda. ## DNS: impossibile connettersi agli host con UNKNOWNHOSTEXCEPTION **Messaggio di errore:** *UNKNOWNHOSTEXCEPTION* Le funzioni Lambda supportano un massimo di 20 connessioni TCP simultanee per la risoluzione DNS. La tua funzione potrebbe esaurire quel limite. Le richieste DNS più comuni vengono eseguite tramite UDP. Se la tua funzione consiste solo nel creare connessioni DNS UDP, è poco probabile che questo sia il tuo problema. Questo errore viene generalmente generato a causa di una configurazione errata o di un'infrastruttura degradata, quindi prima di esaminare a fondo il traffico DNS, verifica che l'infrastruttura DNS sia configurata correttamente e integra e che la funzione Lambda si riferisca a un host specificato nel DNS. Se diagnostichi il problema come correlato al numero massimo di connessioni TCP, tieni presente che non puoi richiedere un aumento di questo limite. Se la tua funzione Lambda ritorna al DNS TCP a causa di payload DNS di grandi dimensioni, verifica che la tua soluzione utilizzi librerie che supportano EDNS. Per ulteriori informazioni su EDNS, consulta [lo standard RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891). Se i payload DNS superano costantemente le dimensioni massime EDNS, la soluzione potrebbe comunque esaurire il limite DNS TCP.