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: 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, consulta Abilita e imposta .

Per istruzioni dettagliate sulla risoluzione dei problemi, sui casi d'uso avanzati e sulla disponibilità delle regioni, consulta il debug remoto delle funzioni Lambda 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 per aumentare sia la memoria sia la CPU.

Payload di eventi non previsti

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.

Un JSON mal strutturato può verificarsi se fornito da servizi upstream che non utilizzano un processo affidabile per il controllo delle proprie 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 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 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.

Dimensioni del payload inaspettatamente grandi

Problema: le funzioni scadono o causano errori a causa di carichi utili di grandi dimensioni.

Payload più grandi possono anche causare dei timeout. Consigliamo di creare dei test per garantire che la funzione gestisca i payload più elevati previsti e che il timeout della funzione sia impostato correttamente.

Molti payload di eventi contengono riferimenti ad altre risorse. Ad esempio, una funzione Lambda con 128 MB di memoria può convertire un file JPG archiviato come oggetto in S3, utilizzando una libreria di elaborazione delle immagini. 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 massimi delle dimensioni dei dati previste e il codice dovrebbe anche convalidare le dimensioni del payload. Il codice dovrebbe anche convalidare le dimensioni del payload.

Lambda: errori di codifica e decodifica JSON

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

Assicurati di elaborare correttamente gli attributi JSON. Ad esempio, per gli eventi generati da S3, l'attributo s3.object.key contiene un nome chiave dell'oggetto con codifica URL. 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 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:

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 CloudWatch Logs.

Problema: le tracce non vengono visualizzate in AWS X-Ray.

La funzione necessita dell'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: mancano log delle funzioni File di log CloudWatch, anche se le mie autorizzazioni sono corrette

Se il tuo Account AWS raggiunge i limiti di quota di File di log CloudWatch, il servizio limita la registrazione dei log delle funzioni. Quando ciò accade, alcuni log generati dalle funzioni potrebbero non apparire in File di log CloudWatch.

Gli output di log potrebbero non comparire in File di log CloudWatch anche nel caso in cui la funzione emetta log a una velocità troppo elevata per consentire a Lambda di elaborarli. Quando non è in grado di inviare i log a CloudWatch alla velocità in cui la funzione li produce, Lambda 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 in formato JSON, Lambda prova a inviare un evento logsDropped a CloudWatch Logs quando elimina i log. Tuttavia, se 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 il tuo Account AWS ha raggiunto i limiti di quota di File di log CloudWatch, procedi come segue:

Puoi anche impostare allarmi CloudWatch per avvisarti quando l'utilizzo dell'account supera un limite specificato per tali quote. Per ulteriori informazioni, consulta Creare un allarme CloudWatch basato su una soglia statica.

Se i limiti di quota predefiniti per File di log CloudWatch non sono sufficienti per il 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, tra cui AWS SDK, operano 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.

Esecuzione di una versione o di un alias di versione non previsti

Problema: la versione o l'alias della funzione non sono stati richiamati

Quando si pubblicano nuove funzioni Lambda nella console o utilizzando SAM, l'ultima versione del codice è rappresentata dall'alias $LATEST. Per impostazione predefinita, le chiamate che non specificano una versione o un alias indirizzano automaticamente alla $LATEST versione del codice della funzione.

Se usi versioni o alias di funzione specifici, oltre a queste si tratta di versioni pubblicate immutabili di una funzione. $LATEST Durante la risoluzione dei problemi relativi a queste funzioni, verifica innanzitutto che il chiamante abbia attivato 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 del log START:

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 termina mai. L'invocazione termina solo quando la funzione scade. È possibile identificarli monitorando i timeout e quindi correggendo il comportamento del ciclo.

Il secondo tipo di ciclo è tra le funzioni Lambda e altre risorse AWS. 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 a sua volta crea un'altra interazione con lo stesso bucket S3 e così via. Questi tipi di cicli possono essere causati da diverse origini eventi AWS, tra cui code Amazon SQS e tabelle DynamoDB. È possibile utilizzare il rilevamento ricorsivo dei loop per identificare questi schemi.

Puoi evitare questi cicli assicurandoti che le funzioni Lambda scrivano su risorse che non sono le stesse della risorsa che consuma e implementando interruttori automatici per schemi di cicli più complessi. Se devi pubblicare nuovamente i dati sulla risorsa che consuma, assicurati che i nuovi dati non attivino lo stesso evento, altrimenti la funzione Lambda potrà filtrare gli eventi. In alternativa, utilizzate il filtraggio 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, è necessario assicurarsi che siano in grado di gestire gli errori e i timeout del servizio. Queste risorse downstream possono avere tempi di risposta variabili o non essere disponibili a causa di interruzioni del servizio. A seconda dell'implementazione, questi errori a valle possono apparire come timeout o eccezioni della funzione Lambda, se la risposta all'errore del servizio non viene gestita all'interno del codice personalizzato della funzione.

Ogni volta che una funzione dipende da un servizio a valle, ad esempio una chiamata API, è necessario implementare una gestione degli errori e una logica di ripetizione dei tentativi appropriate. Per i servizi critici, la funzione Lambda deve pubblicare parametri o log su CloudWatch e quindi è possibile creare allarmi. Ad esempio, se un'API di pagamento di terze parti non è disponibile, una funzione Lambda può registrare queste informazioni, quindi gli allarmi CloudWatch possono inviarti una notifica. È quindi possibile configurare gli allarmi CloudWatch per inviare notifiche relative a questi errori.

Poiché il servizio Lambda è in grado di scalare rapidamente le chiamate, i servizi downstream non serverless potrebbero avere difficoltà a gestire i picchi di traffico. Esistono tre approcci comuni per gestire questo problema:

AWSSDK : versioni e aggiornamenti

Problema: l'SDK AWS incluso nel runtime non è l'ultima versione

Problema: l'SDK AWS incluso nel runtime si aggiorna automaticamente

I runtime per i linguaggi interpretati includono una versione dell'AWSSDK. Lambda aggiorna periodicamente questi runtime per utilizzare la versione SDK più recente. Per trovare la versione dell'SDK inclusa nel runtime, consulta le sezioni seguenti:

Per utilizzare una versione più recente dell'SDK AWS o per bloccare le funzioni a una versione specifica, è possibile raggruppare la libreria con il codice funzione o creare un livello Lambda. 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.