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 delle funzioni Lambda nell'ambiente reale AWS

Lambda fornisce una funzionalità di debug remoto tramite. AWS Toolkit for Visual Studio Code Per la configurazione e le istruzioni generali, consulta Esecuzione da remoto del debug delle funzioni Lambda con Visual Studio Code.

Per istruzioni dettagliate sulla risoluzione dei problemi, sui casi d'uso avanzati e sulla disponibilità regionale, consulta le funzioni di debug remoto di 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 il codice richiede molto più tempo per essere eseguito 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.

Lambda: payload per eventi imprevisti

Problema: errori di funzione legati a un 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 annidati.

Un 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 potrebbero 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: payload di dimensioni inaspettatamente elevate

Problema: le funzioni stanno scadendo o causano errori a causa di payload di grandi dimensioni.

Payload più grandi possono causare timeout ed errori. Consigliamo di creare test per garantire che la funzione gestisca i payload massimi previsti e 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 potrebbe 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 test case dovrebbero includere esempi relativi ai limiti superiori delle dimensioni dei dati previste. Il codice dovrebbe inoltre convalidare le dimensioni del payload.

Lambda: errori di codifica e decodifica JSON

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

Verifica 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 log non vengono visualizzati nei CloudWatch log.

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 log delle funzioni non sono presenti nei CloudWatch log, anche se le mie autorizzazioni sono corrette

Se Account AWS raggiungi i limiti della quota di CloudWatch Logs, limita la CloudWatch registrazione delle funzioni. In questo caso, alcuni dei log generati dalle tue funzioni potrebbero non essere visualizzati in Logs. CloudWatch

Se la tua funzione genera i log a una velocità troppo elevata perché Lambda possa elaborarli, ciò può anche far sì che gli output dei log non vengano visualizzati nei Logs. CloudWatch Quando Lambda non è in grado di inviare i log CloudWatch alla velocità con cui la funzione li produce, elimina i log 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 tua funzione è configurata per utilizzare log in formato JSON, Lambda tenta di inviare un 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 della quota di CloudWatch Logs, procedi come segue:

Puoi anche impostare CloudWatch allarmi per avvisarti quando l'utilizzo del tuo account supera il 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 log 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 viene restituita prima che il codice termini 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 il gestore di funzioni Lambda in Node.js.

Lambda: esecuzione di una versione o di un alias di una funzione non intenzionale

Problema: versione o alias della funzione non richiamato

Quando si pubblicano nuove funzioni Lambda nella console o utilizzando AWS SAM, la versione più recente del codice è rappresentata da. $LATEST Per impostazione predefinita, le invocazioni che non specificano una versione o un alias hanno come target automaticamente la $LATEST versione del codice della funzione.

Se utilizzi versioni o alias di funzioni specifici, oltre a queste si tratta di versioni pubblicate immutabili di una funzione. $LATEST Quando risolvete i problemi di queste funzioni, verificate innanzitutto che il chiamante abbia richiamato la versione o l'alias desiderato. Puoi farlo controllando i log delle funzioni. La versione della funzione richiamata è sempre mostrata nella riga del registro 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 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 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. Questo 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 dei loop per identificare questi pattern.

Puoi evitare questi cicli assicurandoti che le funzioni Lambda scrivano su risorse diverse dalla risorsa che la 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 i 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 a valle, 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 a valle potrebbero apparire come timeout o eccezioni di Lambda se la risposta all'errore del servizio non viene gestita all'interno del codice funzione.

Ogni volta che una funzione dipende da un servizio a valle, ad esempio una chiamata API, implementa una logica appropriata di gestione degli errori e riprova. Per i servizi critici, la funzione Lambda dovrebbe pubblicare metriche o registri 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 è scalabile 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: 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 tuo runtime, consulta le seguenti sezioni:

Per utilizzare una versione più recente dell' AWS SDK o per bloccare le funzioni su una versione specifica, puoi raggruppare la libreria con il tuo codice funzione o creare un layer 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 Comprendere la variabile di ambiente JAVA_TOOL_OPTIONS.

Kafka: problemi relativi alla gestione degli errori e ai nuovi tentativi di configurazione

Problema: la mappatura dell'origine degli eventi di Kafka non consente di configurare le impostazioni relative ai nuovi tentativi o le destinazioni in caso di errore

Le configurazioni dei nuovi tentativi di Kafka e le destinazioni in caso di errore sono disponibili solo per le mappature delle sorgenti di eventi con la modalità provisioned abilitata. Assicurati di aver effettuato la configurazione prima di tentare di impostare le configurazioni dei nuovi MinimumPollers tentativi. ProvisionedPollerConfig

Errori di configurazione comuni: