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à.
# Utilizzo dell'API Extensions di Lambda per creare estensioni
Gli autori di funzioni Lambda utilizzano le estensioni per integrare Lambda con gli strumenti preferiti per il monitoraggio, l'osservabilità, la sicurezza e la governance. Gli autori delle funzioni possono utilizzare estensioni di AWS, [AWS partner](extensions-api-partners.md) e progetti open source. Per ulteriori informazioni sull'utilizzo delle estensioni, consulta [Introducing AWS Lambda Extensions](https://aws.amazon.com/blogs/aws/getting-started-with-using-your-favorite-operational-tools-on-aws-lambda-extensions-are-now-generally-available/) on the AWS Compute Blog. In questa sezione viene descritto come utilizzare l'API di estensione Lambda, il ciclo di vita dell'ambiente di esecuzione Lambda e la documentazione di riferimento delle API di estensione Lambda.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
In qualità di autore dell'estensione, l'utente utilizzare l'API estensioni per ottenere un'integrazione profonda nell'[ambiente di esecuzione](lambda-runtime-environment.md) Lambda. L'estensione può registrarsi per funzioni ed eventi del ciclo di vita dell'ambiente di esecuzione. In risposta a questi eventi, è possibile avviare nuovi processi, eseguire la logica e controllare e partecipare a tutte le fasi del ciclo di vita di Lambda: inizializzazione, invocazione e arresto. Inoltre, è possibile utilizzare l'[API Log di runtime](runtimes-logs-api.md) per ricevere un flusso di log.
Un'estensione esterna viene eseguita come processo indipendente nell'ambiente di esecuzione e continua a funzionare anche dopo che la chiamata della funzione è stata completamente elaborata. Poiché le estensioni esterne vengono eseguite come processi, è possibile scriverle in un linguaggio diverso da quella della funzione. Si consiglia di implementare le estensioni utilizzando un linguaggio compilato. In questo caso, l'estensione è un binario autonomo compatibile con tutti i tempi di esecuzione supportati. Tutti i [Runtime Lambda](lambda-runtimes.md) supportano le estensioni. Se si utilizza un linguaggio non compilato, assicurarsi di includere un runtime compatibile nell'estensione.
Lambda supporta anche le *estensioni interne*. Un'estensione interna viene eseguita come thread separato nel processo di runtime. Il runtime avvia e arresta l'estensione interna. Un modo alternativo per integrarsi con l'ambiente Lambda consiste nell'utilizzare [variabili d'ambiente e script wrapper](runtimes-modify.md) specifici del linguaggio. Le estensioni interne consentono di configurare l'ambiente di runtime e modificare il comportamento di startup del processo di runtime.
È possibile aggiungere estensioni a una funzione in due modi. Per una funzione distribuita come [archivio di file con estensione zip](configuration-function-zip.md), è possibile distribuire l'estensione come [livello](chapter-layers.md). Per una funzione definita come immagine di container, [le estensioni](extensions-configuration.md#invocation-extensions-images) vengono aggiunte all'immagine del container.
**Nota**
Per esempio estensioni e script wrapper, consulta [AWS Lambda Extensions](https://github.com/aws-samples/aws-lambda-extensions) on the Samples repository. AWS GitHub
**Topics**
+ [
## Ciclo di vita dell'ambiente di esecuzione Lambda
](#runtimes-extensions-api-lifecycle)
+ [
## Riferimento all'API delle estensioni
](#runtimes-extensions-registration-api)
## Ciclo di vita dell'ambiente di esecuzione Lambda
Il ciclo di vita dell'ambiente di esecuzione prevede le seguenti fasi:
+ `Init`: in questa fase, Lambda crea o sblocca un ambiente di esecuzione con le risorse configurate, scarica il codice per la funzione e tutti i livelli, inizializza le estensioni, inizializza il runtime e quindi esegue il codice di inizializzazione della funzione (il codice al di fuori del gestore principale). La fase `Init` si verifica durante la prima invocazione o prima delle invocazioni di funzione se è stata abilitata la [concorrenza con provisioning](provisioned-concurrency.md).
La fase `Init` è suddivisa in tre sottofasi: `Extension init`, `Runtime init` e `Function init`. Queste sottofasi assicurano che tutte le estensioni e il runtime completino le loro attività di configurazione prima dell'esecuzione del codice della funzione.
+ `Invoke`: in questa fase, Lambda invoca il gestore della funzione. Dopo che la funzione è stata completata, Lambda si prepara a gestire un'altra invocazione di funzione.
+ `Shutdown`: questa fase viene attivata se la funzione Lambda non riceve alcuna invocazione per un certo periodo. Nella fase `Shutdown`, Lambda chiude il runtime, avvisa le estensioni per farle fermare in modo pulito, e poi rimuove l'ambiente. Lambda invia un evento `Shutdown` a ogni estensione; l'evento comunica all'estensione che l'ambiente sta per essere chiuso.
Ogni fase inizia con un evento da Lambda al runtime e a tutte le estensioni registrate. Il runtime e ogni estensione segnalano il completamento inviando una richiesta API `Next`. Lambda congela l'ambiente di esecuzione quando ogni processo è stato completato e non ci sono eventi in sospeso.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Overview-Full-Sequence.png)
**Topics**
+ [
### Fase di init
](#runtimes-extensions-api-reg)
+ [
### Invoca fase
](#runtimes-lifecycle-extensions-invoke)
+ [
### Fase di arresto
](#runtimes-lifecycle-extensions-shutdown)
+ [
### Autorizzazioni e configurazione
](#runtimes-extensions-registration-api-e)
+ [
### Gestione dei guasti
](#runtimes-extensions-api-failure)
+ [
### Risoluzione dei problemi delle estensioni
](#runtimes-extensions-api-trbl)
### Fase di init
Durante la fase `Extension init`, per ricevere gli eventi ogni estensione deve registrarsi con Lambda. Lambda utilizza il nome file completo dell'estensione per confermare che l'estensione abbia completato la sequenza di bootstrap. Pertanto, ogni chiamata `Register` API deve includere l'intestazione `Lambda-Extension-Name` con il nome file completo dell'estensione.
È possibile registrare fino a 10 estensioni per una funzione. Questo limite viene applicato tramite la chiamata `Register` API.
Dopo la registrazione di ogni estensione, Lambda inizia la fase `Runtime init`. Il processo di runtime chiama `functionInit` per avviare la fase `Function init`.
La fase `Init` viene completata dopo il runtime e ogni estensione registrata indica il completamento inviando una richiesta `Next` API.
**Nota**
Le estensioni possono completare la loro inizializzazione in qualsiasi punto della fase `Init`.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Init-Phase.png)
### Invoca fase
Quando viene richiamata una funzione Lambda in risposta a una richiesta API `Next`, Lambda invia un evento `Invoke` al runtime e a ogni estensione registrata per l'evento `Invoke`.
**Nota**
**Istanze gestite Lambda: le funzioni Extensions** for Lambda Managed Instances non possono registrarsi per l'evento. `Invoke` Poiché Lambda Managed Instances supporta chiamate simultanee all'interno di un singolo ambiente di esecuzione, l'evento non è supportato. `Invoke` Le estensioni possono registrarsi solo per l'evento. `Shutdown` Se devi tenere traccia dell'inizio e della fine delle chiamate, utilizza l'evento della `platform.report` piattaforma tramite l'API di [telemetria](telemetry-api.md).
Durante la chiamata, le estensioni esterne vengono eseguite in parallelo con la funzione. Continuano anche a funzionare dopo che la funzione è stata completata. In questo modo è possibile acquisire informazioni diagnostiche o inviare log, parametri e tracce in una posizione di propria scelta.
Dopo aver ricevuto la risposta della funzione dal runtime, Lambda restituisce la risposta al client, anche se le estensioni sono ancora in esecuzione.
La fase `Invoke` termina dopo il runtime e tutte le estensioni segnalano che vengono eseguite inviando una richiesta `Next` API.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Invoke-Phase.png)
**Payload evento**: l'evento inviato al runtime (e alla funzione Lambda) contiene l'intera richiesta, le intestazioni (ad esempio `RequestId`) e il payload. L'evento inviato a ciascuna estensione contiene metadati che descrivono il contenuto dell'evento. Questo evento del ciclo di vita include il tipo di evento, l'ora di timeout della funzione (`deadlineMs`), il `requestId`, la funzione richiamata Amazon Resource Name (ARN) e le intestazioni di traccia.
Le estensioni che desiderano accedere al corpo dell'evento funzione possono utilizzare un SDK in runtime che comunica con l'estensione. Gli sviluppatori di funzioni utilizzano l'SDK in runtime per inviare il payload all'estensione quando viene richiamata la funzione.
Ecco un esempio di payload:
```
{
"eventType": "INVOKE",
"deadlineMs": 676051,
"requestId": "3da1f2dc-3222-475e-9205-e2e6c6318895",
"invokedFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:ExtensionTest",
"tracing": {
"type": "X-Amzn-Trace-Id",
"value": "Root=1-5f35ae12-0c0fec141ab77a00bc047aa2;Parent=2be948a625588e32;Sampled=1"
}
}
```
**Duration limit (Limite di durata)**: l'impostazione di timeout della funzione limita la durata dell'intera fase `Invoke`. Ad esempio, se si imposta il timeout della funzione come 360 secondi, la funzione e tutte le estensioni devono essere completate entro 360 secondi. Si noti che non esiste una fase post-richiamo indipendente. La durata è la somma di tutto il tempo necessario per il completamento del runtime e di tutte le invocazioni delle estensioni e non viene calcolata fino a quando la funzione e tutte le estensioni non hanno terminato l'esecuzione.
**Impatto sulle prestazioni e sovraccarico di estensione**: le estensioni possono influire sulle prestazioni delle funzioni In qualità di autore dell'estensione, hai il controllo sull'impatto sulle prestazioni della tua estensione. Ad esempio, se una estensione svolge operazioni con uso intensivo dell'elaborazione, la durata della funzione aumenta poiché l'estensione e il codice della funzione condividono le stesse risorse della CPU. Inoltre, se l'estensione esegue operazioni estese al termine dell'invocazione della funzione, la durata della funzione aumenta perché la fase `Invoke` continua fino a quando tutte le estensioni non segnalano che sono state completate.
**Nota**
Lambda alloca la potenza della CPU in proporzione all'impostazione della memoria della funzione. Potresti avere una maggiore durata di esecuzione e inizializzazione a impostazioni di memoria inferiori perché i processi di funzione e estensione sono in concorrenza per le stesse risorse della CPU. Per ridurre la durata di esecuzione e inizializzazione, prova ad aumentare l'impostazione della memoria.
Per aiutare a identificare l'impatto sulle prestazioni introdotto dalle estensioni sulla fase `Invoke`, Lambda esegue l'output del parametro `PostRuntimeExtensionsDuration`. Questa metrica misura il tempo cumulativo trascorso tra la richiesta `Next` API runtime e l'ultima richiesta `Next` API di estensione. Per misurare l'aumento della memoria utilizzata, utilizzare la metrica `MaxMemoryUsed`. Per ulteriori informazioni sugli stati delle funzioni, consultare [Utilizzo dei parametri di CloudWatch Logs con Lambda](monitoring-metrics.md).
Gli sviluppatori di funzioni possono eseguire diverse versioni delle loro funzioni fianco a fianco per comprendere l'impatto di un'estensione specifica. Si consiglia agli autori di estensioni di pubblicare il consumo previsto di risorse per semplificare la scelta di un'estensione adatta per gli sviluppatori di funzioni.
### Fase di arresto
Quando Lambda sta per chiudere il runtime, invia uno `Shutdown` a ciascuna estensione esterna registrata. Le estensioni possono utilizzare questo tempo per le attività di pulizia finali. L'evento `Shutdown` viene inviato in risposta a una richiesta `Next` API.
**Limite di durata**: la durata massima della fase `Shutdown` dipende dalla configurazione delle estensioni registrate:
+ 0 ms: funzione senza estensioni registrate
+ 500 ms: funzione con estensione interna registrata
+ 2.000 ms: funzione con una o più estensioni esterne registrate
Se il runtime o un'estensione non risponde all'evento `Shutdown` entro il limite, Lambda termina il processo utilizzando un segnale `SIGKILL`.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Shutdown-Phase.png)
**Payload evento**: l'evento `Shutdown` contiene il motivo dell'arresto e il tempo rimanente in millisecondi.
`shutdownReason` include quanto segue:
+ SPINDOWN – Arresto normale
+ TIMEOUT – Timeout del limite di durata
+ FAILURE – Condizione di errore, ad esempio un evento `out-of-memory`
```
{
"eventType": "SHUTDOWN",
"shutdownReason": "reason for shutdown",
"deadlineMs": "the time and date that the function times out in Unix time milliseconds"
}
```
### Autorizzazioni e configurazione
Le estensioni vengono eseguite nello stesso ambiente di esecuzione della funzione Lambda. Inoltre, le estensioni condividono con la funzione risorse quali CPU, memoria e archiviazione `/tmp` su disco. Inoltre, le estensioni utilizzano lo stesso ruolo AWS Identity and Access Management (IAM) e lo stesso contesto di sicurezza della funzione.
**Autorizzazioni di accesso al file system e alla rete**: le estensioni vengono eseguite nello stesso file system e nello stesso spazio dei nomi dei nomi di rete del runtime della funzione. Ciò significa che le estensioni devono essere compatibili con il sistema operativo associato. Se un'estensione richiede ulteriori regole di traffico di rete in uscita, è necessario applicare tali regole alla configurazione della funzione.
**Nota**
Poiché la directory del codice funzione è di sola lettura, le estensioni non possono modificare il codice della funzione.
**Variabili di ambiente**: le estensioni possono accedere alle [variabili di ambiente](configuration-envvars.md), della funzione, ad eccezione delle seguenti variabili specifiche del processo di runtime:
+ `AWS_EXECUTION_ENV`
+ `AWS_LAMBDA_LOG_GROUP_NAME`
+ `AWS_LAMBDA_LOG_STREAM_NAME`
+ `AWS_XRAY_CONTEXT_MISSING`
+ `AWS_XRAY_DAEMON_ADDRESS`
+ `LAMBDA_RUNTIME_DIR`
+ `LAMBDA_TASK_ROOT`
+ `_AWS_XRAY_DAEMON_ADDRESS`
+ `_AWS_XRAY_DAEMON_PORT`
+ `_HANDLER`
**Nota**
**Rilevamento delle istanze gestite Lambda: le** estensioni possono controllare `AWS_LAMBDA_INITIALIZATION_TYPE` la variabile di ambiente per determinare se sono in esecuzione su istanze gestite Lambda anziché su funzioni Lambda (predefinite). Questo è il metodo consigliato alle estensioni per adattare il proprio comportamento in base al tipo di ambiente di esecuzione.
### Gestione dei guasti
**Errori di inizializzazione**: se un'estensione genera un errore, Lambda riavvia l'ambiente di esecuzione per imporre un comportamento coerente e per incoraggiare la risposta immediata agli errori per le estensioni. Inoltre, per alcuni clienti, le estensioni devono soddisfare esigenze mission-critical quali registrazione, sicurezza, governance e raccolta di dati di telemetria.
**Invocare errori** (come memoria esaurita, timeout funzione): poiché le estensioni condividono le risorse con il runtime, sono influenzata dall'esaurimento della memoria. Quando il runtime fallisce, tutte le estensioni e il runtime stesso partecipano alla fase `Shutdown`. Inoltre, il runtime viene riavviato automaticamente come parte dell'invocazione corrente o tramite un meccanismo di reinizializzazione differita.
Se si verifica un errore (ad esempio un timeout della funzione o un errore di runtime) durante `Invoke`, il servizio Lambda esegue un reset. Il reset si comporta come un evento `Shutdown`. Innanzitutto Lambda chiude il runtime, poi invia un evento `Shutdown` a ogni estensione esterna registrata. L'evento include il motivo dell'arresto. Se questo ambiente viene utilizzato per una nuova chiamata, l'estensione e il runtime vengono reinizializzati come parte della chiamata successiva.
![\[Esempio di ambiente di esecuzione: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Per una spiegazione più approfondita del diagramma precedente, consulta [Errori durante la fase di richiamo](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors).
**Registri delle estensioni**: Lambda invia l'output di registro delle estensioni CloudWatch a Logs. Lambda genera anche un evento di log aggiuntivo per ogni estensione durante `Init`. L'evento di log registra il nome e la preferenza di registrazione (evento, configurazione) in caso di successo o il motivo dell'errore in caso di errore.
### Risoluzione dei problemi delle estensioni
+ Se una richiesta `Register` non riesce, assicurarsi che l'intestazione `Lambda-Extension-Name` nella chiamata `Register` API contenga il nome file completo dell'estensione.
+ Se la richiesta `Register` non riesce per un'estensione interna, assicurarsi che la richiesta non si registra per l'evento `Shutdown`.
## Riferimento all'API delle estensioni
La specifica OpenAPI per le estensioni API versione **2020-01-01** è disponibile qui: [extensions-api.zip](samples/extensions-api.zip)
È possibile recuperare il valore dell'endpoint API dalla variabile di ambiente `AWS_LAMBDA_RUNTIME_API`. Per inviare una richiesta `Register`, utilizzare il prefisso `2020-01-01/` prima di ogni percorso API. Ad esempio:
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
```
**Topics**
+ [
### Registrati
](#extensions-registration-api-a)
+ [
### Next
](#extensions-api-next)
+ [
### Errore di init
](#runtimes-extensions-init-error)
+ [
### Errore di uscita
](#runtimes-extensions-exit-error)
### Registrati
Durante `Extension init`, per ricevere gli eventi tutte le estensioni devono registrarsi con Lambda. Lambda utilizza il nome file completo dell'estensione per confermare che l'estensione abbia completato la sequenza di bootstrap. Pertanto, ogni chiamata `Register` API deve includere l'intestazione `Lambda-Extension-Name` con il nome file completo dell'estensione.
Le estensioni interne vengono avviate e arrestate dal processo di runtime, pertanto non sono autorizzate a registrarsi per l'evento `Shutdown`.
**Percorso** – `/extension/register`
**Metodo** – **POST**
**Intestazioni della richiesta**
+ `Lambda-Extension-Name` – Il nome file completo dell'estensione. Campo obbligatorio: sì Tipo: stringa
+ `Lambda-Extension-Accept-Feature`: si utilizza per specificare le funzionalità opzionali delle estensioni durante la registrazione. Campo obbligatorio: no. Tipo: stringa separata da virgole. Funzionalità disponibili da specificare tramite questa impostazione:
+ `accountId`: se specificato, la risposta alla registrazione dell'estensione conterrà l'ID dell'account associato alla funzione Lambda per cui si sta registrando l'estensione.
**Parametri del corpo della richiesta**
+ `events` – Array degli eventi a cui registrarsi. Campo obbligatorio: no. Tipo: array di stringhe Stringhe valide: `INVOKE`, `SHUTDOWN`.
**Nota**
**Istanze gestite Lambda: le** funzioni Extensions for Lambda Managed Instances possono registrarsi solo per l'evento. `SHUTDOWN` Il tentativo di registrazione all'`INVOKE`evento genererà un errore. Questo perché Lambda Managed Instances supporta chiamate simultanee all'interno di un unico ambiente di esecuzione.
**Intestazioni di risposta**
+ `Lambda-Extension-Identifier` – Identificativo univoco dell'agente generato (stringa UUID) necessario per tutte le richieste successive.
**Codice di risposta**
+ 200 – Il corpo della risposta contiene il nome della funzione, la versione della funzione e il nome del gestore.
+ 400 – Richiesta non valida
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. L'estensione dovrebbe uscire tempestivamente.
**Example Esempio di corpo della richiesta**
```
{
'events': [ 'INVOKE', 'SHUTDOWN']
}
```
**Example Esempio di corpo della risposta**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler"
}
```
**Example Esempio di corpo della risposta con funzione accountId facoltativa**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler",
"accountId": "123456789012"
}
```
### Next
Le estensioni inviano una richiesta `Next` API per ricevere l'evento successivo, che può essere un evento `Invoke` o un evento `Shutdown`. Il corpo della risposta contiene il payload, che è un documento JSON che contiene i dati degli eventi.
L'estensione invia una richiesta `Next` API per segnalare che è pronta per ricevere nuovi eventi. Questa è una chiamata di blocco.
Non impostare un timeout sulla chiamata GET, poiché l'estensione può essere sospesa per un periodo di tempo fino a quando non c'è un evento da restituire.
**Percorso** – `/extension/event/next`
**Metodo** – **GET**
**Intestazioni della richiesta**
+ `Lambda-Extension-Identifier` – Identificativo univoco dell'estensione (stringa UUID). Campo obbligatorio: sì Tipo: stringa UUID.
**Intestazioni di risposta**
+ `Lambda-Extension-Event-Identifier`: identificatore univoco per l'evento (stringa UUID).
**Codice di risposta**
+ 200 – La risposta contiene informazioni sull'evento successivo (`EventInvoke` o `EventShutdown`).
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. L'estensione dovrebbe uscire tempestivamente.
### Errore di init
L'estensione utilizza questo metodo per segnalare un errore di inizializzazione a Lambda. Chiamalo quando l'estensione non riesce a inizializzare dopo che si è registrata. Dopo che Lambda riceve l'errore, le chiamate API successive hanno esito negativo. L'estensione dovrebbe terminare dopo aver ricevuto la risposta da Lambda.
**Percorso** – `/extension/init/error`
**Metodo** – **POST**
**Intestazioni della richiesta**
+ `Lambda-Extension-Identifier` – Identificativo univoco dell'estensione. Campo obbligatorio: sì Tipo: stringa UUID.
+ `Lambda-Extension-Function-Error-Type` – Tipo di errore rilevato dall'estensione. Campo obbligatorio: sì L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma si consiglia di utilizzare il formato . Esempio:
+ Estensione. NoSuchHandler
+ Estensione. APIKeyNotFound
+ Estensione. ConfigInvalid
+ Estensione. UnknownReason
**Parametri del corpo della richiesta**
+ `ErrorRequest` – Informazioni sull'errore. Campo obbligatorio: no.
Questo campo è un oggetto JSON con la seguente struttura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
NB: Lambda accetta qualsiasi valore per `errorType`.
Nell'esempio seguente viene mostrato un messaggio di errore della funzione Lambda in cui la funzione non è stata in grado di analizzare i dati evento forniti nell'invocazione.
**Example Errore di funzione**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Codice di risposta**
+ 202 – Accettato
+ 400 – Richiesta non valida
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. L'estensione dovrebbe uscire tempestivamente.
### Errore di uscita
L'estensione utilizza questo metodo per segnalare un errore a Lambda prima di uscire. Chiamalo quando incontri un errore inaspettato. Dopo che Lambda riceve l'errore, le chiamate API successive hanno esito negativo. L'estensione dovrebbe terminare dopo aver ricevuto la risposta da Lambda.
**Percorso** – `/extension/exit/error`
**Metodo** – **POST**
**Intestazioni della richiesta**
+ `Lambda-Extension-Identifier` – Identificativo univoco dell'estensione. Campo obbligatorio: sì Tipo: stringa UUID.
+ `Lambda-Extension-Function-Error-Type` – Tipo di errore rilevato dall'estensione. Campo obbligatorio: sì L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma si consiglia di utilizzare il formato . Esempio:
+ Estensione. NoSuchHandler
+ Estensione. APIKeyNotFound
+ Estensione. ConfigInvalid
+ Estensione. UnknownReason
**Parametri del corpo della richiesta**
+ `ErrorRequest` – Informazioni sull'errore. Campo obbligatorio: no.
Questo campo è un oggetto JSON con la seguente struttura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
NB: Lambda accetta qualsiasi valore per `errorType`.
Nell'esempio seguente viene mostrato un messaggio di errore della funzione Lambda in cui la funzione non è stata in grado di analizzare i dati evento forniti nell'invocazione.
**Example Errore di funzione**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Codice di risposta**
+ 202 – Accettato
+ 400 – Richiesta non valida
+ 403 – Non consentito
+ 500 – Errore del container. Stato non recuperabile. L'estensione dovrebbe uscire tempestivamente.