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.

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. Configura la funzione con memoria aggiuntiva per aumentare sia la memoria cheCPU.

Lambda: payload per eventi imprevisti

Problema: errori di funzione relativi alla convalida dei dati non valida JSON o inadeguata.

Tutte le funzioni Lambda ricevono un payload di eventi nel primo parametro dell'handler. Il payload dell'evento è una JSON struttura che può contenere matrici ed elementi annidati.

I malformati JSON possono verificarsi se forniti 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. JSONviene inoltre spesso serializzato per il passaggio da un servizio all'altro. Analizza sempre JSON le strutture sia come produttore che come consumatore 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 un payload di eventi Lambda è 256 KB. A seconda del contenuto, payload più grandi possono significare più elementi passati alla funzione o più dati binari incorporati in un JSON attributo. 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 scadono 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 JPG file archiviato come oggetto in S3. La funzione funziona come previsto con file di immagine più piccoli. Tuttavia, quando viene fornito un JPG file 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 massimi delle dimensioni dei dati previste. Il codice dovrebbe anche convalidare le dimensioni del payload.

Lambda: errori di JSON codifica e decodifica

Problema: NoSuchKey eccezione durante l'analisi degli input. JSON

Verificate che JSON gli attributi siano elaborati correttamente. Ad esempio, per gli eventi generati da S3, l's3.object.keyattributo contiene un nome chiave dell'oggetto URL codificato. Molte funzioni elaborano questo attributo come testo per caricare l'oggetto S3 di riferimento:

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 URL codifica converte gli spazi e altri caratteri in un nome chiave, è necessario assicurarsi che le funzioni decodifichino le chiavi prima di utilizzare questi dati:

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 registri non vengono visualizzati nei registri. 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 per concedere a esso l'autorizzazione. Aggiungere le policy gestite seguenti per abilitare i registri e l'analisi.

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.

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, 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. Aspettati di osservare costantemente i log eliminati quando il throughput dei log supera i 2 MB/s per un singolo flusso di log.

Se la funzione è configurata per utilizzare log JSON formattati, Lambda tenta di inviare un logsDroppedevento 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:

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.

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.

Lambda: la funzione restituisce prima del termine dell'esecuzione

Problema: (Node.js) La funzione restituisce prima che il codice finisca l'esecuzione

Molte librerie, inclusa la 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.

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 START registro:

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 SQS code Amazon e tabelle DynamoDB. Puoi utilizzare il rilevamento ricorsivo dei loop per identificare questi modelli.

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. Ad esempio, ecco due soluzioni proposte per loop infiniti con risorse S3 e DynamoDB:

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 API chiamata, 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 pagamento di terze parti non è API più disponibile, la funzione Lambda può registrare queste informazioni. È quindi possibile 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:

AWS SDK: Versioni e aggiornamenti

Problema: la versione AWS SDK inclusa nel runtime non è la versione più recente

Problema: la AWS SDK versione inclusa nel runtime si aggiorna automaticamente

I runtime per i linguaggi di scripting includono AWS SDK e vengono aggiornati periodicamente alla versione più recente. La versione corrente per ogni runtime è elencata nella pagina runtime. Per utilizzare una versione più recente di o per bloccare le funzioni su una versione specifica, puoi raggruppare la libreria con il codice della funzione o creare un layer Lambda. AWS SDK Per informazioni dettagliate sulla creazione di un pacchetto di distribuzione con dipendenze, vedere i seguenti argomenti:

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

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.