

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

# Aumentare le funzioni Lambda utilizzando le estensioni Lambda
<a name="lambda-extensions"></a>

È possibile utilizzare le estensioni Lambda per potenziare le funzioni Lambda. Ad esempio, utilizza le estensioni Lambda per integrare le funzioni con i tuoi strumenti di monitoraggio, osservabilità, sicurezza e governance preferiti. È possibile scegliere tra un ampio set di strumenti forniti dai [Partner AWS Lambda](https://aws.amazon.com/lambda/partners/) oppure [creare estensioni Lambda personalizzate](runtimes-extensions-api.md).

Lambda supporta estensioni interne ed esterne. Un'estensione esterna viene eseguita come processo indipendente nell'ambiente di esecuzione e continua a funzionare dopo che l'invocazione della funzione è completamente elaborata. Poiché le estensioni vengono eseguite come processi separati, è possibile scriverle in un linguaggio diverso da quello della funzione. Tutti i [Runtime Lambda](lambda-runtimes.md) supportano le estensioni.

Un'estensione interna viene eseguita come parte del processo di runtime. La funzione accede alle estensioni interne utilizzando script wrapper o meccanismi in-process come `JAVA_TOOL_OPTIONS`. Per ulteriori informazioni, consulta [Modifica dell'ambiente di runtime](runtimes-modify.md).

Puoi aggiungere estensioni a una funzione utilizzando la console Lambda, AWS Command Line Interface (AWS CLI) o servizi e strumenti infrastructure-as-code (IaC) come CloudFormation, AWS Serverless Application Model (AWS SAM) e Terraform.

Ti viene addebitato il runtime consumato dall'estensione (in incrementi di 1 ms). Non c'è alcun costo per installare le proprie estensioni. Per ulteriori informazioni sui prezzi delle estensioni, consulta la sezione [Prezzi AWS Lambda](https://aws.amazon.com/lambda/pricing/). Per informazioni sui prezzi per le estensioni dei partner, consulta i siti Web dei partner. Consulta [Partner con estensioni AWS Lambda](extensions-api-partners.md) per l'elenco delle estensioni ufficiali dei partner.

**Topics**
+ [

## Ambiente di esecuzione
](#using-extensions-env)
+ [

## Impatto su prestazioni e risorse
](#using-extensions-reg)
+ [

## Permissions
](#using-extensions-permissions)
+ [

# Configurazione delle estensioni Lambda
](extensions-configuration.md)
+ [

# Partner con estensioni AWS Lambda
](extensions-api-partners.md)
+ [

# Utilizzo dell'API Extensions di Lambda per creare estensioni
](runtimes-extensions-api.md)
+ [

# Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry
](telemetry-api.md)

## Ambiente di esecuzione
<a name="using-extensions-env"></a>

Lambda richiama la funzione in un [ambiente di esecuzione](lambda-runtime-environment.md), che fornisce un ambiente di runtime sicuro e isolato. L'ambiente di esecuzione gestisce le risorse necessarie per eseguire la funzione e fornisce il supporto del ciclo di vita per il runtime e le estensioni della funzione.

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.

  Quando [Lambda SnapStart](snapstart.md) è attivato, la fase `Init` si verifica quando si pubblica una versione della funzione. Lambda salva uno snapshot della memoria e dello stato del disco dell'ambiente di esecuzione inizializzato, mantiene lo snapshot crittografato e lo memorizza nella cache per l'accesso a bassa latenza. Se disponi di un [hook di runtime](snapstart-runtime-hooks.md) prima del checkpoint, il codice viene eseguito alla fine della fase `Init`.
+ `Restore`(SnapStart solo): Quando richiami una [SnapStart](snapstart.md)funzione per la prima volta e man mano che la funzione aumenta, Lambda riprende i nuovi ambienti di esecuzione dall'istantanea persistente invece di inizializzare la funzione da zero. Se disponi di un [hook di runtime](snapstart-runtime-hooks.md) dopo il ripristino, il codice viene eseguito alla fine della fase `Restore`. Ti sarà addebitata la durata degli hook di runtime dopo il ripristino. Il runtime deve essere caricato e gli hook di runtime dopo il ripristino devono essere completati entro il limite di timeout (10 secondi). SnapStartTimeoutExceptionAltrimenti, otterrai un. Al termine della fase `Restore`, Lambda chiama il gestore della funzione ([Invoca fase](lambda-runtime-environment.md#runtimes-lifecycle-invoke)).
+ `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.

Durante la fase `Init`, Lambda estrae i livelli contenenti estensioni nella directory `/opt` nell'ambiente di esecuzione. Lambda cerca le estensioni nella directory `/opt/extensions/`, interpreta ogni file come un bootstrap eseguibile per avviare l'estensione e avvia tutte le estensioni in parallelo.

## Impatto su prestazioni e risorse
<a name="using-extensions-reg"></a>

Le dimensioni delle estensioni della funzione vengono conteggiate per il limite di dimensioni del pacchetto di distribuzione. Per un archivio di file .zip, la dimensione totale decompressa della funzione e di tutte le estensioni non può superare il limite della dimensione decompressa del pacchetto di distribuzione pari a 250 MB.

Le estensioni possono influire sulle prestazioni della funzione perché condividono risorse funzionali quali CPU, memoria e archiviazione. Ad esempio, se un'estensione esegue operazioni ad alta intensità di calcolo, è possibile che la durata dell'esecuzione della funzione aumenti.

Ogni estensione deve completare la sua inizializzazione prima che Lambda richiami la funzione. Pertanto, un'estensione che consuma tempo di inizializzazione significativo può aumentare la latenza della chiamata di funzione.

Per misurare il tempo aggiuntivo impiegato dall'estensione dopo l'esecuzione della funzione, è possibile utilizzare la `PostRuntimeExtensionsDuration` [metrica della funzione](monitoring-metrics.md). Per misurare l'aumento della memoria utilizzata, è possibile utilizzare la metrica `MaxMemoryUsed`. Per comprendere l'impatto di un'estensione specifica, è possibile eseguire diverse versioni delle funzioni affiancate.

**Nota**  
La metrica `MaxMemoryUsed` è una delle [Metriche raccolte da Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-metrics.html) e non una metrica nativa di Lambda.

## Permissions
<a name="using-extensions-permissions"></a>

Le estensioni hanno accesso alle stesse risorse delle funzioni. Poiché le estensioni vengono eseguite nello stesso ambiente della funzione, le autorizzazioni vengono condivise tra la funzione e l'estensione.

Per un archivio di file.zip, puoi creare un CloudFormation modello per semplificare l'operazione di allegare la stessa configurazione di estensione, incluse le autorizzazioni AWS Identity and Access Management (IAM), a più funzioni.

# Configurazione delle estensioni Lambda
<a name="extensions-configuration"></a>

## Configurazione delle estensioni (archivio di file .zip)
<a name="using-extensions-config"></a>

È possibile aggiungere un'estensione alla funzione come [livello Lambda](chapter-layers.md). L'utilizzo dei livelli consente di condividere le estensioni all'interno dell'organizzazione o all'intera community di sviluppatori Lambda. È possibile aggiungere una o più estensioni a un livello. È possibile registrare fino a 10 estensioni per una funzione.

Si aggiunge l'estensione alla funzione utilizzando lo stesso metodo che si farebbe per qualsiasi livello. Per ulteriori informazioni, consulta [Gestione delle dipendenze Lambda con i livelli](chapter-layers.md).

**Aggiungi un'estensione alla tua funzione (console)**

1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.

1. Scegliere una funzione.

1. Seleziona la scheda **Codice** se non è già selezionata.

1. In **Livelli**, scegli **Modifica**.

1. Per **Scegli un livello**, scegliere **Specifica un ARN**.

1. In **Specifica un ARN**, inserire l'Amazon Resource Name (ARN) di un livello di estensione.

1. Scegli **Aggiungi**.

## Utilizzo delle estensioni nelle immagini di container
<a name="invocation-extensions-images"></a>

È possibile aggiungere estensioni all'[immagine di container](images-create.md). L'impostazione ENTRYPOINT dell'immagine di container specifica il processo principale per la funzione. Configurare l'impostazione ENTRYPOINT nel Dockerfile o come sostituzione nella configurazione della funzione. 

È possibile eseguire più processi all'interno di un container. Lambda gestisce il ciclo di vita del processo principale ed eventuali processi aggiuntivi. Lambda utilizza l'[API Estensioni](runtimes-extensions-api.md) per gestire il ciclo di vita dell'estensione. 

### Esempio: aggiunta di un'estensione esterna
<a name="extensions-images-ex1"></a>

Un'estensione esterna viene eseguita in un processo separato dalla funzione Lambda. Lambda avvia un processo per ogni estensione nella directory `/opt/extensions/`. Lambda utilizza l'API Estensioni per gestire il ciclo di vita dell'estensione. Dopo che la funzione è stata eseguita completamente, Lambda invia un evento `Shutdown` a ciascuna estensione esterna.

**Example di aggiungere un'estensione esterna a un'immagine di base Python**  

```
FROM public.ecr.aws/lambda/python:3.11

# Copy and install the app
COPY /app /app
WORKDIR /app
RUN pip install -r requirements.txt

# Add an extension from the local directory into /opt/extensions
ADD my-extension.zip /opt/extensions
CMD python ./my-function.py
```

## Passaggi successivi
<a name="using-extensions-next"></a>

Per ulteriori informazioni sulle estensioni, si consiglia di utilizzare le seguenti risorse:
+ Per un esempio di lavoro di base, consulta [Creazione di estensioni per AWS Lambda](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/) nel blog Compute di AWS.
+ Per informazioni sulle estensioni fornite dai partner AWS Lambda, consulta [Introduzione delle estensioni AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/) nel blog Compute di AWS.
+ Per visualizzare le estensioni di esempio e gli script wrapper disponibili, consulta le [Estensioni AWS Lambda](https://github.com/aws-samples/aws-lambda-extensions) negli esempi del repository AWS GitHub.

# Partner con estensioni AWS Lambda
<a name="extensions-api-partners"></a>

AWS Lambda ha collaborato con diverse entità di terze parti per fornire estensioni da integrare con le funzioni Lambda. L'elenco seguente descrive le estensioni di terze parti pronte all'uso in qualsiasi momento.
+ [https://docs.appdynamics.com/display/PRO20X/Use+the+AppDynamics+AWS+Lambda+Extension+to+Instrument+Serverless+APM+at+Runtime](https://docs.appdynamics.com/display/PRO20X/Use+the+AppDynamics+AWS+Lambda+Extension+to+Instrument+Serverless+APM+at+Runtime): fornisce la strumentazione automatica delle funzioni Node.js o Python Lambda, fornendo visibilità e avvisi sulle prestazioni delle funzioni.
+ [https://axiom.co/docs/apps/lambda](https://axiom.co/docs/apps/lambda): fornisce i pannelli di controllo per il monitoraggio delle prestazioni della funzione Lambda e i parametri aggregati a livello di sistema.
+ [https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/](https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/): fornisce visibilità completa e in tempo reale alle applicazioni serverless tramite l'uso di metriche, tracce e log.
+ [https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/integrations/deploy-oneagent-as-lambda-extension/](https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/integrations/deploy-oneagent-as-lambda-extension/): fornisce visibilità su tracce e metriche e sfrutta l'intelligenza artificiale per il rilevamento automatico degli errori e l'analisi delle cause principali nell'intero stack di applicazioni.
+ [https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html](https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html): fornisce il monitoraggio delle prestazioni delle applicazioni (APM) per identificare e risolvere i problemi principali utilizzando tracce, parametri e log correlati.
+ [https://docs.epsagon.com/docs/environment-monitoring/lambda/intro](https://docs.epsagon.com/docs/environment-monitoring/lambda/intro) – attende gli eventi di richiamo, memorizza le tracce e le invia in parallelo alle esecuzioni delle funzioni Lambda.
+ [https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/](https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/)– protegge le funzioni Lambda da attività sospette, come attacchi in stile iniezione, acquisizione di account tramite furto di credenziali, bot dannosi e abuso delle API.
+ [https://learn.hashicorp.com/tutorials/vault/aws-lambda](https://learn.hashicorp.com/tutorials/vault/aws-lambda) – gestisce i segreti e li rende disponibili affinché gli sviluppatori possano utilizzarli all'interno del codice della funzione, senza rendere le funzioni consapevoli di Vault.
+ [https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/](https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/) – strumento di osservabilità per il debug dello stack di app.
+ [https://docs.lumigo.io/docs/lambda-extensions](https://docs.lumigo.io/docs/lambda-extensions) – profila i richiami delle funzioni Lambda e raccoglie le metriche per la risoluzione dei problemi in ambienti serverless e di microservizi.
+ [https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/get-started/monitoring-aws-lambda-serverless-monitoring](https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/get-started/monitoring-aws-lambda-serverless-monitoring) – funziona insieme alle funzioni Lambda, raccogliendo, migliorando e trasportando automaticamente la telemetria alla piattaforma di osservabilità unificata di New Relic.
+ [https://docs.sedai.io/get-started/platform/optimization/aws/lambda](https://docs.sedai.io/get-started/platform/optimization/aws/lambda) – una piattaforma di gestione cloud autonoma, basata su AI/ML, che offre un'ottimizzazione continua per i team operativi del cloud per massimizzare i risparmi sui costi, le prestazioni e la disponibilità del cloud su larga scala.
+ [https://docs.sentry.io/platforms/javascript/guides/aws-lambda/](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/) – esegue la diagnostica, corregge e ottimizza le prestazioni delle funzioni Lambda.
+ [https://www.site24x7.com/help/aws/lambda-execution-logs.html](https://www.site24x7.com/help/aws/lambda-execution-logs.html) – ottiene osservabilità in tempo reale negli ambienti Lambda
+ [https://github.com/signalfx/splunk-otel-lambda](https://github.com/signalfx/splunk-otel-lambda) – raccoglie parametri ad alta risoluzione e bassa latenza per un monitoraggio efficiente ed efficace delle funzioni Lambda.
+ [https://help.sumologic.com/03Send-Data/Collect-from-Other-Data-Sources/Collect_AWS_Lambda_Logs_using_an_Extension](https://help.sumologic.com/03Send-Data/Collect-from-Other-Data-Sources/Collect_AWS_Lambda_Logs_using_an_Extension) – fornisce visibilità sullo stato e sulle prestazioni delle applicazioni serverless.
+ [Salt Security](https://salt.security/press-releases/salt-security-becomes-the-first-and-only-api-security-vendor-to-join-aws-lambda-ready-program?): semplifica la governance dello stato delle API e la sicurezza delle API per le funzioni Lambda attraverso la configurazione e il supporto automatizzati per diversi runtime.

## AWSEstensioni gestite da
<a name="aws-managed-extensions"></a>

AWS fornisce le proprie estensioni gestite, tra cui:
+ [AWSAppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html#appconfig-integration-lambda-extensions-enabling): utilizza flag di funzionalità e dati dinamici per aggiornare le funzioni Lambda. È inoltre possibile utilizzare questa estensione per aggiornare altre configurazioni dinamiche, come la limitazione e l'ottimizzazione delle operazioni. 
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/python-lambda-layers.html): migliora le prestazioni delle applicazioni e riduce i costi individuando la linea di codice più costosa di un'applicazione e fornendo consigli per migliorare il codice.
+ [CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html): monitora, risolve i problemi e ottimizza le prestazioni delle funzioni Lambda tramite dashboard automatizzati.
+ [AWS Distro for OpenTelemetry (ADOT)](https://aws.amazon.com/otel): consente alle funzioni di inviare dati di traccia ai servizi di monitoraggio di AWS come AWS X-Ray e alle destinazioni che supportano OpenTelemetry, come Honeycomb e Lightstep.
+ [AWS Parametri e segreti ](with-secrets-manager.md): recupera in modo sicuro i parametri da AWS Systems Manager Parameter Store e i segreti da Gestione dei segreti AWS Funzioni Lambda.

Per ulteriori esempi di estensioni e progetti dimostrativi, consultare [Estensioni AWS Lambda](https://github.com/aws-samples/aws-lambda-extensions).

# Utilizzo dell'API Extensions di Lambda per creare estensioni
<a name="runtimes-extensions-api"></a>

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
<a name="runtimes-extensions-api-lifecycle"></a>

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
<a name="runtimes-extensions-api-reg"></a>

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
<a name="runtimes-lifecycle-extensions-invoke"></a>

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
<a name="runtimes-lifecycle-extensions-shutdown"></a>

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
<a name="runtimes-extensions-registration-api-e"></a>

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
<a name="runtimes-extensions-api-failure"></a>

**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
<a name="runtimes-extensions-api-trbl"></a>
+ 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
<a name="runtimes-extensions-registration-api"></a>

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
<a name="extensions-registration-api-a"></a>

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
<a name="extensions-api-next"></a>

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
<a name="runtimes-extensions-init-error"></a>

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 <categoria.motivo>. 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
<a name="runtimes-extensions-exit-error"></a>

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 <categoria.motivo>. 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.

 

# Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry
<a name="telemetry-api"></a>

L'API Telemetry consente alle estensioni di ricevere dati di telemetria direttamente da Lambda. Durante l'inizializzazione e l'invocazione, Lambda acquisisce in automatico i dati di telemetria, tra cui log, parametri della piattaforma e tracce della piattaforma. L'API Telemetry consente alle estensioni di accedere a tali dati di telemetria direttamente da Lambda quasi in tempo reale.

All'interno dell'ambiente di esecuzione Lambda, puoi abbonare le estensioni Lambda ai flussi di telemetria. Dopo l'abbonamento, Lambda invia automaticamente tutti i dati di telemetria alle estensioni. Avrai quindi la flessibilità necessaria per elaborare, filtrare e inviare i dati alla tua destinazione preferita, come un bucket Amazon Simple Storage Service (Amazon S3) o un fornitore di strumenti di osservabilità di terze parti.

Il diagramma seguente mostra come l'API Extensions e l'API Telemetry connettono le estensioni a Lambda dall'interno dell'ambiente di esecuzione. Inoltre L'API Runtime collega il runtime e la funzione a Lambda.

![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/telemetry-api-concept-diagram.png)


**Importante**  
L'API di telemetria Lambda sostituisce l'API Lambda Logs. **Sebbene l'API Logs rimanga completamente funzionante, in futuro consigliamo di utilizzare solo l'API di telemetria. ** Puoi iscrivere la tua estensione a un flusso di telemetria utilizzando l'API di telemetria o l'API Logs. Dopo la sottoscrizione utilizzando uno di questi APIs, qualsiasi tentativo di sottoscrizione utilizzando l'altra API restituisce un errore.

**Requisiti della versione dello schema Lambda Managed Instances**  
Le istanze gestite Lambda supportano solo la versione `2025-01-29` dello schema dell'API di telemetria. **Quando ti iscrivi ai flussi di telemetria per le funzioni Managed Instance, devi utilizzarli nella richiesta di abbonamento.** `"schemaVersion": "2025-01-29"` L'utilizzo di versioni precedenti dello schema comporterà il rifiuto degli eventi da parte di Lambda.  
La versione `2025-01-29` dello schema è retrocompatibile e può essere utilizzata sia con le istanze gestite Lambda che con le funzioni Lambda (predefinite). Consigliamo di utilizzare questa versione per tutte le nuove estensioni per garantire la compatibilità tra entrambi i modelli di distribuzione.

Le estensioni possono utilizzare l'API di telemetria per sottoscrivere i tre diversi flussi di telemetria.
+ **Telemetria della piattaforma**: registri, metriche e tracce, che descrivono eventi ed errori relativi al ciclo di vita del runtime dell'ambiente di esecuzione, al ciclo di vita delle estensioni e alle chiamate delle funzioni.
+ **Log delle funzioni**: log personalizzati generati dal codice della funzione Lambda.
+ **Log di estensione**: i log personalizzati generati dal codice di estensione Lambda.

**Nota**  
Lambda invia log e metriche e tracce a X-Ray (se hai attivato il tracciamento) CloudWatch, anche se un'estensione si abbona ai flussi di telemetria.

**Topics**
+ [

## Creazione di estensioni tramite l'API di telemetria
](#telemetry-api-creating-extensions)
+ [

## Registrazione delle estensioni
](#telemetry-api-registration)
+ [

## Creazione di un listener di telemetria
](#telemetry-api-listener)
+ [

## Specifica di un protocollo di destinazione
](#telemetry-api-destination)
+ [

## Configurazione dell'utilizzo della memoria e del buffering
](#telemetry-api-buffering)
+ [

## Invio di una richiesta di sottoscrizione all'API di telemetria
](#telemetry-api-subscription)
+ [

## Messaggi dell'API di telemetria in entrata
](#telemetry-api-messages)
+ [

# Riferimento all'API di telemetria Lambda
](telemetry-api-reference.md)
+ [

# Riferimento allo schema `Event` dell'API di telemetria Lambda
](telemetry-schema-reference.md)
+ [

# Conversione degli oggetti dell'API di `Event` telemetria Lambda in Spans OpenTelemetry
](telemetry-otel-spans.md)
+ [

# Utilizzo dell'API Logs di Lambda
](runtimes-logs-api.md)

## Creazione di estensioni tramite l'API di telemetria
<a name="telemetry-api-creating-extensions"></a>

Le estensioni Lambda vengono eseguite come processi indipendenti nell'ambiente di esecuzione. L'esecuzione delle estensioni può proseguire dopo il completamento dell'invocazione della funzione. Poiché le estensioni vengono eseguite come processi separati, è possibile scriverle in un linguaggio diverso da quello del codice della funzione. Consigliamo di scrivere estensioni utilizzando un linguaggio compilato come Golang o Rust. In questo caso, l'estensione è un binario autonomo compatibile con qualsiasi runtime supportato.

Il diagramma seguente illustra un processo in quattro fasi per creare un'estensione che riceve ed elabora i dati di telemetria tramite l'API di telemetria.

![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/telemetry-api-creation-steps.png)


Ecco ogni fase in modo più dettagliato:

1. Registra la tua estensione utilizzando l'[Utilizzo dell'API Extensions di Lambda per creare estensioni](runtimes-extensions-api.md). Questo ti fornisce un `Lambda-Extension-Identifier`, di cui avrai bisogno nei passaggi seguenti. Per ulteriori informazioni su come eseguire la registrazione dell'estensione, consulta [Registrazione delle estensioni](#telemetry-api-registration).

1. Crea un listener di telemetria. Può trattarsi di un server HTTP o TCP di base. Lambda utilizza l'URI del listener di telemetria per inviare dati di telemetria all'estensione. Per ulteriori informazioni, consulta [Creazione di un listener di telemetria](#telemetry-api-listener).

1. Utilizzando l'API Subscribe nell'API Telemetry, esegui l'abbonamento all'estensione ai flussi di telemetria desiderati. Avrai bisogno dell'URI del tuo listener di telemetria per questo passaggio. Per ulteriori informazioni, consulta [Invio di una richiesta di sottoscrizione all'API di telemetria](#telemetry-api-subscription).

1. Ottieni dati di telemetria da Lambda tramite l'listener di telemetria. Puoi eseguire qualsiasi elaborazione personalizzata di questi dati, ad esempio inviandoli ad Amazon S3 o a un servizio di osservabilità esterno.

**Nota**  
L'ambiente di esecuzione di una funzione Lambda può avviarsi e interrompersi più volte nell'ambito del suo [ciclo di vita](runtimes-extensions-api.md#runtimes-extensions-api-lifecycle). In generale, il codice dell'estensione viene eseguito durante le chiamate delle funzioni e anche fino a 2 secondi durante la fase di spegnimento. Consigliamo di raggruppare i dati di telemetria non appena arrivano all'listener. Quindi, utilizza gli eventi del ciclo di vita `Invoke` e `Shutdown` per inviare ogni batch alle destinazioni desiderate.

## Registrazione delle estensioni
<a name="telemetry-api-registration"></a>

Prima di poter eseguire l'abbonamento ai dati di telemetria, devi registrare l'estensione Lambda. La registrazione avviene durante la [fase di inizializzazione dell'estensione](runtimes-extensions-api.md#runtimes-extensions-api-reg). L'esempio seguente mostra una richiesta HTTP per la registrazione di un'estensione.

```
POST http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
 Lambda-Extension-Name: lambda_extension_name
{
    'events': [ 'INVOKE', 'SHUTDOWN']
}
```

Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta riuscita HTTP 200. L'intestazione della risposta contiene l'`Lambda-Extension-Identifier`. Il corpo della risposta contiene altre proprietà della funzione.

```
HTTP/1.1 200 OK
Lambda-Extension-Identifier: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
{
    "functionName": "lambda_function",
    "functionVersion": "$LATEST",
    "handler": "lambda_handler",
    "accountId": "123456789012"
}
```

Per ulteriori informazioni, consulta [Riferimento all'API delle estensioni](runtimes-extensions-api.md#runtimes-extensions-registration-api).

## Creazione di un listener di telemetria
<a name="telemetry-api-listener"></a>

L'estensione Lambda deve disporre di un listener che gestisca le richieste in entrata dall'API di telemetria. Il codice seguente mostra un esempio di implementazione dell'listener di telemetria in Golang:

```
// Starts the server in a goroutine where the log events will be sent
func (s *TelemetryApiListener) Start() (string, error) {
	address := listenOnAddress()
	l.Info("[listener:Start] Starting on address", address)
	s.httpServer = &http.Server{Addr: address}
	http.HandleFunc("/", s.http_handler)
	go func() {
		err := s.httpServer.ListenAndServe()
		if err != http.ErrServerClosed {
			l.Error("[listener:goroutine] Unexpected stop on Http Server:", err)
			s.Shutdown()
		} else {
			l.Info("[listener:goroutine] Http Server closed:", err)
		}
	}()
	return fmt.Sprintf("http://%s/", address), nil
}

// http_handler handles the requests coming from the Telemetry API.
// Everytime Telemetry API sends log events, this function will read them from the response body
// and put into a synchronous queue to be dispatched later.
// Logging or printing besides the error cases below is not recommended if you have subscribed to
// receive extension logs. Otherwise, logging here will cause Telemetry API to send new logs for
// the printed lines which may create an infinite loop.
func (s *TelemetryApiListener) http_handler(w http.ResponseWriter, r *http.Request) {
	body, err := ioutil.ReadAll(r.Body)
	if err != nil {
		l.Error("[listener:http_handler] Error reading body:", err)
		return
	}

	// Parse and put the log messages into the queue
	var slice []interface{}
	_ = json.Unmarshal(body, &slice)

	for _, el := range slice {
		s.LogEventsQueue.Put(el)
	}

	l.Info("[listener:http_handler] logEvents received:", len(slice), " LogEventsQueue length:", s.LogEventsQueue.Len())
	slice = nil
}
```

## Specifica di un protocollo di destinazione
<a name="telemetry-api-destination"></a>

Quando esegui la sottoscrizione per ricevere la telemetria tramite l'API di telemetria, puoi specificare un protocollo di destinazione in aggiunta all'URI di destinazione:

```
{
    "destination": {
        "protocol": "HTTP",
        "URI": "http://sandbox.localdomain:8080"
    }
}
```

Lambda accetta due protocolli per la ricezione della telemetria:
+ **HTTP** (consigliato): Lambda consegna la telemetria a un endpoint HTTP locale (`http://sandbox.localdomain:${PORT}/${PATH}`) come matrice di record in formato JSON. Il parametro `$PATH` è facoltativo. Lambda supporta solo HTTP, non HTTPS. Lambda fornisce la telemetria tramite richieste POST.
+ **TCP**: Lambda consegna la telemetria a una porta TCP in [formato JSON delimitato da Newline (NDJSON)](https://github.com/ndjson/ndjson-spec).

**Nota**  
Si consiglia di utilizzare HTTP anziché TCP. Con TCP, la piattaforma Lambda non può riconoscere che la telemetria viene consegnata al livello dell'applicazione. Pertanto, se l'estensione si blocca si potrebbero perdere i dati di telemetria. HTTP non condivide questa limitazione.

Prima di eseguire l'abbonamento per i ricevere i dati di telemetria, definisci l'listener HTTP locale o la porta TCP. Durante l'installazione, tenere presente quanto segue:
+ Lambda invia la telemetria solo alle destinazioni che si trovano all'interno dell'ambiente di esecuzione.
+ Lambda riprova a inviare i dati di telemetria (con backoff) in assenza di un listener o se la richiesta POST subisce un errore. Se riporta un arresto anomalo, l'listener di telemetria continuerà a riceverla dopo che Lambda avrà riavviato l'ambiente di esecuzione.
+ Lambda riserva la porta 9001. Non ci sono altre restrizioni o raccomandazioni sul numero di porta.

## Configurazione dell'utilizzo della memoria e del buffering
<a name="telemetry-api-buffering"></a>

L'utilizzo della memoria in un ambiente di esecuzione aumenta linearmente con il numero di abbonati. Gli abbonamenti consumano risorse di memoria, perché ognuno apre un nuovo buffer di memoria per archiviare i dati di telemetria. L'utilizzo della memoria buffer contribuisce al consumo di memoria complessivo nell'ambiente di esecuzione.

Quando effettui l'abbonamento per ricevere la telemetria attraverso l'API Telemetry, hai la possibilità di eseguire il buffer dei dati di telemetria e consegnarli agli abbonati in batch. Per ottimizzare l'utilizzo della memoria, puoi specificare una configurazione di buffering:

```
{
    "buffering": {
        "maxBytes": 256*1024,
        "maxItems": 1000,
        "timeoutMs": 100
    }
}
```


| Parametro | Description | Valori predefiniti e limiti | 
| --- | --- | --- | 
|  `maxBytes`  |  Il volume massimo di dati di telemetria (in byte) da memorizzare nel buffer della memoria.  |  Predefinito: 262.144. Minimo: 262.144. Massimo: 1.048.576.  | 
|  `maxItems`  |  Il numero massimo di eventi da memorizzare nel buffer.  |  Predefinito: 10.000 Minimo: 1.000 Massimo: 10.000.  | 
|  `timeoutMs`  |  Il tempo massimo (in millisecondi) per memorizzare nel buffer un batch.  |  Predefinito: 1.000 Minimo: 25 Massimo: 30.000  | 

Quando configuri il buffering, tieni presente i seguenti punti:
+ Se uno qualsiasi dei flussi di input è chiuso, Lambda svuota i log. Ad esempio, ciò si può verificare quando il runtime subisce un arresto anomalo.
+ Ogni abbonato può personalizzare la configurazione di buffering nella richiesta di abbonamento.
+ Al momento di determinare la dimensione di buffer per la lettura dei dati, prevedi di ricevere payload di dimensioni pari a `2 * maxBytes + metadataBytes`, dove `maxBytes` è un componente della configurazione di buffering. Per valutare la quantità di `metadataBytes` da considerare, esamina i seguenti metadati. Lambda allega metadati simili a questi a ogni record:

  ```
  {
     "time": "2022-08-20T12:31:32.123Z",
     "type": "function",
     "record": "Hello World"
  }
  ```
+ Se il sottoscrittore non è in grado di elaborare la telemetria in ingresso abbastanza rapidamente o se il codice di funzione genera un volume di log molto elevato, Lambda potrebbe eliminare i registri per mantenere limitato l'utilizzo della memoria. Quando ciò si verifica, Lambda invia un evento `platform.logsDropped`.

## Invio di una richiesta di sottoscrizione all'API di telemetria
<a name="telemetry-api-subscription"></a>

Un'estensione Lambda può eseguire la sottoscrizione per ricevere i dati di telemetria inviando una richiesta di sottoscrizione all'API di telemetria. La richiesta di sottoscrizione deve contenere informazioni sui tipi di eventi a cui si desidera che l'estensione si iscriva. Inoltre, la richiesta può contenere [informazioni sulla destinazione della consegna](#telemetry-api-destination) e una [configurazione del buffering](#telemetry-api-buffering).

Prima di inviare una richiesta di sottoscrizione, è necessario disporre di un ID di estensione (`Lambda-Extension-Identifier`). Quando [registri l'estensione con l'API delle estensioni](#telemetry-api-registration), ottieni un ID di estensione dalla risposta dell'API.

La registrazione avviene durante la [fase di inizializzazione dell'estensione](runtimes-extensions-api.md#runtimes-extensions-api-reg). L'esempio seguente mostra una richiesta HTTP di sottoscrizione a tutti e tre i flussi di telemetria: telemetria della piattaforma, log delle funzioni e log delle estensioni.

```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1
{
   "schemaVersion": "2025-01-29",
   "types": [
        "platform",
        "function",
        "extension"
   ],
   "buffering": {
        "maxItems": 1000,
        "maxBytes": 256*1024,
        "timeoutMs": 100
   },
   "destination": {
        "protocol": "HTTP",
        "URI": "http://sandbox.localdomain:8080"
   }
}
```

Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta do operazione riuscita HTTP 200.

```
HTTP/1.1 200 OK
"OK"
```

## Messaggi dell'API di telemetria in entrata
<a name="telemetry-api-messages"></a>

Dopo l'abbonamento con l'API Telemetry, un'estensione comincia in automatico a ricevere i dati di telemetria da Lambda attraverso richieste POST. Ogni corpo di richiesta POST contiene una serie di oggetti `Event`. Ogni `Event` presenta il seguente schema:

```
{
   time: String,
   type: String,
   record: Object
}
```
+ La proprietà `time` definisce il momento in cui la piattaforma Lambda ha generato l'evento. Si tratta di un valore diverso da quando l'evento si è verificato effettivamente. Il valore della stringa di `time` è un timestamp nel formato ISO 8601.
+ La proprietà `type` definisce il tipo di evento. La seguente tabella riporta tutti i valori possibili.
+ La proprietà `record` definisce un oggetto JSON che contiene i dati di telemetria. Lo schema di questo oggetto JSON dipende dal `type`.

**Ordinamento degli eventi con invocazioni simultanee**  
Per le [istanze gestite Lambda, le](lambda-managed-instances.md) chiamate di più funzioni possono essere eseguite contemporaneamente all'interno dello stesso ambiente di esecuzione. In questo caso, l'ordine degli `platform.start` `platform.report` eventi non è garantito tra diverse chiamate simultanee. Le estensioni devono gestire gli eventi di più chiamate in esecuzione in parallelo e non devono presupporre un ordinamento sequenziale.  
Per attribuire correttamente gli eventi a chiamate specifiche, le estensioni devono utilizzare il `requestId` campo presente in questi eventi della piattaforma. Ogni chiamata ha un ID di richiesta univoco che rimane coerente in tutti gli eventi di quella chiamata, consentendo alle estensioni di correlare correttamente gli eventi anche quando arrivano fuori ordine.

La tabella seguente riassume tutti i tipi di oggetti `Event` e i collegamenti al [riferimento dello schema `Event` dell'API di telemetria](telemetry-schema-reference.md) per ogni tipo di evento.


| Categoria | Tipo di evento | Description | Schema dei registri di eventi | 
| --- | --- | --- | --- | 
|  Evento della piattaforma  |  `platform.initStart`  |  Inizializzazione della funzione avviata.  |  Schema [`platform.initStart`](telemetry-schema-reference.md#platform-initStart)  | 
|  Evento della piattaforma  |  `platform.initRuntimeDone`  |  Inizializzazione della funzione completata.  |  Schema [`platform.initRuntimeDone`](telemetry-schema-reference.md#platform-initRuntimeDone)  | 
|  Evento della piattaforma  |  `platform.initReport`  |  Un rapporto sull'inizializzazione della funzione.  |  Schema [`platform.initReport`](telemetry-schema-reference.md#platform-initReport)  | 
|  Evento della piattaforma  |  `platform.start`  |  L'invocazione della funzione è stata avviata.  |  Schema [`platform.start`](telemetry-schema-reference.md#platform-start)  | 
|  Evento della piattaforma  |  `platform.runtimeDone`  |  Il runtime ha terminato l'elaborazione di un evento con esito positivo o negativo.  |  Schema [`platform.runtimeDone`](telemetry-schema-reference.md#platform-runtimeDone)  | 
|  Evento della piattaforma  |  `platform.report`  |  Un rapporto sull'invocazione di una funzione.  |  Schema [`platform.report`](telemetry-schema-reference.md#platform-report)  | 
|  Evento della piattaforma  |  `platform.restoreStart`  |  Il ripristino del runtime è iniziato.  |  Schema [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart)  | 
|  Evento della piattaforma  |  `platform.restoreRuntimeDone`  |  Il ripristino del runtime è stato completato.  |  Schema [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone)  | 
|  Evento della piattaforma  |  `platform.restoreReport`  |  Rapporto di ripristino del runtime.  |  Schema [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport)  | 
|  Evento della piattaforma  |  `platform.telemetrySubscription`  |  L'estensione che ha eseguito la sottoscrizione all'API di telemetria.  |  Schema [`platform.telemetrySubscription`](telemetry-schema-reference.md#platform-telemetrySubscription)  | 
|  Evento della piattaforma  |  `platform.logsDropped`  |  Lambda ha eliminato le voci del log.  |  Schema [`platform.logsDropped`](telemetry-schema-reference.md#platform-logsDropped)  | 
|  Log delle funzioni  |  `function`  |  Una riga del log dal codice della funzione.  |  Schema [`function`](telemetry-schema-reference.md#telemetry-api-function)  | 
|  Log di estensioni  |  `extension`  |  Una riga di log dal codice dell'estensione.  |  Schema [`extension`](telemetry-schema-reference.md#telemetry-api-extension)  | 

# Riferimento all'API di telemetria Lambda
<a name="telemetry-api-reference"></a>

Utilizza l'endpoint dell'API di telemetria Lambda per sottoscrivere le estensioni ai flussi di telemetria. È possibile recuperare l'endpoint dell'API di telemetria dalla variabile di ambiente `AWS_LAMBDA_RUNTIME_API`. Per inviare una richiesta API, aggiungi la versione dell'API (`2022-07-01/`) e `telemetry/`. Esempio:

```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```

Per la definizione della specifica OpenAPI (OAS) della versione delle risposte alla sottoscrizione `2025-01-29`, consulta quanto segue:
+ **HTTP** — [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **TCP** [— .zip telemetry-api-tcp-schema](samples/events_tcp_schema_v2025_01_29.zip)

**Topics**
+ [

## Subscribe
](#telemetry-subscribe-api)

## Subscribe
<a name="telemetry-subscribe-api"></a>

Per sottoscrivere un flusso di telemetria, un'estensione Lambda può inviare una richiesta API Subscribe.
+ **Percorso** – `/telemetry`
+ **Metodo**: `PUT`
+ **Headers**
  + `Content-Type`: `application/json`
+ **Parametri del corpo della richiesta**
  + **schemaVersion**
    + Obbligatorio: sì
    + Tipo: String
    + Valori validi: `"2025-01-29"`, `"2022-12-13"` o `"2022-07-01"`
    + **Nota:** le istanze gestite Lambda richiedono. `"2025-01-29"` Questa versione è retrocompatibile con le funzioni Lambda (predefinite).
  + **destinazione**: le impostazioni di configurazione che definiscono la destinazione dell'evento di telemetria e il protocollo per la consegna degli eventi.
    + Obbligatorio: sì
    + Tipo: oggetto

      ```
      {
          "protocol": "HTTP",
          "URI": "http://sandbox.localdomain:8080"
      }
      ```
    + **protocollo**: il protocollo utilizzato da Lambda per inviare dati di telemetria.
      + Obbligatorio: sì
      + Tipo: String
      + Valori validi: `"HTTP"`\$1`"TCP"`
    + **URI**: l'URI a cui inviare i dati di telemetria.
      + Obbligatorio: sì
      + Tipo: String
    + Per ulteriori informazioni, consulta [Specifica di un protocollo di destinazione](telemetry-api.md#telemetry-api-destination).
  + **tipi**: i tipi di dati di telemetria che desideri siano sottoscritti dall'estensione.
    + Obbligatorio: sì
    + Tipo: array di stringhe
    + Valori validi: `"platform"`\$1`"function"`\$1`"extension"`
  + **buffering**: le impostazioni di configurazione per il buffering degli eventi.
    + Obbligatorio: no
    + Tipo: oggetto

      ```
      {
         "buffering": {
              "maxItems": 1000,
              "maxBytes": 256*1024,
              "timeoutMs": 100
         }
      }
      ```
    + **maxItems** – Il numero massimo di eventi da memorizzare nel buffer.
      + Obbligatorio: no
      + Tipo: numero intero
      + Predefinito: 1.000
      + Minimo: 1.000
      + Massimo: 10.000.
    + **maxBytes**: il volume massimo di dati di telemetria (in byte) da memorizzare nel buffer della memoria.
      + Obbligatorio: no
      + Tipo: numero intero
      + Predefinito: 262.144.
      + Minimo: 262.144.
      + Massimo: 1.048.576.
    + **timeoutMs** – Il tempo massimo (in millisecondi) per il buffer di un batch.
      + Obbligatorio: no
      + Tipo: numero intero
      + Predefinito: 1.000
      + Minimo: 25
      + Massimo: 30.000
    + Per ulteriori informazioni, consulta [Configurazione dell'utilizzo della memoria e del buffering](telemetry-api.md#telemetry-api-buffering).

### Esempio di richiesta API Subscribe
<a name="telemetry-subscribe-api-example"></a>

```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1
{
   "schemaVersion": "2025-01-29",
   "types": [
        "platform",
        "function",
        "extension"
   ],
   "buffering": {
        "maxItems": 1000,
        "maxBytes": 256*1024,
        "timeoutMs": 100
   },
   "destination": {
        "protocol": "HTTP",
        "URI": "http://sandbox.localdomain:8080"
   }
}
```

Se la richiesta Subscribe ha esito positivo, il sottoscrittore riceve una risposta di operazione riuscita HTTP 200.

```
HTTP/1.1 200 OK
"OK"
```

Se la richiesta non riesce, l'estensione riceve una risposta di errore. Esempio:

```
HTTP/1.1 400 OK
{
    "errorType": "ValidationError",
    "errorMessage": "URI port is not provided; types should not be empty"
}
```

Ecco alcuni codici di risposta aggiuntivi che l'estensione può ricevere:
+ 200 – Richiesta completata con successo
+ 202 – Richiesta accettata. Risposta alla richiesta di sottoscrizione nell'ambiente di test locale
+ 400: richiesta non valida
+ 500 – Errore servizio

# Riferimento allo schema `Event` dell'API di telemetria Lambda
<a name="telemetry-schema-reference"></a>

Utilizza l'endpoint dell'API di telemetria Lambda per sottoscrivere le estensioni ai flussi di telemetria. È possibile recuperare l'endpoint dell'API di telemetria dalla variabile di ambiente `AWS_LAMBDA_RUNTIME_API`. Per inviare una richiesta API, aggiungi la versione dell'API (`2022-07-01/`) e `telemetry/`. Esempio:

```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```

Per la definizione della specifica OpenAPI (OAS) della versione delle risposte alla sottoscrizione `2025-01-29`, consulta quanto segue:
+ **HTTP** — [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **TCP** [— .zip telemetry-api-tcp-schema](samples/events_tcp_schema_v2025_01_29.zip)

La tabella seguente è un riepilogo di tutti i tipi di oggetti `Event` supportati dall'API di telemetria.


| Categoria | Tipo di evento | Description | Schema dei registri di eventi | 
| --- | --- | --- | --- | 
|  Evento della piattaforma  |  `platform.initStart`  |  Inizializzazione della funzione avviata.  |  Schema [`platform.initStart`](#platform-initStart)  | 
|  Evento della piattaforma  |  `platform.initRuntimeDone`  |  Inizializzazione della funzione completata.  |  Schema [`platform.initRuntimeDone`](#platform-initRuntimeDone)  | 
|  Evento della piattaforma  |  `platform.initReport`  |  Un rapporto sull'inizializzazione della funzione.  |  Schema [`platform.initReport`](#platform-initReport)  | 
|  Evento della piattaforma  |  `platform.start`  |  L'invocazione della funzione è stata avviata.  |  Schema [`platform.start`](#platform-start)  | 
|  Evento della piattaforma  |  `platform.runtimeDone`  |  Il runtime ha terminato l'elaborazione di un evento con esito positivo o negativo.  |  Schema [`platform.runtimeDone`](#platform-runtimeDone)  | 
|  Evento della piattaforma  |  `platform.report`  |  Un rapporto sull'invocazione di una funzione.  |  Schema [`platform.report`](#platform-report)  | 
|  Evento della piattaforma  |  `platform.restoreStart`  |  Il ripristino del runtime è iniziato.  |  Schema [`platform.restoreStart`](#platform-restoreStart)  | 
|  Evento della piattaforma  |  `platform.restoreRuntimeDone`  |  Il ripristino del runtime è stato completato.  |  Schema [`platform.restoreRuntimeDone`](#platform-restoreRuntimeDone)  | 
|  Evento della piattaforma  |  `platform.restoreReport`  |  Rapporto di ripristino del runtime.  |  Schema [`platform.restoreReport`](#platform-restoreReport)  | 
|  Evento della piattaforma  |  `platform.telemetrySubscription`  |  L'estensione che ha eseguito la sottoscrizione all'API di telemetria.  |  Schema [`platform.telemetrySubscription`](#platform-telemetrySubscription)  | 
|  Evento della piattaforma  |  `platform.logsDropped`  |  Lambda ha eliminato le voci del log.  |  Schema [`platform.logsDropped`](#platform-logsDropped)  | 
|  Log delle funzioni  |  `function`  |  Una riga del log dal codice della funzione.  |  Schema [`function`](#telemetry-api-function)  | 
|  Log di estensioni  |  `extension`  |  Una riga di log dal codice dell'estensione.  |  Schema [`extension`](#telemetry-api-extension)  | 

**Contents**
+ [

## Tipi di oggetti `Event` dell'API di telemetria
](#telemetry-api-events)
  + [

### `platform.initStart`
](#platform-initStart)
  + [

### `platform.initRuntimeDone`
](#platform-initRuntimeDone)
  + [

### `platform.initReport`
](#platform-initReport)
  + [

### `platform.start`
](#platform-start)
  + [

### `platform.runtimeDone`
](#platform-runtimeDone)
  + [

### `platform.report`
](#platform-report)
  + [

### `platform.restoreStart`
](#platform-restoreStart)
  + [

### `platform.restoreRuntimeDone`
](#platform-restoreRuntimeDone)
  + [

### `platform.restoreReport`
](#platform-restoreReport)
  + [

### `platform.extension`
](#platform-extension)
  + [

### `platform.telemetrySubscription`
](#platform-telemetrySubscription)
  + [

### `platform.logsDropped`
](#platform-logsDropped)
  + [

### `function`
](#telemetry-api-function)
  + [

### `extension`
](#telemetry-api-extension)
+ [

## Tipi di oggetti condivisi
](#telemetry-api-objects)
  + [

### `InitPhase`
](#InitPhase)
  + [

### `InitReportMetrics`
](#InitReportMetrics)
  + [

### `InitType`
](#InitType)
  + [

### `ReportMetrics`
](#ReportMetrics)
  + [

### `RestoreReportMetrics`
](#RestoreReportMetrics)
  + [

### `RuntimeDoneMetrics`
](#RuntimeDoneMetrics)
  + [

### `Span`
](#Span)
  + [

### `Status`
](#Status)
  + [

### `TraceContext`
](#TraceContext)
  + [

### `TracingType`
](#TracingType)

## Tipi di oggetti `Event` dell'API di telemetria
<a name="telemetry-api-events"></a>

Questa sezione descrive in dettaglio i tipi di oggetti `Event` supportati dall'API di telemetria Lambda. Nelle descrizioni degli eventi, un punto interrogativo (`?`) indica che l'attributo potrebbe non essere presente nell'oggetto.

### `platform.initStart`
<a name="platform-initStart"></a>

Un evento `platform.initStart` indica che la fase di inizializzazione della funzione è stata avviata. Un oggetto `platform.initStart` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.initStart
- record: PlatformInitStart
```

L'oggetto `PlatformInitStart` ha i seguenti attributi:
+ **functionName**: `String`
+ **functionVersion**: `String`
+ **initializationType**: oggetto ``InitType``
+ **instanceId?**: `String`
+ **instanceMaxMemory?** – `Integer`
+ **phase**: oggetto ``InitPhase``
+ **runtimeVersion?**: `String`
+ **runtimeVersionArn?** – `String`

Di seguito è riportato un esempio `Event` di tipo `platform.initStart`:

```
{
    "time": "2022-10-12T00:00:15.064Z",
    "type": "platform.initStart",
    "record": {
        "initializationType": "on-demand",
        "phase": "init",
        "runtimeVersion": "nodejs-14.v3",
        "runtimeVersionArn": "arn",
        "functionName": "myFunction",
        "functionVersion": "$LATEST",
        "instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
        "instanceMaxMemory": 256
    }
}
```

### `platform.initRuntimeDone`
<a name="platform-initRuntimeDone"></a>

Un evento `platform.initRuntimeDone` indica che la fase di inizializzazione della funzione è stata completata. Un oggetto `platform.initRuntimeDone` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.initRuntimeDone
- record: PlatformInitRuntimeDone
```

L'oggetto `PlatformInitRuntimeDone` ha i seguenti attributi:
+ **initializationType**: oggetto ``InitType``
+ **phase**: oggetto ``InitPhase``
+ **status**: oggetto ``Status``
+ **spans?** : elenco di oggetti ``Span``

Di seguito è riportato un esempio `Event` di tipo `platform.initRuntimeDone`:

```
{
    "time": "2022-10-12T00:01:15.000Z",
    "type": "platform.initRuntimeDone",
    "record": {
        "initializationType": "on-demand"
        "status": "success",
        "spans": [
            {
                "name": "someTimeSpan",
                "start": "2022-06-02T12:02:33.913Z",
                "durationMs": 70.5
            }
        ]
    }
}
```

### `platform.initReport`
<a name="platform-initReport"></a>

Un evento `platform.initReport` contiene un rapporto generale della fase di inizializzazione della funzione. Un oggetto `platform.initReport` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.initReport
- record: PlatformInitReport
```

L'oggetto `PlatformInitReport` ha i seguenti attributi:
+ **errorType?**: stringa
+ **initializationType**: oggetto ``InitType``
+ **phase**: oggetto ``InitPhase``
+ **metrics**: oggetto ``InitReportMetrics``
+ **spans?** : elenco di oggetti ``Span``
+ **status**: oggetto ``Status``

Di seguito è riportato un esempio `Event` di tipo `platform.initReport`:

```
{
    "time": "2022-10-12T00:01:15.000Z",
    "type": "platform.initReport",
    "record": {
        "initializationType": "on-demand",
        "status": "success",
        "phase": "init",
        "metrics": {
            "durationMs": 125.33
        },
        "spans": [
            {
                "name": "someTimeSpan",
                "start": "2022-06-02T12:02:33.913Z",
                "durationMs": 90.1
            }
        ]
    }
}
```

### `platform.start`
<a name="platform-start"></a>

Un evento `platform.start` indica che la fase di invocazione della funzione è stata avviata. Un oggetto `platform.start` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.start
- record: PlatformStart
```

L'oggetto `PlatformStart` ha i seguenti attributi:
+ **requestId**: `String`
+ **version?**: `String`
+ **tracing?**: ``TraceContext``

Di seguito è riportato un esempio `Event` di tipo `platform.start`:

```
{
    "time": "2022-10-12T00:00:15.064Z",
    "type": "platform.start",
    "record": {
        "requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
        "version": "$LATEST",
        "tracing": {
            "spanId": "54565fb41ac79632",
            "type": "X-Amzn-Trace-Id",
            "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
        }
    }
}
```

### `platform.runtimeDone`
<a name="platform-runtimeDone"></a>

Un evento `platform.runtimeDone` indica che la fase di invocazione della funzione è stata completata. Un oggetto `platform.runtimeDone` `Event` ha la seguente forma:

**Istanze gestite Lambda**  
L'`platform.runtimeDone`evento non è supportato per le istanze gestite Lambda. Le estensioni in esecuzione su istanze gestite non riceveranno questo evento perché le estensioni non possono sottoscrivere l'`INVOKE`evento sulle istanze gestite. A causa del modello di esecuzione simultanea in cui è possibile elaborare più chiamate contemporaneamente, le estensioni non possono eseguire l'elaborazione post-invoca per le singole chiamate come avviene tradizionalmente con le funzioni Lambda (predefinite).  
Per le istanze gestite, gli intervalli `responseLatency` e `responseDuration` gli intervalli normalmente inclusi sono invece disponibili nell'evento. `platform.runtimeDone` `platform.report` Per informazioni dettagliate, vedi [`platform.report`](#platform-report).

```
Event: Object
- time: String
- type: String = platform.runtimeDone
- record: PlatformRuntimeDone
```

L'oggetto `PlatformRuntimeDone` ha i seguenti attributi:
+ **errorType?**: `String`
+ **metrics?**: oggetto ``RuntimeDoneMetrics``
+ **requestId**: `String`
+ **status**: oggetto ``Status``
+ **spans?** : elenco di oggetti ``Span``
+ **tracing?**: oggetto ``TraceContext``

Di seguito è riportato un esempio `Event` di tipo `platform.runtimeDone`:

```
{
    "time": "2022-10-12T00:01:15.000Z",
    "type": "platform.runtimeDone",
    "record": {
        "requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
        "status": "success",
        "tracing": {
            "spanId": "54565fb41ac79632",
            "type": "X-Amzn-Trace-Id",
            "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
        },
        "spans": [
            {
                "name": "someTimeSpan",
                "start": "2022-08-02T12:01:23:521Z",
                "durationMs": 80.0
            }
        ],
        "metrics": {
            "durationMs": 140.0,
            "producedBytes": 16
        }
    }
}
```

### `platform.report`
<a name="platform-report"></a>

Un evento `platform.report` contiene un rapporto generale della fase di invocazione della funzione. Un oggetto `platform.report` `Event` ha la seguente forma:

**Istanze gestite Lambda**  
L'`platform.report`evento per Lambda Managed Instances ha metriche e intervalli diversi rispetto alle funzioni Lambda (predefinite). Per le istanze gestite:  
**Spans**: contiene `responseLatency` e `responseDuration` invece di. `extensionOverhead` Lo `extensionOverhead` span non è disponibile perché le estensioni non possono sottoscrivere l'`INVOKE`evento su Managed Instances a causa del modello di esecuzione simultanea.
**Metriche**: include solo. `durationMs` Le seguenti metriche non sono incluse:`billedDurationMs`, `initDurationMs``maxMemoryUsedMB`, e. `memorySizeMB` Queste metriche per richiamo non sono applicabili nell'ambiente di esecuzione simultanea. [Per le metriche sull'utilizzo delle risorse, usa o [Monitoraggio delle istanze gestite da Lambda](lambda-managed-instances-monitoring.md) Lambda Insights.](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html)

```
Event: Object
- time: String
- type: String = platform.report
- record: PlatformReport
```

L'oggetto `PlatformReport` ha i seguenti attributi:
+ **metrics**: oggetto ``ReportMetrics``
+ **requestId**: `String`
+ **spans?** : elenco di oggetti ``Span``
+ **status**: oggetto ``Status``
+ **tracing?**: oggetto ``TraceContext``

Di seguito è riportato un esempio `Event` di tipo `platform.report`:

```
{
    "time": "2022-10-12T00:01:15.000Z",
    "type": "platform.report",
    "record": {
        "metrics": {
            "billedDurationMs": 694,
            "durationMs": 693.92,
            "initDurationMs": 397.68,
            "maxMemoryUsedMB": 84,
            "memorySizeMB": 128
        },
        "requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
    }
}
```

### `platform.restoreStart`
<a name="platform-restoreStart"></a>

Un evento `platform.restoreStart` indica che un evento di ripristino dell'ambiente della funzione è stato avviato. In un evento di ripristino dell'ambiente, Lambda crea l'ambiente da uno snapshot memorizzato nella cache anziché inizializzarlo da zero. Per ulteriori informazioni, consulta [Lambda SnapStart](snapstart.md). Un oggetto `platform.restoreStart` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.restoreStart
- record: PlatformRestoreStart
```

L'oggetto `PlatformRestoreStart` ha i seguenti attributi:
+ **functionName**: `String`
+ **functionVersion**: `String`
+ **instanceId?**: `String`
+ **instanceMaxMemory?** – `String`
+ **runtimeVersion?**: `String`
+ **runtimeVersionArn?** – `String`

Di seguito è riportato un esempio `Event` di tipo `platform.restoreStart`:

```
{
    "time": "2022-10-12T00:00:15.064Z",
    "type": "platform.restoreStart",
    "record": {
        "runtimeVersion": "nodejs-14.v3",
        "runtimeVersionArn": "arn",
        "functionName": "myFunction",
        "functionVersion": "$LATEST",
        "instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
        "instanceMaxMemory": 256
    }
}
```

### `platform.restoreRuntimeDone`
<a name="platform-restoreRuntimeDone"></a>

Un evento `platform.restoreRuntimeDone` indica che un evento di ripristino dell'ambiente della funzione è stato completato. In un evento di ripristino dell'ambiente, Lambda crea l'ambiente da uno snapshot memorizzato nella cache anziché inizializzarlo da zero. Per ulteriori informazioni, consulta [Lambda SnapStart](snapstart.md). Un oggetto `platform.restoreRuntimeDone` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.restoreRuntimeDone
- record: PlatformRestoreRuntimeDone
```

L'oggetto `PlatformRestoreRuntimeDone` ha i seguenti attributi:
+ **errorType?**: `String`
+ **spans?** : elenco di oggetti ``Span``
+ **status**: oggetto ``Status``

Di seguito è riportato un esempio `Event` di tipo `platform.restoreRuntimeDone`:

```
{
    "time": "2022-10-12T00:00:15.064Z",
    "type": "platform.restoreRuntimeDone",
    "record": {
        "status": "success",
        "spans": [
            {
                "name": "someTimeSpan",
                "start": "2022-08-02T12:01:23:521Z",
                "durationMs": 80.0
            }
        ]
    }
}
```

### `platform.restoreReport`
<a name="platform-restoreReport"></a>

Un evento `platform.restoreReport` contiene un rapporto generale di un evento di ripristino della funzione. Un oggetto `platform.restoreReport` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.restoreReport
- record: PlatformRestoreReport
```

L'oggetto `PlatformRestoreReport` ha i seguenti attributi:
+ **errorType?**: stringa
+ **metrics?**: oggetto ``RestoreReportMetrics``
+ **spans?** : elenco di oggetti ``Span``
+ **status**: oggetto ``Status``

Di seguito è riportato un esempio `Event` di tipo `platform.restoreReport`:

```
{
    "time": "2022-10-12T00:00:15.064Z",
    "type": "platform.restoreReport",
    "record": {
        "status": "success",
        "metrics": {
            "durationMs": 15.19
        },
        "spans": [
            {
                "name": "someTimeSpan",
                "start": "2022-08-02T12:01:23:521Z",
                "durationMs": 30.0
            }
        ]
    }
}
```

### `platform.extension`
<a name="platform-extension"></a>

Un evento `extension` contiene i log del codice dell'estensione. Un oggetto `extension` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = extension
- record: {}
```

L'oggetto `PlatformExtension` ha i seguenti attributi:
+ **events**: elenco di `String`
+ **name**: `String`
+ **state**: `String`

Di seguito è riportato un esempio `Event` di tipo `platform.extension`:

```
{
    "time": "2022-10-12T00:02:15.000Z",
    "type": "platform.extension",
    "record": {
        "events": [ "INVOKE", "SHUTDOWN" ],
        "name": "my-telemetry-extension",
        "state": "Ready"
    }
}
```

### `platform.telemetrySubscription`
<a name="platform-telemetrySubscription"></a>

Un evento `platform.telemetrySubscription` contiene informazioni su una sottoscrizione dell'estensione. Un oggetto `platform.telemetrySubscription` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.telemetrySubscription
- record: PlatformTelemetrySubscription
```

L'oggetto `PlatformTelemetrySubscription` ha i seguenti attributi:
+ **name**: `String`
+ **state**: `String`
+ **tipi**: elenco di `String`

Di seguito è riportato un esempio `Event` di tipo `platform.telemetrySubscription`:

```
{
    "time": "2022-10-12T00:02:35.000Z",
    "type": "platform.telemetrySubscription",
    "record": {
        "name": "my-telemetry-extension",
        "state": "Subscribed",
        "types": [ "platform", "function" ]
    }
}
```

### `platform.logsDropped`
<a name="platform-logsDropped"></a>

Un evento `platform.logsDropped` contiene informazioni sugli eventi eliminati. Quando una funzione genera log a una velocità troppo elevata per consentire a Lambda di elaborarli, Lambda emette l'evento `platform.logsDropped`. Quando Lambda non è in grado di inviare log a CloudWatch o verso l'estensione sottoscritta all'API di telemetria alla velocità di produzione della funzione, elimina i log per evitare che l'esecuzione della funzione rallenti. Un oggetto `platform.logsDropped` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = platform.logsDropped
- record: PlatformLogsDropped
```

L'oggetto `PlatformLogsDropped` ha i seguenti attributi:
+ **droppedBytes**: `Integer`
+ **droppedRecords**: `Integer`
+ **reason**: `String`

Di seguito è riportato un esempio `Event` di tipo `platform.logsDropped`:

```
{
    "time": "2022-10-12T00:02:35.000Z",
    "type": "platform.logsDropped",
    "record": {
        "droppedBytes": 12345,
        "droppedRecords": 123,
        "reason": "Some logs were dropped because the downstream consumer is slower than the logs production rate"
    }
}
```

### `function`
<a name="telemetry-api-function"></a>

Un evento `function` contiene i log del codice della funzione. Un oggetto `function` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = function
- record: {}
```

Il formato del campo `record` dipende dal fatto che i log della funzione siano formattati in testo normale o JSON. Per ulteriori informazioni sulle opzioni di configurazione del formato dei log, consulta la pagina [Configurazione dei formati di log JSON e testo normale](monitoring-cloudwatchlogs-logformat.md)

Di seguito è riportato un esempio di `Event` di tipo `function` in cui il formato di log è il testo normale:

```
{
    "time": "2022-10-12T00:03:50.000Z",
    "type": "function",
    "record": "[INFO] Hello world, I am a function!"
}
```

Di seguito è riportato un esempio di `Event` di tipo `function` in cui il formato di log è JSON:

```
{
    "time": "2022-10-12T00:03:50.000Z",
    "type": "function",
    "record": {
        "timestamp": "2022-10-12T00:03:50.000Z",
        "level": "INFO",
        "requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
        "message": "Hello world, I am a function!"
    }
}
```

**Nota**  
Se la versione dello schema che stai utilizzando è precedente alla versione `2022-12-13`, il `"record"` viene sempre visualizzato come stringa anche quando il formato di registrazione della funzione è configurato come JSON. Per le istanze gestite Lambda, è necessario utilizzare la versione dello schema. `2025-01-29`

### `extension`
<a name="telemetry-api-extension"></a>

Un evento `extension` contiene i log del codice dell'estensione. Un oggetto `extension` `Event` ha la seguente forma:

```
Event: Object
- time: String
- type: String = extension
- record: {}
```

Il formato del campo `record` dipende dal fatto che i log della funzione siano formattati in testo normale o JSON. Per ulteriori informazioni sulle opzioni di configurazione del formato dei log, consulta la pagina [Configurazione dei formati di log JSON e testo normale](monitoring-cloudwatchlogs-logformat.md)

Di seguito è riportato un esempio di `Event` di tipo `extension` in cui il formato di log è il testo normale:

```
{
    "time": "2022-10-12T00:03:50.000Z",
    "type": "extension",
    "record": "[INFO] Hello world, I am an extension!"
}
```

Di seguito è riportato un esempio di `Event` di tipo `extension` in cui il formato di log è JSON:

```
{
    "time": "2022-10-12T00:03:50.000Z",
    "type": "extension",
    "record": {
       "timestamp": "2022-10-12T00:03:50.000Z",
       "level": "INFO",
       "requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
       "message": "Hello world, I am an extension!"
    }    
}
```

**Nota**  
Se la versione dello schema che stai utilizzando è precedente alla versione `2022-12-13`, il `"record"` viene sempre visualizzato come stringa anche quando il formato di registrazione della funzione è configurato come JSON. Per le istanze gestite Lambda, è necessario utilizzare la versione dello schema. `2025-01-29`

## Tipi di oggetti condivisi
<a name="telemetry-api-objects"></a>

Questa sezione descrive in dettaglio i tipi di oggetti condivisi supportati dall'API di telemetria Lambda.

### `InitPhase`
<a name="InitPhase"></a>

Una stringa enum che descrive la fase in cui si verifica l'operazione di inizializzazione. Nella maggior parte dei casi, Lambda esegue il codice di inizializzazione della funzione durante la fase `init`. Tuttavia, in alcuni casi di errore, Lambda può eseguire nuovamente il codice di inizializzazione della funzione durante la fase `invoke`. (Questa è chiamata *init soppressa*.)
+ **Tipo**: `String`
+ **Valori validi**: `init`\$1`invoke`\$1`snap-start`

### `InitReportMetrics`
<a name="InitReportMetrics"></a>

Un oggetto che contiene parametri relativi a una fase di inizializzazione.
+ **Tipo**: `Object`

Un oggetto `InitReportMetrics` ha la seguente forma:

```
InitReportMetrics: Object
- durationMs: Double
```

Di seguito è illustrato un esempio di oggetto `InitReportMetrics` di esempio:

```
{
    "durationMs": 247.88
}
```

### `InitType`
<a name="InitType"></a>

Una stringa enum che descrive come Lambda ha inizializzato l'ambiente.
+ **Tipo**: `String`
+ **Valori validi**: `on-demand`\$1`provisioned-concurrency`

### `ReportMetrics`
<a name="ReportMetrics"></a>

Un oggetto che contiene i parametri di una fase completata.
+ **Tipo**: `Object`

Un oggetto `ReportMetrics` ha la seguente forma:

```
ReportMetrics: Object
- billedDurationMs: Integer
- durationMs: Double
- initDurationMs?: Double
- maxMemoryUsedMB: Integer
- memorySizeMB: Integer
- restoreDurationMs?: Double
```

Di seguito è illustrato un esempio di oggetto `ReportMetrics` di esempio:

```
{
    "billedDurationMs": 694,
    "durationMs": 693.92,
    "initDurationMs": 397.68,
    "maxMemoryUsedMB": 84,
    "memorySizeMB": 128
}
```

### `RestoreReportMetrics`
<a name="RestoreReportMetrics"></a>

Un oggetto che contiene i parametri di una fase di ripristino completata.
+ **Tipo**: `Object`

Un oggetto `RestoreReportMetrics` ha la seguente forma:

```
RestoreReportMetrics: Object
- durationMs: Double
```

Di seguito è illustrato un esempio di oggetto `RestoreReportMetrics` di esempio:

```
{
    "durationMs": 15.19
}
```

### `RuntimeDoneMetrics`
<a name="RuntimeDoneMetrics"></a>

Un oggetto che contiene parametri relativi a una fase di chiamata.
+ **Tipo**: `Object`

Un oggetto `RuntimeDoneMetrics` ha la seguente forma:

```
RuntimeDoneMetrics: Object
- durationMs: Double
- producedBytes?: Integer
```

Di seguito è illustrato un esempio di oggetto `RuntimeDoneMetrics` di esempio:

```
{
    "durationMs": 200.0,
    "producedBytes": 15
}
```

### `Span`
<a name="Span"></a>

Un oggetto che contiene i dettagli di un intervallo. Un intervallo rappresenta un'unità di lavoro o un'operazione in una traccia. Per ulteriori informazioni sugli span, consulta [Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span) nella pagina **Tracing API** del sito Web di Docs. OpenTelemetry 

Lambda supporta i seguenti intervalli per l'evento `platform.RuntimeDone`:
+ L'intervallo `responseLatency` descrive il tempo impiegato dalla funzione Lambda per iniziare a inviare la risposta.
+ L'intervallo `responseDuration` descrive il tempo impiegato dalla funzione Lambda per finire di inviare la risposta.
+ L'intervallo `runtimeOverhead` descrive il tempo impiegato dal runtime di Lambda per segnalare che è pronto per l'elaborazione del richiamo successivo della funzione. Questo è il tempo impiegato dal runtime per il richiamo dell'API dell'[invocazione successiva](runtimes-api.md#runtimes-api-next) per ottenere l'evento successivo dopo aver restituito la risposta della funzione.

Di seguito è illustrato un oggetto di intervallo `responseLatency` di esempio:

```
{
        "name": "responseLatency", 
        "start": "2022-08-02T12:01:23.521Z",
        "durationMs": 23.02
      }
```

### `Status`
<a name="Status"></a>

Un oggetto che descrive lo stato di una fase di inizializzazione o invocazione. Se lo stato è `failure` o `error`, l'oggetto `Status`contiene anche un campo `errorType` che descrive l'errore.
+ **Tipo**: `Object`
+ **Valori di stato validi**: `success`\$1`failure`\$1`error`\$1`timeout`

### `TraceContext`
<a name="TraceContext"></a>

Un oggetto che descrive le proprietà di una traccia.
+ **Tipo**: `Object`

Un oggetto `TraceContext` ha la seguente forma:

```
TraceContext: Object
- spanId?: String
- type: TracingType enum
- value: String
```

Di seguito è illustrato un esempio di oggetto `TraceContext` di esempio:

```
{
    "spanId": "073a49012f3c312e",
    "type": "X-Amzn-Trace-Id",
    "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
```

### `TracingType`
<a name="TracingType"></a>

Una stringa enum che descrive il tipo di tracciamento in un oggetto ``TraceContext``.
+ **Tipo**: `String`
+ **Valori validi**: `X-Amzn-Trace-Id`

# Conversione degli oggetti dell'API di `Event` telemetria Lambda in Spans OpenTelemetry
<a name="telemetry-otel-spans"></a>

Lo schema dell'API di AWS Lambda telemetria è semanticamente compatibile con (). OpenTelemetry OTel Ciò significa che puoi convertire gli oggetti dell'API di AWS Lambda telemetria in () Spans. `Event` OpenTelemetry OTel Durante la conversione, non dovreste mappare un singolo `Event` oggetto su un singolo Span. OTel Dovreste invece presentare tutti e tre gli eventi relativi a una fase del ciclo di vita in un unico Span. OTel Ad esempio, gli eventi `start`, `runtimeDone` e `runtimeReport`rappresentano una singola chiamata di funzione. Presentate tutti e tre questi eventi come un unico Span. OTel 

Puoi convertire i tuoi eventi usando Span Events o Child Spans (nidificati). Le tabelle in questa pagina descrivono le mappature tra le proprietà dello schema dell'API di telemetria e OTel le proprietà Span per entrambi gli approcci. **Per ulteriori informazioni su OTel Spans, consulta [Span nella pagina Tracing API del sito Web](https://opentelemetry.io/docs/reference/specification/trace/api/#span) Docs.** OpenTelemetry 

**Topics**
+ [

## Mappa su Spans with Span OTel Events
](#telemetry-otel-span-events)
+ [

## Mappa su OTel Spans with Child Spans
](#telemetry-otel-child-spans)

## Mappa su Spans with Span OTel Events
<a name="telemetry-otel-span-events"></a>

Nelle seguenti tabelle, `e` rappresenta l'evento proveniente dall'origine di telemetria.

**Mappatura degli eventi \$1Start**


| OpenTelemetry | Schema dell'API di telemetria Lambda | 
| --- | --- | 
|  `Span.Name`  |  La tua estensione genera questo valore in base al campo `type`.  | 
|  `Span.StartTime`  |  Utilizza `e.time`.  | 
|  `Span.EndTime`  |  N/D, perché l'evento non è ancora stato completato.  | 
|  `Span.Kind`  |  Imposta su `Server`.  | 
|  `Span.Status`  |  Imposta su `Unset`.  | 
|  `Span.TraceId`  |  Analizza l' AWS X-Ray intestazione trovata in`e.tracing.value`, quindi usa il valore. `TraceId`  | 
|  `Span.ParentId`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Parent`.  | 
|  `Span.SpanId`  |  Usa `e.tracing.spanId` se disponibile. Altrimenti, genera un nuovo `SpanId`.  | 
|  `Span.SpanContext.TraceState`  |  N/D per un contesto di traccia X-Ray.  | 
|  `Span.SpanContext.TraceFlags`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Sampled`.  | 
|  `Span.Attributes`  |  La tua estensione può aggiungere qualsiasi valore personalizzato qui.  | 

**Mappatura degli eventi \$1 RuntimeDone **


| OpenTelemetry | Schema dell'API di telemetria Lambda | 
| --- | --- | 
|  `Span.Name`  |  L'estensione genera il valore in base al campo `type`.  | 
|  `Span.StartTime`  |  Usa `e.time` dall'evento `*Start` corrispondente. In alternativa, utilizzare `e.time - e.metrics.durationMs`.  | 
|  `Span.EndTime`  |  N/D, perché l'evento non è ancora stato completato.  | 
|  `Span.Kind`  |  Imposta su `Server`.  | 
|  `Span.Status`  |  Se `e.status` non è uguale a `success`, imposta su `Error`. In caso contrario, imposta il valore su `Ok`.  | 
|  `Span.Events[]`  |  Utilizza `e.spans[]`.  | 
|  `Span.Events[i].Name`  |  Utilizza `e.spans[i].name`.  | 
|  `Span.Events[i].Time`  |  Utilizza `e.spans[i].start`.  | 
|  `Span.TraceId`  |  Analizza l' AWS X-Ray intestazione trovata in`e.tracing.value`, quindi usa il valore. `TraceId`  | 
|  `Span.ParentId`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Parent`.  | 
|  `Span.SpanId`  |  Usa lo stesso `SpanId` dell'evento `*Start`. Se non disponibile, usa `e.tracing.spanId` o genera un nuovo `SpanId`.  | 
|  `Span.SpanContext.TraceState`  |  N/D per un contesto di traccia X-Ray.  | 
|  `Span.SpanContext.TraceFlags`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Sampled`.  | 
|  `Span.Attributes`  |  La tua estensione può aggiungere qualsiasi valore personalizzato qui.  | 

**Mappatura degli eventi \$1Report**


| OpenTelemetry | Schema dell'API di telemetria Lambda | 
| --- | --- | 
|  `Span.Name`  |  L'estensione genera il valore in base al campo `type`.  | 
|  `Span.StartTime`  |  Usa `e.time` dall'evento `*Start` corrispondente. In alternativa, utilizzare `e.time - e.metrics.durationMs`.  | 
|  `Span.EndTime`  |  Utilizza `e.time`.  | 
|  `Span.Kind`  |  Imposta su `Server`.  | 
|  `Span.Status`  |  Usa lo stesso valore dell'evento `*RuntimeDone`.  | 
|  `Span.TraceId`  |  Analizza l' AWS X-Ray intestazione trovata in`e.tracing.value`, quindi usa il valore. `TraceId`  | 
|  `Span.ParentId`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Parent`.  | 
|  `Span.SpanId`  |  Usa lo stesso `SpanId` dell'evento `*Start`. Se non disponibile, usa `e.tracing.spanId` o genera un nuovo `SpanId`.  | 
|  `Span.SpanContext.TraceState`  |  N/D per un contesto di traccia X-Ray.  | 
|  `Span.SpanContext.TraceFlags`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Sampled`.  | 
|  `Span.Attributes`  |  La tua estensione può aggiungere qualsiasi valore personalizzato qui.  | 

## Mappa su OTel Spans with Child Spans
<a name="telemetry-otel-child-spans"></a>

La tabella seguente descrive come convertire gli eventi dell'API Lambda Telemetry in OTel Spans with Child (nested) Spans for Spans. `*RuntimeDone` Per le mappature `*Start` e `*Report`, fai riferimento alle tabelle in [Mappa su Spans with Span OTel Events](#telemetry-otel-span-events), poiché sono le stesse per gli intervalli secondari. In questa tabella, `e` rappresenta l'evento proveniente dall'origine di telemetria.

**Mappatura degli eventi\$1 RuntimeDone **


| OpenTelemetry | Schema dell'API di telemetria Lambda | 
| --- | --- | 
|  `Span.Name`  |  L'estensione genera il valore in base al campo `type`.  | 
|  `Span.StartTime`  |  Usa `e.time` dall'evento `*Start` corrispondente. In alternativa, utilizzare `e.time - e.metrics.durationMs`.  | 
|  `Span.EndTime`  |  N/D, perché l'evento non è ancora stato completato.  | 
|  `Span.Kind`  |  Imposta su `Server`.  | 
|  `Span.Status`  |  Se `e.status` non è uguale a `success`, imposta su `Error`. In caso contrario, imposta il valore su `Ok`.  | 
|  `Span.TraceId`  |  Analizza l' AWS X-Ray intestazione trovata in`e.tracing.value`, quindi usa il valore. `TraceId`  | 
|  `Span.ParentId`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Parent`.  | 
|  `Span.SpanId`  |  Usa lo stesso `SpanId` dell'evento `*Start`. Se non disponibile, usa `e.tracing.spanId` o genera un nuovo `SpanId`.  | 
|  `Span.SpanContext.TraceState`  |  N/D per un contesto di traccia X-Ray.  | 
|  `Span.SpanContext.TraceFlags`  |  Analizza l'intestazione X-Ray trovata in `e.tracing.value`, quindi usa il valore `Sampled`.  | 
|  `Span.Attributes`  |  La tua estensione può aggiungere qualsiasi valore personalizzato qui.  | 
|  `ChildSpan[i].Name`  |  Utilizza `e.spans[i].name`.  | 
|  `ChildSpan[i].StartTime`  |  Utilizza `e.spans[i].start`.  | 
|  `ChildSpan[i].EndTime`  |  Utilizza `e.spans[i].start + e.spans[i].durations`.  | 
|  `ChildSpan[i].Kind`  |  Uguale all'elemento padre `Span.Kind`.  | 
|  `ChildSpan[i].Status`  |  Uguale all'elemento padre `Span.Status`.  | 
|  `ChildSpan[i].TraceId`  |  Uguale all'elemento padre `Span.TraceId`.  | 
|  `ChildSpan[i].ParentId`  |  Usa elemento padre `Span.SpanId`.  | 
|  `ChildSpan[i].SpanId`  |  Genera un nuovo `SpanId`.  | 
|  `ChildSpan[i].SpanContext.TraceState`  |  N/D per un contesto di traccia X-Ray.  | 
|  `ChildSpan[i].SpanContext.TraceFlags`  |  Uguale all'elemento padre `Span.SpanContext.TraceFlags`.  | 

# Utilizzo dell'API Logs di Lambda
<a name="runtimes-logs-api"></a>

**Importante**  
L'API di telemetria Lambda sostituisce l'API Lambda Logs. **Sebbene l'API Logs rimanga completamente funzionante, in futuro consigliamo di utilizzare solo l'API di telemetria. ** Puoi iscrivere la tua estensione a un flusso di telemetria utilizzando l'API di telemetria o l'API Logs. Dopo la sottoscrizione utilizzando una di queste APIs, qualsiasi tentativo di sottoscrizione utilizzando l'altra API restituisce un errore.

**Le istanze gestite Lambda non supportano l'API Logs**  
Le istanze gestite Lambda non supportano l'API Logs. Se utilizzi le funzioni di istanze gestite, utilizza invece l'API di [telemetria](telemetry-api.md). L'API di telemetria offre funzionalità avanzate per la raccolta e l'elaborazione dei dati di telemetria dalle funzioni Lambda.

Lambda acquisisce automaticamente i log di runtime e li trasmette ad Amazon. CloudWatch Questo flusso di registri contiene i log generati dal codice funzione e dalle estensioni e anche i log generati da Lambda nell'ambito del richiamo della funzione.

Le [estensioni Lambda](runtimes-extensions-api.md) possono utilizzare l'API Logs del runtime di Lambda per eseguire la sottoscrizione ai flussi di log direttamente dall'interno dell'[ambiente di esecuzione](lambda-runtime-environment.md) Lambda. Lambda trasmette i log all'estensione e l'estensione può quindi elaborare, filtrare e inviare i log a qualsiasi destinazione preferita.

![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/logs-api-concept-diagram.png)


L'API Logs consente alle estensioni di sottoscrivere tre flussi di log diversi:
+ Log di funzioni che la funzione Lambda genera e scrive in `stdout` o `stderr`.
+ Log di estensione generati dal codice di estensione.
+ Log si piattaforma Lambda, che registrano eventi ed errori relativi a richiami ed estensioni.

**Nota**  
Lambda invia tutti i log a CloudWatch, anche quando un'estensione sottoscrive uno o più flussi di log.

**Topics**
+ [

## Sottoscrizione ai log di ricezione
](#runtimes-logs-api-subscribing)
+ [

## Utilizzo della memoria
](#runtimes-logs-api-memory)
+ [

## Protocolli destinazione
](#runtimes-logs-api-dest)
+ [

## Configurazione buffering
](#runtimes-logs-api-buffering)
+ [

## Esempio di sottoscrizione
](#runtimes-logs-api-subs-example)
+ [

## Codice di esempio per l'API Logs
](#runtimes-logs-api-samples)
+ [

## Riferimento dell'API Logs.
](#runtimes-logs-api-ref)
+ [

## Messaggi di log
](#runtimes-logs-api-msg)

## Sottoscrizione ai log di ricezione
<a name="runtimes-logs-api-subscribing"></a>

Un'estensione Lambda può sottoscrivere i log di ricezione inviando una richiesta di sottoscrizione all'API Logs.

Per sottoscrivere i log di ricezione, è necessario l'identificatore di estensione (`Lambda-Extension-Identifier`). Innanzitutto [registrare l'estensione](runtimes-extensions-api.md#extensions-registration-api-a) per ricevere l'identificatore dell'estensione. Quindi sottoscrivere l'API Logs durante l'[inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib). Al termine della fase di inizializzazione, Lambda non elabora le richieste di sottoscrizione.

**Nota**  
La sottoscrizione Logs API è idempotente. Le richieste di sottoscrizione duplicate non comportano sottoscrizioni duplicate.

## Utilizzo della memoria
<a name="runtimes-logs-api-memory"></a>

L'utilizzo della memoria aumenta linearmente man mano che aumenta il numero di abbonati. Le sottoscrizioni consumano risorse di memoria perché ogni sottoscrizione apre un nuovo buffer di memoria per archiviare i log. Per ottimizzare l'utilizzo della memoria, è possibile regolare la [configurazione di buffering](#runtimes-logs-api-buffering). L'utilizzo della memoria buffer conta per il consumo complessivo della memoria nell'ambiente di esecuzione.

## Protocolli destinazione
<a name="runtimes-logs-api-dest"></a>

È possibile scegliere uno dei seguenti protocolli per ricevere i log:

1. **HTTP** (consigliato) – Lambda consegna i log a un endpoint HTTP locale (`http://sandbox.localdomain:${PORT}/${PATH}`) come matrice di record in formato JSON. Il parametro `$PATH` è facoltativo. Si noti che è supportato solo HTTP, non HTTPS. Puoi scegliere di ricevere i log tramite PUT o POST.

1. **TCP** – Lambda consegna i log a una porta TCP in [formato JSON delimitato da Newline (NDJSON)](https://github.com/ndjson/ndjson-spec).

Si consiglia di utilizzare HTTP anziché TCP. Con TCP, la piattaforma Lambda non può riconoscere che i log vengono consegnati al livello dell'applicazione. Pertanto, se l'estensione si blocca si potrebbero perdere i log. HTTP non condivide questa limitazione.

Si consiglia inoltre di impostare il listener HTTP locale o la porta TCP prima di sottoscrivere i log di ricezione. Durante l'installazione, tenere presente quanto segue:
+ Lambda invia i log solo alle destinazioni che si trovano all'interno dell'ambiente di esecuzione.
+ Lambda ritenta il tentativo di inviare i log (con backoff) se non c'è listener o se la richiesta POST o PUT genera errori. Se il sottoscrittore del log si blocca, continuerà a ricevere i log dopo che Lambda riavvia l'ambiente di esecuzione.
+ Lambda riserva la porta 9001. Non ci sono altre restrizioni o raccomandazioni sul numero di porta.

## Configurazione buffering
<a name="runtimes-logs-api-buffering"></a>

Lambda può tamponare i log e consegnarli al sottoscrittore. È possibile configurare questo comportamento nella richiesta di sottoscrizione specificando i seguenti campi facoltativi. Si noti che Lambda utilizza il valore predefinito per qualsiasi campo non specificato.
+ **timeoutMs** – Il tempo massimo (in millisecondi) per il buffer di un batch. Valore predefinito: 1.000 Minimo: 25. Massimo: 30.000
+ **maxBytes** – La dimensione massima (in byte) dei registri al buffer in memoria. Valore predefinito: 262.144. Minimo: 262.144. Massimo: 1.048.576.
+ **maxItems** – Il numero massimo di eventi da memorizzare nel buffer. Valore predefinito: 10.000 Minimo: 1.000. Massimo: 10.000.

Durante la configurazione del buffering, prendere nota dei seguenti punti:
+ Lambda svuota i log se uno qualsiasi dei flussi di input è chiuso, ad esempio, se il runtime si arresta in modo anomalo.
+ Ogni sottoscrittore può specificare una configurazione di buffering diversa durante la richiesta di sottoscrizione.
+ Considerare la dimensione del buffer necessaria per leggere i dati. Aspettarsi di ricevere payload grandi come `2*maxBytes+metadata`, dove `maxBytes` è configurato nella richiesta di sottoscrizione. Ad esempio, Lambda aggiunge i byte di metadati seguenti a ciascun record:

  ```
  {
  "time": "2020-08-20T12:31:32.123Z",
  "type": "function",
  "record": "Hello World"
  }
  ```
+ Se il server di sottoscrizione non è in grado di elaborare i log in ingresso abbastanza rapidamente, Lambda potrebbe eliminare i log per mantenere limitato l'utilizzo della memoria. Per indicare il numero di record eliminati, Lambda invia un log `platform.logsDropped`. Per ulteriori informazioni, consulta [Lambda: non vengono visualizzati tutti i log della mia funzione](troubleshooting-execution.md#troubleshooting-execution-missinglogs).

## Esempio di sottoscrizione
<a name="runtimes-logs-api-subs-example"></a>

L'esempio seguente mostra una richiesta di sottoscrizione ai log della piattaforma e delle funzioni.

```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs HTTP/1.1
{ "schemaVersion": "2020-08-15",
  "types": [
      "platform",
      "function"
    ],
  "buffering": {
      "maxItems": 1000,
      "maxBytes": 262144,
      "timeoutMs": 100
    },
  "destination": {
    "protocol": "HTTP",
    "URI": "http://sandbox.localdomain:8080/lambda_logs"
  }
}
```

Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta riuscita HTTP 200.

```
HTTP/1.1 200 OK
"OK"
```

## Codice di esempio per l'API Logs
<a name="runtimes-logs-api-samples"></a>

Per un codice di esempio che mostra come inviare i log a una destinazione personalizzata, consulta [Usare AWS Lambda le estensioni per inviare log a destinazioni personalizzate su Compute Blog.](https://aws.amazon.com/blogs/compute/using-aws-lambda-extensions-to-send-logs-to-custom-destinations/) AWS 

Per esempi di codice in Python e Go che mostrano come sviluppare un'estensione Lambda di base e sottoscrivere l'API Logs, consulta [AWS Lambda Extensions](https://github.com/aws-samples/aws-lambda-extensions) on the Samples repository. AWS GitHub Per ulteriori informazioni sulla creazione di un'estensione Lambda, consultare [Utilizzo dell'API Extensions di Lambda per creare estensioni](runtimes-extensions-api.md).

## Riferimento dell'API Logs.
<a name="runtimes-logs-api-ref"></a>

È possibile recuperare l'endpoint API Logs dalla`AWS_LAMBDA_RUNTIME_API` variabile di ambiente. Per inviare una richiesta API, utilizzare il prefisso `2020-08-15/` prima del percorso API. Esempio:

```
http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs
```

[La specifica OpenAPI per la versione Logs API **2020-08-15** è disponibile qui: .zip logs-api-request](samples/logs-api-request.zip)

### Subscribe
<a name="runtimes-logs-api-ref-a"></a>

Per sottoscrivere uno o più flussi di log disponibili nell'ambiente di esecuzione di Lambda, le estensioni inviano una richiesta API di sottoscrizione.

**Percorso** – `/logs`

**Method** – **PUT**

**Parametri corpo**

`destination` - Consultare [Protocolli destinazione](#runtimes-logs-api-dest). Campo obbligatorio: sì Tipo: stringhe.

`buffering` - Consultare [Configurazione buffering](#runtimes-logs-api-buffering). Campo obbligatorio: no. Tipo: stringhe.

`types` – Un array dei tipi di log da ricevere. Campo obbligatorio: sì Tipo: array di stringhe Valori validi: «piattaforma», «funzione», «estensione».

`schemaVersion` – Obbligatorio: no. Valore di default: "2020-08-15". Impostare su "2021-03-18" per l'estensione in modo da ricevere messaggi [`platform.runtimeDone`](#runtimes-logs-api-ref-done).

****Parametri di risposta****

Le specifiche OpenAPI per le risposte di sottoscrizione, versione **2020-08-15**, sono disponibili per i protocolli HTTP e TCP:
+ [logs-api-http-responseHTTP](samples/logs-api-http-response.zip): .zip
+ [TCP: .zip logs-api-tcp-response](samples/logs-api-tcp-response.zip)

****Codice di risposta****
+ 200 – Richiesta completata con successo
+ 202 – Richiesta accettata. Risposta ad una richiesta di sottoscrizione durante il test locale.
+ 4XX – Richiesta non valida
+ 500 – Errore servizio

Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta riuscita HTTP 200.

```
HTTP/1.1 200 OK
"OK"
```

Se la richiesta fallisce, il sottoscrittore riceve una risposta di errore. Ad esempio: 

```
HTTP/1.1 400 OK
{
    "errorType": "Logs.ValidationError",
    "errorMessage": URI port is not provided; types should not be empty"
}
```

## Messaggi di log
<a name="runtimes-logs-api-msg"></a>

L'API Logs consente alle estensioni di sottoscrivere tre flussi di log diversi:
+ Funzione – Log che la funzione Lambda genera e scrive in `stdout` o `stderr`.
+ Estensione – Log generati dal codice di estensione.
+ Piattaforma – Log generati dalla piattaforma runtime, che registrano eventi ed errori relativi a richiami ed estensioni.

**Topics**
+ [

### Log delle funzioni
](#runtimes-logs-api-msg-function)
+ [

### Log di estensioni
](#runtimes-logs-api-msg-extension)
+ [

### Log di piattaforma
](#runtimes-logs-api-msg-platform)

### Log delle funzioni
<a name="runtimes-logs-api-msg-function"></a>

La funzione Lambda e le estensioni interne generano log di funzioni e li scrivono in `stdout` o `stderr`.

L'esempio seguente mostra il formato di un messaggio di log di funzioni. \$1 "time": "2020-08-20T12:31:32.123Z", "type": "function", "record": "ERROR encountered. Stack trace:\$1n\$1my-function (line 10)\$1n" \$1 

### Log di estensioni
<a name="runtimes-logs-api-msg-extension"></a>

Le estensioni possono generare log di estensioni. Il formato del log è uguale a quello di un log di funzioni.

### Log di piattaforma
<a name="runtimes-logs-api-msg-platform"></a>

Lambda genera messaggi di log per eventi della piattaforma come `platform.start`, `platform.end` e `platform.fault`.

Facoltativamente, è possibile sottoscrivere la versione **2021-03-18** dello schema dell'API Log, che include il messaggio di log `platform.runtimeDone`.

#### Esempio di messaggi di log di piattaforma
<a name="runtimes-logs-api-examples"></a>

Nell'esempio seguente vengono illustrati i log di inizio e di fine della piattaforma. Questi log indicano l'ora di inizio e l'ora di fine chiamata per la chiamata specificata da requestId. 

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.start",
    "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}   
}
{
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.end",
    "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}   
}
```

**La piattaforma. initRuntimeDone**il messaggio di registro mostra lo stato della `Runtime init` sottofase, che fa parte della fase del [ciclo di vita di Init](lambda-runtime-environment.md#runtimes-lifecycle-ib). In caso di riuscita di `Runtime init`, il runtime invia una richiesta API `/next` di runtime (per i tipi di inizializzazione `on-demand` e `provisioned-concurrency`) o `restore/next` (per il tipo di inizializzazione `snap-start`). **L'esempio seguente mostra una piattaforma di successo. initRuntimeDone**messaggio di registro per il tipo di `snap-start` inizializzazione.

```
{
  "time":"2022-07-17T18:41:57.083Z",
  "type":"platform.initRuntimeDone",
  "record":{
      "initializationType":"snap-start",
      "status":"success"
  }
}
```

Il messaggio di log **platform.initReport** mostra quanto è durata la fase `Init` e quanti millisecondi sono stati fatturati durante questa fase. Quando il tipo di inizializzazione è `provisioned-concurrency`, Lambda invia questo messaggio durante la chiamata. Quando il tipo di inizializzazione è `snap-start`, Lambda invia questo messaggio dopo aver ripristinato lo snapshot. L'esempio seguente mostra un messaggio di log **platform.initReport** riuscito per il tipo di inizializzazione `snap-start`.

```
{
  "time":"2022-07-17T18:41:57.083Z",
  "type":"platform.initReport",
  "record":{
      "initializationType":"snap-start",
      "metrics":{
          "durationMs":731.79,
          "billedDurationMs":732
          }
  }
}
```

Il log dei report della piattaforma include parametri sulla chiamata specificata da requestId. Il campo `initDurationMs` è incluso nel log solo se la chiamata include un avvio a freddo. Se la traccia AWS X-Ray è attiva, il log include i metadati X-Ray. Nell'esempio seguente viene illustrato un log di rapporto della piattaforma per una chiamata che includeva un avvio a freddo.

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.report",
    "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56",
        "metrics": {"durationMs": 101.51,
            "billedDurationMs": 300,
            "memorySizeMB": 512,
            "maxMemoryUsedMB": 33,
            "initDurationMs": 116.67
        }
    }
}
```

Il log della piattaforma acquisisce errori di runtime o dell'ambiente di esecuzione. L'esempio seguente mostra un messaggio di log di errore della piattaforma. 

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.fault",
    "record": "RequestId: d783b35e-a91d-4251-af17-035953428a2c Process exited before completing request"
}
```

**Nota**  
AWS sta attualmente implementando modifiche al servizio Lambda. A causa di queste modifiche, potresti notare piccole differenze tra la struttura e il contenuto dei messaggi di log di sistema e dei segmenti di traccia emessi da diverse funzioni Lambda nel tuo Account AWS.  
Uno degli output dei log interessati da questa modifica è il campo `"record"` del log degli errori della piattaforma. Gli esempi seguenti mostrano campi `"record"` nei formati vecchi e nuovi. Il nuovo stile del log degli errori contiene un messaggio più conciso  
Queste modifiche verranno implementate nelle prossime settimane e tutte le funzioni, Regioni AWS ad eccezione della Cina e delle GovCloud regioni, passeranno all'utilizzo dei messaggi di registro e dei segmenti di traccia di nuovo formato.



**Example record del log degli errori della piattaforma (vecchio stile)**  

```
"record":"RequestId: ...\tError: Runtime exited with error: exit status 255\nRuntime.ExitError"
```

**Example record del log degli errori della piattaforma (nuovo stile)**  

```
"record":"RequestId: ... Status: error\tErrorType: Runtime.ExitError"
```

Lambda genera un log di estensioni della piattaforma quando un'estensione si registra con l'API delle estensioni. L'esempio seguente mostra un messaggio dell'estensione della piattaforma. 

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.extension",
    "record": {"name": "Foo.bar",
        "state": "Ready",
        "events": ["INVOKE", "SHUTDOWN"]
     }
}
```

Lambda genera un log di sottoscrizione al log della piattaforma quando un'estensione sottoscrive l'API Log. Nell'esempio seguente viene illustrato un messaggio di sottoscrizione log. 

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.logsSubscription",
    "record": {"name": "Foo.bar",
        "state": "Subscribed",
        "types": ["function", "platform"],
    }
}
```

Lambda genera un log eliminato dei log di piattaforma quando un'estensione non è in grado di elaborare il numero di log che sta ricevendo. Nell'esempio seguente viene mostrato un`platform.logsDropped` messaggio di log. 

```
{     
    "time": "2020-08-20T12:31:32.123Z",
    "type": "platform.logsDropped",
    "record": {"reason": "Consumer seems to have fallen behind as it has not acknowledged receipt of logs.",
        "droppedRecords": 123,
        "droppedBytes" 12345
    }
}
```

Il messaggio di log **platform.restoreStart** mostra l'ora di inizio della fase `Restore` (solo per il tipo di inizializzazione `snap-start`). Esempio:

```
{ 
  "time":"2022-07-17T18:43:44.782Z", 
  "type":"platform.restoreStart", 
  "record":{} 
}
```

Il messaggio di log **platform.restoreReport** mostra quanto è durata la fase `Restore` e quanti millisecondi sono stati fatturati durante questa fase (solo per il tipo di inizializzazione `snap-start`). Esempio:

```
{
  "time":"2022-07-17T18:43:45.936Z",
  "type":"platform.restoreReport",
  "record":{
      "metrics":{
          "durationMs":70.87,
          "billedDurationMs":13
      }
  }
}
```

#### Messaggi `runtimeDone` della piattaforma
<a name="runtimes-logs-api-ref-done"></a>

Se si imposta la versione dello schema su "2021-03-18" nella richiesta di sottoscrizione, Lambda invia un messaggio `platform.runtimeDone` dopo il completamento della chiamata della funzione o con un errore. L'estensione può utilizzare questo messaggio per arrestare tutta la raccolta di dati di telemetria per questa chiamata di funzione.

La specifica OpenAPI per il tipo di evento Log nella versione dello schema **2021-03-18** è disponibile qui: [schema-2021-03-18.zip](samples/schema-2021-03-18.zip)

Lambda genera il messaggio di log `platform.runtimeDone` quando il runtime invia una richiesta API di runtime `Next` o `Error`. Il log `platform.runtimeDone` informa i consumatori dell'API Log che la chiamata di funzione è stata completata. Le estensioni possono utilizzare queste informazioni per decidere quando inviare tutti i dati di telemetria raccolti durante tale chiamata.

##### Esempi
<a name="runtimes-logs-api-examples"></a>

Lambda invia il messaggio `platform.runtimeDone` dopo che il runtime invia la richiesta NEXT al completamento della chiamata della funzione. Negli esempi seguenti vengono illustrati i messaggi relativi a ciascuno dei valori di stato: riuscita, errore e timeout.

**Example Esempio di messaggio di riuscita**  

```
{
    "time": "2021-02-04T20:00:05.123Z",
    "type": "platform.runtimeDone",
    "record": {
       "requestId":"6f7f0961f83442118a7af6fe80b88",
       "status": "success"
    }
}
```

**Example Esempio di messaggio di errore**  

```
{
   "time": "2021-02-04T20:00:05.123Z",
   "type": "platform.runtimeDone",
   "record": {
      "requestId":"6f7f0961f83442118a7af6fe80b88",
      "status": "failure"
   }
}
```

**Example Esempio di messaggio di timeout**  

```
{
   "time": "2021-02-04T20:00:05.123Z",
   "type": "platform.runtimeDone",
   "record": {
      "requestId":"6f7f0961f83442118a7af6fe80b88",
      "status": "timeout"
  }
}
```

**Example Piattaforma di esempio. restoreRuntimeDone messaggio (solo tipo di `snap-start` inizializzazione)**  
La **piattaforma. restoreRuntimeDone**il messaggio di registro mostra se la `Restore` fase ha avuto successo o meno. Lambda genera questo messaggio quando il runtime invia una richiesta API di runtime `restore/next`. Ci sono tre stati possibili: riuscito, errore e timeout. L'esempio seguente mostra una **piattaforma di successo. restoreRuntimeDone**messaggio di registro.  

```
{
  "time":"2022-07-17T18:43:45.936Z",
  "type":"platform.restoreRuntimeDone",
  "record":{
      "status":"success"
  }
}
```