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à.
# Monitoraggio, debug e risoluzione dei problemi delle funzioni Lambda
AWS Lambda si integra con altri Servizi AWS per aiutarti a monitorare e risolvere i problemi relativi alle tue funzioni Lambda. Lambda monitora automaticamente le funzioni Lambda per tuo conto e segnala i parametri tramite Amazon CloudWatch. Per monitorare il codice durante la sua esecuzione, Lambda tiene traccia automaticamente del numero di richieste, della durata della chiamata di ogni richiesta e del numero di richieste che restituiscono un errore.
Puoi utilizzare altri Servizi AWS per risolvere i problemi relativi alle funzioni Lambda. In questa sezione viene descritto come utilizzare questi Servizi AWS per monitorare, tracciare, eseguire il debug e risolvere i problemi relativi alle funzioni e alle applicazioni Lambda. Per dettagli sulla registrazione delle funzioni e sugli errori in ogni runtime, consulta le singole sezioni del runtime.
**Topics**
+ [Prezzi](#monitoring-console-metrics-pricing)
+ [Utilizzo dei parametri di CloudWatch Logs con Lambda](monitoring-metrics.md)
+ [Utilizzo dei registri delle funzioni Lambda](monitoring-logs.md)
+ [Registrazione delle chiamate AWS Lambda API utilizzando AWS CloudTrail](logging-using-cloudtrail.md)
+ [Visualizza le chiamate alla funzione Lambda utilizzando AWS X-Ray](services-xray.md)
+ [Monitorare le prestazioni delle funzioni con Lambda Insights di Amazon CloudWatch](monitoring-insights.md)
+ [Monitoraggio delle applicazioni Lambda](applications-console-monitoring.md)
+ [Monitoraggio delle prestazioni delle applicazioni con Amazon CloudWatch Application Signals](monitoring-application-signals.md)
+ [Esecuzione da remoto del debug delle funzioni Lambda con Visual Studio Code](debugging.md)
## Prezzi
CloudWatch dispone di un piano gratuito senza termini di tempo. Oltre la soglia del piano gratuito, CloudWatch prevede dei costi per parametri, pannelli, allarmi, registri e informazioni dettagliate. Per ulteriori informazioni, consulta [Prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
# Utilizzo dei parametri di CloudWatch Logs con Lambda
Quando la funzione AWS Lambda termina l'elaborazione di un evento, Lambda invia ad Amazon CloudWatch i parametri relativi all'invocazione. Non è necessario concedere autorizzazioni aggiuntive al ruolo di esecuzione per ricevere i parametri delle funzioni e non sono previsti costi aggiuntivi per questi parametri.
Esistono molti tipi di parametri associati alle funzioni Lambda. Tra questi vi sono i parametri di invocazione, parametri delle prestazioni, parametri di simultaneità, parametri di invocazione asincrona e parametri dello strumento di mappatura dell'origine degli eventi. Per ulteriori informazioni, consulta [Tipi di parametri per le funzioni Lambda](monitoring-metrics-types.md).
Sulla console CloudWatch, è possibile [visualizzare questi parametri](monitoring-metrics-view.md) e creare grafici e pannelli di controllo con essi. È possibile impostare allarmi per rispondere alle modifiche apportate alle percentuali di utilizzo, prestazioni o errore. Lambda invia i dati dei parametri a CloudWatch in intervalli di 1 minuto. Se desideri una visione più immediata della funzione Lambda, è possibile creare [parametri personalizzati ad alta risoluzione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html). Per i parametri personalizzati e gli allarmi CloudWatch sono previsti dei costi. Per ulteriori informazioni, consulta la pagina [Prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
# Visualizzazione di parametri per le funzioni Lambda
Usa la console CloudWatch per visualizzare i parametri per le tue funzioni Lambda. Nella console, puoi filtrare e ordinare i parametri della funzione in base al nome, all'alias o alla versione o all'UUID del mapping dell'origine di eventi.
**Per visualizzare i parametri nella console CloudWatch**
1. Aprire la pagina [Metrics](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (Parametri) (namespace di `AWS/Lambda`) nella console CloudWatch.
1. Nella scheda **Sfoglia**, in **Parametri**, scegli una delle seguenti dimensioni:
+ **Per nome funzione** (`FunctionName`) – Visualizza i parametri aggregati per tutte le versioni e gli alias di una funzione.
+ **Per risorsa** (`Resource`) – Visualizza i parametri per una versione o un alias di una funzione.
+ **Per version eseguita** (`ExecutedVersion`) – Visualizza i parametri per una combinazione di alias e versione. Utilizzare la dimensione `ExecutedVersion` per confrontare le percentuali di errore per due versioni di una funzione che sono entrambe destinazioni di un [alias ponderato](configuration-aliases.md).
+ **Per UUID di mapping di origine di eventi** (`EventSourceMappingUUID`): visualizza i parametri per uno strumento di mappatura dell'origine degli eventi.
+ **In tutte le funzioni (nessuna)**: visualizza i parametri aggregati per tutte le funzioni nella Regione AWS corrente.
1. Scegli un parametro. Il parametro dovrebbe apparire automaticamente nel grafico visivo e nella scheda **Parametri nel grafico**.
Per impostazione predefinita, i grafici utilizzano la statistica `Sum` per tutti i parametri. Per scegliere un parametro diverso e personalizzare il grafico, utilizzare le opzioni nella scheda **Graphed metrics (Parametri grafico)**.
**Nota**
Il timestamp su un parametro riflette quando la funzione è stata invocata. A seconda della durata della chiamata, possono essere necessari diversi minuti prima dell'emissione del parametro. Se, ad esempio, la funzione ha un timeout di 10 minuti, per trovare i parametri accurati bisogna cercare a ritroso oltre i 10 minuti.
Per ulteriori informazioni su CloudWatch, consulta la [Guida per l'utente di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
# Tipi di parametri per le funzioni Lambda
Questa sezione descrive i tipi di metriche Lambda disponibili nella console. CloudWatch
**Topics**
+ [Parametri di invocazione](#invocation-metrics)
+ [Metriche di implementazione](#deployment-metrics)
+ [Metriche delle prestazioni](#performance-metrics)
+ [Parametri di concorrenza](#concurrency-metrics)
+ [Parametri di chiamata asincrona](#async-invocation-metrics)
+ [Parametri dello strumento di mappatura dell'origine degli eventi](#event-source-mapping-metrics)
## Parametri di invocazione
I parametri di invocazione sono indicatori binari del risultato di una chiamata alla funzione Lambda. Visualizza questi parametri con la statistica `Sum`. Ad esempio, se la funzione restituisce un errore, Lambda invia il parametro `Errors` con un valore pari a 1. Per ottenere un conteggio del numero di errori di funzione che si sono verificati ogni minuto, visualizzare la somma `Sum` del parametro `Errors` con un periodo di un minuto.
+ `Invocations`: il numero di volte in cui viene chiamato il codice di funzione, incluse le chiamate riuscite e le chiamate che determinano un errore di funzione. Le chiamate non vengono registrate se la richiesta di chiamata è limitata o altrimenti viene generato un errore di chiamata. Il valore di `Invocations` equivale al numero di richieste fatturate.
+ `Errors`: il numero di chiamate che provocano un errore di funzione. Gli errori di funzione includono eccezioni generate dal codice e eccezioni generate dal runtime Lambda. Il runtime restituisce errori per problemi quali timeout ed errori di configurazione. Per calcolare la percentuale di errore, dividere il valore di `Errors` per il valore di `Invocations`. Tieni presente che il timestamp di un parametro di errore riflette quando è stata richiamata la funzione, non quando si è verificato l'errore.
+ `DeadLetterErrors`: per la [chiamata asincrona](invocation-async.md), il numero di tentativi di invio non riusciti da parte di Lambda di un evento a una coda DLQ. Gli errori DLQ possono verificarsi a causa di risorse configurate erroneamente o limiti di dimensione.
+ `DestinationDeliveryFailures`: per la chiamata asincrona e per lo [strumento di mappatura dell'origine degli eventi](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) supportato, indica il numero di tentativi di invio non riusciti da parte di Lambda di un evento a una [destinazione](invocation-async-retain-records.md#invocation-async-destinations). Per gli strumenti di mappatura dell'origine degli eventi, Lambda supporta destinazioni per le origini di flusso (DynamoDB e Kinesis). Gli errori di recapito possono verificarsi a causa di errori di autorizzazioni, risorse configurate erroneamente o limiti di dimensione. Gli errori possono verificarsi anche se la destinazione che hai configurato è di tipo non supportato, ad esempio una coda FIFO di Amazon SQS o un argomento FIFO di Amazon SNS.
+ `Throttles`: il numero di richieste di chiamata con throttling. Quando tutte le istanze di funzione elaborano le richieste e non è disponibile alcuna simultaneità per l'aumento, Lambda rifiuta le richieste aggiuntive con un errore `TooManyRequestsException`. Le richieste con limitazione e altri errori di chiamata non contano come `Invocations` o `Errors`.
**Nota**
Con [Lambda Managed Instances,](lambda-managed-instances.md) Lambda fornisce metriche granulari di accelerazione che identificano il vincolo specifico che causa l'acceleratore. Quando si verifica un rallentamento nell'ambiente di esecuzione, viene emessa esattamente una delle seguenti metriche secondarie con il valore 1, mentre le altre tre vengono emesse con il valore 0. La `Throttles` metrica viene sempre emessa insieme a queste metriche secondarie.
`CPUThrottles`— Le chiamate sono state limitate a causa dell'esaurimento della CPU nell'ambiente di esecuzione.
`MemoryThrottles`— Richiamazioni limitate a causa dell'esaurimento della memoria nell'ambiente di esecuzione.
`DiskThrottles`— Richiamazioni limitate a causa dell'esaurimento del disco nell'ambiente di esecuzione.
`ConcurrencyThrottles`— Le chiamate vengono limitate quando viene raggiunto il limite di concorrenza dell'ambiente di esecuzione.
+ `OversizedRecordCount`: per le origini di eventi di Amazon DocumentDB, il numero di eventi che la funzione riceve dal flusso di modifiche è superiore a 6 MB. Lambda elimina il messaggio ed emette questo parametro.
+ `ProvisionedConcurrencyInvocations`: il numero di volte in cui il codice di funzione viene richiamato tramite la [simultaneità fornita](provisioned-concurrency.md).
+ `ProvisionedConcurrencySpilloverInvocations`: il numero di volte in cui il codice di funzione viene chiamato tramite la simultaneità standard quando è in uso tutta la simultaneità fornita.
+ `RecursiveInvocationsDropped`: il numero di volte in cui Lambda ha interrotto l'invocazione della funzione perché ha rilevato che la funzione fa parte di un ciclo ricorsivo infinito. Il rilevamento ricorsivo del loop monitora quante volte una funzione viene richiamata come parte di una catena di richieste tracciando i metadati aggiunti da Supported. AWS SDKs Per impostazione predefinita, se la funzione viene richiamata come parte di una catena di richieste circa 16 volte, Lambda interrompe l'invocazione successiva. Se disabiliti il rilevamento del ciclo ricorsivo, questo parametro non viene emesso. Per ulteriori informazioni sull'utilizzo di questa caratteristica, consulta [Usa il rilevamento di un ciclo ricorsivo Lambda per prevenire loop infiniti](invocation-recursion.md).
## Metriche di implementazione
Le metriche di distribuzione forniscono informazioni sugli eventi di distribuzione della funzione Lambda e sui relativi processi di convalida.
+ `SignatureValidationErrors`— Il numero di volte in cui si è verificata la distribuzione di un pacchetto di codice con errori di convalida della firma quando la politica di configurazione della firma del codice è impostata su. `Warn` Questa metrica viene emessa quando i controlli di scadenza, mancata corrispondenza o revoca hanno esito negativo, ma la distribuzione è comunque consentita a causa dell'impostazione dei criteri. `Warn` Per ulteriori informazioni sulla firma del codice, consulta. [Utilizzo della firma del codice per verificare l'integrità del codice con Lambda](configuration-codesigning.md)
## Metriche delle prestazioni
I parametri delle prestazioni forniscono dettagli delle prestazioni relativi a una singola chiamata della funzione. Ad esempio, il parametro `Duration` indica il tempo in millisecondi che la funzione impiega per l'elaborazione di un evento. Per avere un'idea della velocità con cui la funzione elabora gli eventi, visualizzare questi parametri con la statistica `Average` o `Max`.
+ `Duration` – La quantità di tempo che il codice della funzione impiega durante l'elaborazione di un evento. La durata fatturata per una invocazione è il valore di `Duration` arrotondato per eccesso al millisecondo più vicino. `Duration` non include il tempo di avvio a freddo.
+ `PostRuntimeExtensionsDuration` – La quantità cumulativa di tempo che il runtime trascorre eseguendo il codice per le estensioni dopo il completamento del codice funzione.
+ `IteratorAge`: per le origini eventi DynamoDB, Kinesis e Amazon DocumentDB, l'età (in millisecondi) dell'ultimo record dell'evento. Questo parametro misura il tempo che passa tra il momento in cui il flusso riceve il record e il momento in cui lo strumento di mappatura dell'origine degli eventi invia l'evento alla funzione.
+ `OffsetLag`: per le origini eventi Apache Kafka autogestite e Streaming gestito da Amazon per Apache Kafka (Amazon MSK), la differenza di offset tra l'ultimo record scritto su un argomento e l'ultimo record elaborato dal gruppo di consumer della funzione. Sebbene un argomento di Kafka possa avere più partizioni, questo parametro misura il ritardo di offset a livello di argomento.
`Duration` supporta anche le statistiche percentili (`p`). Utilizzare i percentili per escludere valori estremi che incideranno sulle statistiche `Average` e `Maximum`. Ad esempio, la statistica `p95` mostra la durata massima del 95% delle chiamate, escludendo il 5% più lento. Per ulteriori informazioni, consulta [Percentiles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles) nella *Amazon CloudWatch User Guide*.
## Parametri di concorrenza
Lambda segnala i parametri di simultaneità come conteggio aggregato del numero di istanze che elaborano eventi in una funzione, una versione, un alias o una Regione AWS. Per vedere quanto sei vicino al superamento dei [limiti di simultaneità](lambda-concurrency.md#concurrency-quotas), visualizza questi parametri con la statistica `Max`.
+ `ConcurrentExecutions` – Il numero di istanze di funzione che stanno elaborando gli eventi. Se questo numero raggiunge la [quota di esecuzioni simultanee](gettingstarted-limits.md#compute-and-storage) per la regione o il limite di [simultaneità riservato](configuration-concurrency.md) configurato per la funzione, Lambda limita le richieste di chiamata aggiuntive.
+ `ProvisionedConcurrentExecutions`: il numero di istanze di funzione che stanno elaborando eventi tramite la [simultaneità fornita](provisioned-concurrency.md). Per ogni chiamata di un alias o versione con la simultaneità fornita, Lambda emette il conteggio corrente. Se la tua funzione è inattiva o non riceve richieste, Lambda non emette questa metrica.
+ `ProvisionedConcurrencyUtilization`: per una versione o un alias, il valore di `ProvisionedConcurrentExecutions` diviso per la quantità totale di simultaneità fornita configurata. Ad esempio, se configuri una simultaneità fornita pari a 10 per la funzione e `ProvisionedConcurrentExecutions` è 7, allora `ProvisionedConcurrencyUtilization` è 0,7.
Se la tua funzione è inattiva o non riceve richieste, Lambda non emette questa metrica perché è basata su. `ProvisionedConcurrentExecutions` Tienilo a mente se lo utilizzi `ProvisionedConcurrencyUtilization` come base per gli allarmi. CloudWatch
+ `UnreservedConcurrentExecutions`: per una regione, il numero di eventi che vengono elaborati da funzioni che non dispongono di simultaneità riservata.
+ `ClaimedAccountConcurrency`: per una Regione, la quantità di simultaneità non disponibile per le invocazioni on demand. `ClaimedAccountConcurrency` corrisponde a `UnreservedConcurrentExecutions` più la quantità di simultaneità allocata (ovvero la simultaneità totale riservata più la simultaneità totale fornita). Per ulteriori informazioni, consulta [Lavorare con il parametro `ClaimedAccountConcurrency`](monitoring-concurrency.md#claimed-account-concurrency).
## Parametri di chiamata asincrona
I parametri di chiamata asincrona forniscono dettagli sulle chiamate asincrone da origini di eventi e sulle chiamate dirette. Puoi impostare le soglie e gli allarmi per la notifica di alcuni cambiamenti. Ad esempio, quando si verifica un aumento indesiderato del numero di eventi in coda per l'elaborazione (`AsyncEventsReceived`). Oppure, quando un evento aspetta da molto tempo di essere elaborato (`AsyncEventAge`).
+ `AsyncEventsReceived`: il numero di eventi che Lambda mette correttamente in coda per l'elaborazione. Questo parametro fornisce informazioni sul numero di eventi ricevuti da una funzione Lambda. Monitora questo parametro e imposta gli allarmi relativi alle soglie per verificare eventuali problemi. Ad esempio, per rilevare un numero indesiderato di eventi inviati a Lambda e diagnosticare rapidamente i problemi derivanti da configurazioni errate di trigger o funzioni. Le discrepanze tra `AsyncEventsReceived` e `Invocations` possono indicare una disparità nell'elaborazione, l'eliminazione degli eventi o un potenziale arretrato della coda.
+ `AsyncEventAge`: il tempo che intercorre tra il momento in cui Lambda mette in coda correttamente l'evento e il momento in cui la funzione viene richiamata. Il valore di questo parametro aumenta quando gli eventi vengono ritentati a causa di errori di chiamata o limitazioni. Monitora questo parametro e imposta allarmi per rilevare le soglie su diverse statistiche relative a quando si verifica un accumulo di code. Per risolvere un aumento di questo parametro, consulta il parametro `Errors` per identificare gli errori della funzione e il parametro `Throttles` per identificare i problemi di simultaneità.
+ `AsyncEventsDropped`: il numero di eventi eliminati senza eseguire correttamente la funzione. Se configuri una coda DLQ o una destinazione `OnFailure`, gli eventi vengono inviati lì prima di essere eliminati. Gli eventi vengono eliminati per diversi motivi. Ad esempio, possono superare la durata massima o esaurire il numero massimo di tentativi oppure la simultaneità riservata potrebbe essere impostata su 0. Per risolvere il problema relativo all'eliminazione degli eventi, consulta il parametro `Errors` per identificare gli errori della funzione e il parametro `Throttles` per identificare i problemi di simultaneità.
## Parametri dello strumento di mappatura dell'origine degli eventi
I parametri dello strumento di mappatura dell'origine degli eventi forniscono informazioni sul comportamento di elaborazione dello strumento di mappatura dell'origine degli eventi.
Attualmente, le metriche di mappatura delle sorgenti degli eventi sono disponibili per Amazon SQS, Kinesis, DynamoDB, Amazon MSK e le sorgenti di eventi Apache Kafka autogestite.
**Per la mappatura delle sorgenti degli eventi con metrics config, puoi anche controllare tutte le metriche relative a ESM nella scheda **Monitor** dalla pagina Console **Lambda** > Risorse **aggiuntive** > mappature delle fonti degli eventi ora.**
**Per abilitare i parametri o uno strumento di mappatura dell'origine degli eventi (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione per la quale desideri abilitare i parametri.
1. Scegli la scheda **Configurazione**, quindi scegli **Trigger**.
1. Scegli lo strumento di mappatura dell'origine degli eventi per cui desideri abilitare i parametri, quindi scegli **Modifica**.
1. **In **Configurazione della mappatura dell'origine degli eventi**, scegli **Abilita** metriche o seleziona dall'elenco a discesa Metriche.**
1. Scegli **Save** (Salva).
In alternativa, puoi abilitare le metriche per la mappatura delle sorgenti degli eventi a livello di codice utilizzando l'oggetto presente nel tuo. [ EventSourceMappingMetricsConfig[EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html)](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html) Ad esempio, il seguente comando [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI abilita le metriche per una mappatura dell'origine degli eventi:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
Esistono 3 gruppi di metriche:`EventCount`, `ErrorCount` e`KafkaMetrics`, e ogni gruppo ha più metriche. Non tutte le metriche sono disponibili per ogni origine di eventi. La tabella seguente riassume le metriche supportate per ogni tipo di origine di eventi.
È necessario attivare il gruppo di metriche per ricevere le metriche relative alle metriche. Ad esempio, imposta EventCount in metrics config per avere: (`PolledEventCount`,,,,, e). `FilteredOutEventCount` `InvokedEventCount` `FailedInvokeEventCount` `DroppedEventCount` `OnFailureDestinationDeliveredEventCount` `DeletedEventCount`
| Parametro dello strumento di mappatura dell'origine degli eventi | Gruppo di metriche | Amazon SQS | Stream Kinesis e DynamoDB | Amazon MSK e Apache Kafka autogestito |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | Sì | Sì | Sì |
| `FilteredOutEventCount` | `EventCount` | Sì | Sì | Sì |
| `InvokedEventCount` | `EventCount` | Sì | Sì | Sì |
| `FailedInvokeEventCount` | `EventCount` | Sì | Sì | Sì |
| `DroppedEventCount` | `EventCount` | No | Sì | Sì |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | No | Sì | Sì |
| `DeletedEventCount` | `EventCount` | Sì | No | No |
| `CommittedEventCount` | `EventCount` | No | No | Sì |
| `PollingErrorCount` | `ErrorCount` | No | No | Sì |
| `InvokeErrorCount` | `ErrorCount` | No | No | Sì |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | No | No | Sì |
| `SchemaRegistryErrorCount` | `ErrorCount` | No | No | Sì |
| `CommitErrorCount` | `ErrorCount` | No | No | Sì |
| `MaxOffsetLag` | `KafkaMetrics` | No | No | Sì |
| `SumOffsetLag` | `KafkaMetrics` | No | No | Sì |
Inoltre, se lo strumento di mappatura dell'origine degli eventi delle origini eventi è in [modalità provisioning](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), Lambda fornisce il seguente parametro:
+ `ProvisionedPollers`: per lo strumento di mappatura dell'origine degli eventi in modalità provisioning, il numero di poller di eventi che sono attivamente in esecuzione. Visualizza questa metrica usando la matematica. `MAX`
+ (Solo Amazon MSK e sorgenti di eventi Apache Kafka autogestite)`EventPollerUnit`: per le mappature delle sorgenti di eventi in modalità provisioning, il numero di unità di poller di eventi che sono attivamente in esecuzione. Visualizza `SUM` questa metrica usando la matematica.
+ (Amazon MSK e sorgenti di eventi Apache Kafka autogestite)`EventPollerThroughputInBytes`: per le mappature delle sorgenti di eventi in modalità provisioned, la dimensione totale dei record dei poller di eventi intervistati dall'origine dell'evento. Può dirti l'attuale produttività dei sondaggi. Visualizza questa metrica usando la matematica. `SUM`
Ecco ulteriori dettagli su ciascuna metrica:
+ `PolledEventCount`: il numero di eventi che Lambda legge correttamente dall'origine eventi. Se Lambda esegue un polling di eventi ma riceve un polling vuoto (nessun nuovo record), Lambda emette un valore 0 per questo parametro. Usa questo parametro per rilevare se lo strumento di mappatura dell'origine degli eventi esegue correttamente il polling dei nuovi eventi.
+ `FilteredOutEventCount`: per lo strumento di mappatura dell'origine degli eventi con un [criterio di filtro](invocation-eventfiltering.md), il numero di eventi filtrati in base a tali criteri di filtro. Utilizza questo parametro per rilevare se lo strumento di mappatura dell'origine degli eventi filtra correttamente gli eventi. Per gli eventi che soddisfano i criteri di filtro, Lambda emette un parametro 0.
+ `InvokedEventCount`: il numero di eventi che hanno richiamato la funzione Lambda. Usa questo parametro per verificare che gli eventi stiano richiamando correttamente la tua funzione. Se un evento causa un errore nella funzione o una limitazione, `InvokedEventCount` può contare più volte per lo stesso evento sottoposto a polling a causa dei vari tentativi automatici.
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per questo motivo, gli eventi possono essere contati più volte nei parametri che coinvolgono il conteggio degli eventi.
+ `FailedInvokeEventCount`: il numero di eventi con cui Lambda ha provato a richiamare la funzione ma senza riuscirci. Le invocazioni possono avere esito negativo per motivi quali problemi di configurazione della rete, autorizzazioni non corrette o una funzione, una versione o un alias Lambda eliminati. Se lo strumento di mappatura dell'origine degli eventi ha abilitato le [risposte in batch parziali](services-sqs-errorhandling.md#services-sqs-batchfailurereporting), `FailedInvokeEventCount` include qualsiasi evento con un valore non vuoto `BatchItemFailures` nella risposta.
**Nota**
Il timestamp per il parametro `FailedInvokeEventCount` rappresenta la fine dell'invocazione della funzione. Questo comportamento è diverso dagli altri parametri di errore di invocazione Lambda, che hanno un timestamp all'inizio dell'invocazione della funzione.
+ `DroppedEventCount`: il numero di eventi che Lambda ha interrotto a causa della scadenza o dell'esaurimento dei nuovi tentativi. In particolare, si tratta del numero di record che superano i valori configurati per `MaximumRecordAgeInSeconds` o `MaximumRetryAttempts`. È importante sottolineare che questo non include il numero di record che scadono a causa del superamento delle impostazioni di conservazione dell'origine eventi. Gli eventi eliminati escludono anche gli eventi inviati a una [destinazione in errore](invocation-async-retain-records.md). Utilizza questo parametro per rilevare un aumento del backlog di eventi.
+ `OnFailureDestinationDeliveredEventCount`: per lo strumento di mappatura dell'origine degli eventi con una [destinazione in errore](invocation-async-retain-records.md) configurata, il numero di eventi inviati a tale destinazione. Utilizza questo parametro per monitorare gli errori di funzione relativi alle chiamate da questa origine eventi. Se la consegna alla destinazione non riesce, Lambda gestisce i parametri come segue:
+ Lambda non emette il parametro `OnFailureDestinationDeliveredEventCount`.
+ Per il parametro `DestinationDeliveryFailures`, Lambda emette un 1.
+ Per il parametro `DroppedEventCount`, Lambda emette un numero pari al numero di eventi che hanno avuto esito negativo nella consegna.
+ `DeletedEventCount`: il numero di eventi che Lambda elimina correttamente in seguito all'elaborazione. Se Lambda prova a eliminare un evento ma fallisce, Lambda emette un parametro 0. Utilizza questo parametro per assicurarti che gli eventi elaborati correttamente vengano eliminati dall'origine eventi.
+ `CommittedEventCount`— Il numero di eventi che Lambda ha eseguito con successo dopo l'elaborazione. È una somma dei delta dell'ultimo e dell'ultimo offset commesso da ciascuna partizione nella mappatura delle sorgenti degli eventi di Kafka.
+ `PollingErrorCount`— Il numero di errori che Lambda non è riuscito a controllare le richieste dall'origine dell'evento. Lambda emette questi dati metrici solo quando si verifica un errore.
+ `InvokeErrorCount`— Il numero di errori in cui Lambda non è riuscito a richiamare la tua funzione. Notate che la chiamata è registrata in batch. Il numero è a livello di batch, non a livello di conteggio dei record. Lambda emette questi dati metrici solo quando si verifica un errore.
+ `SchemaRegistryErrorCount`— Il numero di errori che Lambda non è riuscito a recuperare lo schema o a deserializzare con lo schema. Lambda emette questi dati metrici solo quando si verifica un errore.
+ `CommitErrorCount`— Il numero di errori che Lambda non è riuscito a commettere nel cluster Kafka. Lambda emette questi dati metrici solo quando si verifica un errore.
+ `MaxOffsetLag`— Il numero massimo di ritardi di offset (differenza tra gli offset più recenti e quelli confermati) su tutte le partizioni nella mappatura delle sorgenti degli eventi.
+ `SumOffsetLag`— La somma dell'offset è in ritardo su tutte le partizioni nella mappatura della sorgente dell'evento.
Se lo strumento di mappatura dell'origine degli eventi è disabilitato, non riceverai i parametri dello strumento. Potresti anche visualizzare metriche mancanti se CloudWatch o Lambda presenta una disponibilità ridotta.
# Utilizzo dei registri delle funzioni Lambda
Per aiutarti a risolvere i problemi, AWS Lambda monitora automaticamente le funzioni Lambda per tuo conto. Puoi visualizzare i log delle funzioni Lambda utilizzando la console Lambda, la console, CloudWatch la AWS CLI(), AWS Command Line Interface l'API. CloudWatch Puoi anche configurare Lambda per inviare log ad Amazon S3 e Firehose.
Se il [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione dispone delle autorizzazioni necessarie, Lambda acquisisce i log per tutte le richieste gestite dalla funzione e li invia ad CloudWatch Amazon Logs, che è la destinazione predefinita. Puoi anche usare la console Lambda per configurare Amazon S3 o Firehose come destinazioni di registrazione.
+ **CloudWatch Logs** è la destinazione di registrazione predefinita per le funzioni Lambda. CloudWatch Logs offre funzionalità di visualizzazione e analisi dei log in tempo reale, con supporto per la creazione di metriche e allarmi basati sui dati di registro.
+ **Amazon S3** è conveniente per lo storage a lungo termine e servizi come Athena possono essere utilizzati per analizzare i log. La latenza è in genere superiore.
+ **Firehose** offre lo streaming gestito dei log verso varie destinazioni. Se è necessario inviare log ad altri AWS servizi (ad esempio, OpenSearch Service o Redshift Data API) o piattaforme di terze parti (come Datadog, New Relic o Splunk), Firehose semplifica tale processo fornendo integrazioni predefinite. Puoi anche eseguire lo streaming su endpoint HTTP personalizzati senza configurare un'infrastruttura aggiuntiva.
## Scelta della destinazione del servizio a cui inviare i log
Nella scelta di un servizio come destinazione per i registri delle funzioni, tenete conto dei seguenti fattori chiave:
+ **La gestione dei costi varia in base al servizio.** Amazon S3 offre in genere l'opzione più economica per lo storage a lungo termine, mentre CloudWatch Logs consente di visualizzare log, elaborare log e configurare avvisi in tempo reale. I costi di Firehose includono sia il servizio di streaming che i costi associati alla destinazione a cui lo si configura per lo streaming.
+ **Le funzionalità di analisi differiscono tra i servizi.** CloudWatch Logs eccelle nel monitoraggio in tempo reale e si integra nativamente con altre CloudWatch funzionalità, come Logs Insights e Live Tail. Amazon S3 funziona bene con strumenti di analisi come Athena e può integrarsi con vari servizi, sebbene possa richiedere una configurazione aggiuntiva. Firehose semplifica lo streaming diretto verso AWS servizi specifici (come Service OpenSearch e Redshift Data API) e piattaforme di terze parti supportate (come Datadog e Splunk) fornendo integrazioni predefinite, riducendo potenzialmente il lavoro di configurazione.
+ **La configurazione e la facilità d'uso variano in base al servizio.** CloudWatch Logs è la destinazione di log predefinita: funziona immediatamente senza configurazioni aggiuntive e fornisce una visualizzazione e un'analisi dei log semplici tramite la console. CloudWatch Se hai bisogno di inviare i log ad Amazon S3, dovrai eseguire una configurazione iniziale nella console Lambda e configurare le autorizzazioni del bucket. Se avete bisogno di log inviati direttamente a servizi come OpenSearch Service o piattaforme di analisi di terze parti, Firehose può semplificare tale processo.
## Configurazione delle destinazioni dei log
AWS Lambda supporta più destinazioni per i registri delle funzioni. Questa guida spiega le destinazioni di registrazione disponibili e ti aiuta a scegliere l'opzione giusta per le tue esigenze. Indipendentemente dalla destinazione scelta, Lambda offre opzioni per controllare il formato, il filtraggio e la consegna dei log.
Lambda supporta sia i formati JSON che quelli di testo semplice per i log delle funzioni. I log strutturati JSON offrono una migliore ricercabilità e consentono l'analisi automatizzata, mentre i log di testo semplice offrono semplicità e costi di archiviazione potenzialmente ridotti. Puoi controllare quali log Lambda invia alla destinazione prescelta configurando i livelli di registro per i log di sistema e delle applicazioni. Il filtraggio consente di gestire i costi di archiviazione e semplifica la ricerca delle voci di registro pertinenti durante il debug.
Per istruzioni di configurazione dettagliate per ciascuna destinazione, consulta le seguenti sezioni:
+ [Lambda invia automaticamente i log delle funzioni a CloudWatch Logs.](monitoring-cloudwatchlogs.md)
+ [Invio dei log delle funzioni Lambda a Firehose](logging-with-firehose.md)
+ [Invio di log delle funzioni Lambda ad Amazon S3](logging-with-s3.md)
## Configurazione dei controlli di registrazione avanzati per le funzioni Lambda
Per darti un maggiore controllo sul modo in cui i log delle funzioni vengono acquisiti, elaborati e consumati, Lambda offre le seguenti opzioni di configurazione della registrazione:
+ **Formato di registro**: scegli tra testo semplice e formato JSON strutturato per i log della tua funzione.
+ **Livello di registro**: per i log strutturati JSON, scegli il livello di dettaglio dei log a cui Lambda invia, CloudWatch ad esempio`FATAL`,,`ERROR`,`WARN`, `INFO` e. `DEBUG` `TRACE`
+ **Gruppo di log**: scegli il gruppo di CloudWatch log a cui la funzione invia i log.
Per ulteriori informazioni sulla configurazione dei controlli di registrazione avanzati, consulta le seguenti sezioni:
+ [Configurazione dei formati di log JSON e testo normale](monitoring-cloudwatchlogs-logformat.md)
+ [Filtraggio a livello di log](monitoring-cloudwatchlogs-log-level.md)
+ [Configurazione dei gruppi di CloudWatch log](monitoring-cloudwatchlogs-loggroups.md)
# Configurazione dei formati di log JSON e testo normale
L'acquisizione degli output log come coppie chiave-valore JSON semplifica la ricerca e il filtraggio durante il debug delle funzioni. Con i log in formato JSON, puoi aggiungere ai log anche tag e informazioni contestuali. Questo può aiutarti a eseguire analisi automatizzate di grandi volumi di dati di log. A meno che il flusso di lavoro di sviluppo non si basi su strumenti esistenti che utilizzano i log Lambda in testo normale, ti consigliamo di selezionare JSON come formato di log.
**Istanze Lambda gestite**
Le istanze gestite Lambda supportano solo il formato di registro JSON. Quando crei una funzione Managed Instances, Lambda configura automaticamente il formato di registro in JSON e non è possibile modificarlo in testo semplice. Per ulteriori informazioni sulle istanze gestite, consulta. [Istanze Lambda gestite](lambda-managed-instances.md)
Per tutti i runtime gestiti da Lambda, puoi scegliere se inviare i log di sistema della funzione a CloudWatch Logs in formato testo semplice non strutturato o JSON. I log di sistema sono i log generati da Lambda e a volte vengono chiamati log eventi della piattaforma.
Per i [runtime supportati](#monitoring-cloudwatchlogs-logformat-supported), quando si utilizza uno dei metodi di registrazione integrati supportati, Lambda può anche generare i log delle applicazioni della funzione (i log generati dal codice della funzione) in formato JSON strutturato. Quando configuri il formato di log della funzione per questi runtime, la configurazione scelta si applica sia ai log di sistema sia a quelli delle applicazioni.
Per i runtime supportati, se la funzione utilizza una libreria o un metodo di registrazione supportato, non è necessario apportare modifiche al codice esistente per Lambda per acquisire i log in formato JSON strutturato.
**Nota**
L'utilizzo della formattazione dei log JSON aggiunge metadati aggiuntivi e codifica i messaggi di log come oggetti JSON contenenti una serie di coppie chiave-valore. Per questo motivo, la dimensione dei messaggi di log della funzione può aumentare.
## Runtime e metodi di registrazione supportati
Lambda attualmente supporta l'opzione di generare i log delle applicazioni in formato JSON strutturato per i seguenti runtime.
| Lingua | Versioni supportate |
| --- | --- |
| Java | Tutti i runtime Java eccetto Java 8 su Amazon Linux 1 |
| .NET | .NET 8 e versioni successive |
| Node.js | Node.js 16 e versioni successive |
| Python | Python 3.8 e versioni successive |
| Rust | N/A |
Affinché Lambda invii i log delle applicazioni della funzione CloudWatch in formato JSON strutturato, la funzione deve utilizzare i seguenti strumenti di registrazione integrati per generare i log:
+ **Java**: il logger o Log4j2. `LambdaLogger` Per ulteriori informazioni, consulta [Registrare e monitorare funzioni Lambda in Java](java-logging.md).
+ **.NET**: l'`ILambdaLogger`istanza sull'oggetto contestuale. Per ulteriori informazioni, consulta [Registrare e monitorare le funzioni Lambda con C\$1](csharp-logging.md).
+ **Node.js**: i metodi della console `console.trace` `console.debug``console.log`,`console.info`,`console.error`, e`console.warn`. Per ulteriori informazioni, consulta [Registrare e monitorare funzioni Lambda in Node.js](nodejs-logging.md).
+ **Python**: la libreria Python standard. `logging` Per ulteriori informazioni, consulta [Registrare e monitorare le funzioni Lambda con Python](python-logging.md).
+ **Rust**: La cassa. `tracing` Per ulteriori informazioni, consulta [Registrare e monitorare le funzioni Lambda con Rust](rust-logging.md).
Per altri runtime Lambda gestiti, Lambda attualmente supporta nativamente solo l'acquisizione dei log di sistema in formato JSON strutturato. Tuttavia, è ancora possibile acquisire i log delle applicazioni in formato JSON strutturato in qualsiasi runtime utilizzando strumenti di registrazione come Powertools per AWS Lambda generare output di log in formato JSON.
## Formati di log predefiniti
Attualmente, il formato di log predefinito per tutti i runtime Lambda è il testo normale. Per le istanze gestite Lambda, il formato di registro è sempre JSON e non può essere modificato.
Se utilizzi già librerie di registrazione come Powertools AWS Lambda per generare i log delle funzioni in formato strutturato JSON, non devi modificare il codice se selezioni la formattazione dei log JSON. Lambda non codifica due volte i log che sono già codificati in JSON, quindi i log delle applicazioni della funzione continueranno a essere acquisiti come prima.
## Formato JSON per i log di sistema
Quando configuri il formato di log della funzione come JSON, ogni elemento del log di sistema (evento della piattaforma) viene acquisito come un oggetto JSON contenente coppie chiave-valore con le seguenti chiavi:
+ `"time"`: l'ora in cui è stato generato il messaggio di log
+ `"type"`: il tipo di evento che viene registrato
+ `"record"`: il contenuto dell'output log
Il formato del valore `"record"` varia in base al tipo di evento registrato. Per ulteriori informazioni, consulta [Tipi di oggetti `Event` dell'API di telemetria](telemetry-schema-reference.md#telemetry-api-events). Per ulteriori informazioni sui livelli di log assegnati ai log eventi di sistema, consulta la pagina [Strumento di mappatura degli eventi a livello di log di sistema](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping).
A titolo di confronto, i due esempi seguenti mostrano lo stesso output log in formato di testo normale e in formato JSON strutturato. Tieni presente che, nella maggior parte dei casi, i log eventi di sistema contengono più informazioni quando vengono emessi in formato JSON rispetto a quando vengono emessi in testo normale.
**Example testo normale:**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example JSON strutturato:**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**Nota**
L'[Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry](telemetry-api.md) emette sempre eventi della piattaforma come `START` e `REPORT` in formato JSON. La configurazione del formato dei log di sistema a cui Lambda invia CloudWatch non influisce sul comportamento dell'API Lambda Telemetry.
## Formato JSON per i log delle applicazioni
Quando configuri il formato di log della funzione come JSON, gli output di log delle applicazioni scritti utilizzando le librerie e i metodi di registrazione di log supportati vengono acquisiti come oggetti JSON che contengono coppie chiave-valore con le chiavi riportate di seguito.
+ `"timestamp"`: l'ora in cui è stato generato il messaggio di log
+ `"level"`: il livello di log assegnato al messaggio
+ `"message"`: il contenuto del messaggio di log
+ `"requestId"` (Python, .NET e Node.js) o `"AWSrequestId"` (Java): l'ID di richiesta univoco per l'invocazione della funzione
A seconda del runtime e del metodo di registrazione di log utilizzato dalla funzione, questo oggetto JSON può anche contenere coppie di chiavi aggiuntive. Ad esempio, in Node.js, se la funzione utilizza metodi della `console` per registrare i log degli oggetti di errore con più argomenti, l'oggetto JSON conterrà coppie chiave-valore aggiuntive con le chiavi `errorMessage`, `errorType` e `stackTrace`. Per ulteriori informazioni sui log in formato JSON in diversi runtime Lambda, consulta [Registrare e monitorare le funzioni Lambda con Python](python-logging.md), [Registrare e monitorare funzioni Lambda in Node.js](nodejs-logging.md) e [Registrare e monitorare funzioni Lambda in Java](java-logging.md).
**Nota**
La chiave utilizzata da Lambda per il valore del timestamp è diversa per i log di sistema e i log delle applicazioni. Per i log di sistema, Lambda utilizza la chiave `"time"` per mantenere la coerenza con l'API di telemetria. Per i log delle applicazioni, Lambda segue le convenzioni dei runtime supportati e utilizza `"timestamp"`.
A titolo di confronto, i due esempi seguenti mostrano lo stesso output log in formato di testo normale e in formato JSON strutturato.
**Example testo normale:**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example JSON strutturato:**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## Impostazione del formato di log della funzione
Per configurare il formato di registro per la tua funzione, puoi usare la console Lambda o il AWS Command Line Interface ()AWS CLI. Puoi anche configurare il formato di registro di una funzione utilizzando i comandi [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)e l'API [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Lambda, la risorsa AWS Serverless Application Model (AWS SAM) e la [AWS::Serverless::Function CloudFormation[AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)risorsa.
La modifica del formato di registro della funzione non influisce sui log esistenti archiviati in CloudWatch Logs. Solo i nuovi log utilizzeranno il formato aggiornato.
Se modifichi il formato di log della funzione in JSON e non imposti il livello di log, Lambda imposta in automatico il livello di log dell'applicazione e il livello di log del sistema della funzione su INFO. Ciò significa che Lambda invia solo output di log di livello INFO e inferiore a Logs. CloudWatch Per ulteriori informazioni sul filtraggio a livello di log di applicazioni e sistemi, consulta [Filtraggio a livello di log](monitoring-cloudwatchlogs-log-level.md)
**Nota**
Per i runtime Python, quando il formato di log della funzione è impostato su testo semplice, l'impostazione predefinita a livello di log è WARN. Ciò significa che Lambda invia solo output di log di livello WARN e inferiore a Logs. CloudWatch La modifica del formato di log della funzione in JSON modifica questo comportamento predefinito. Per ulteriori informazioni sulla registrazione di log in Python, consulta [Registrare e monitorare le funzioni Lambda con Python](python-logging.md).
Per le funzioni Node.js che emettono log in formato EMF (Embedded Metric Format), la modifica del formato di registro della funzione in JSON potrebbe comportare l'impossibilità di riconoscere le metriche. CloudWatch
**Importante**
Se la vostra funzione utilizza Powertools for AWS Lambda (TypeScript) o le librerie client EMF open source per emettere i log EMF, aggiornate le librerie [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) ed [EMF](https://www.npmjs.com/package/aws-embedded-metrics) alle versioni più recenti per assicurarvi che possa continuare ad analizzare i log correttamente. CloudWatch Se passi al formato di log JSON, ti consigliamo anche di eseguire dei test per garantire la compatibilità con i parametri incorporati della tua funzione. Per ulteriori consigli sulle funzioni node.js che emettono log EMF, consulta la pagina [Utilizzo di librerie client formato del parametro incorporato (EMF) con log JSON strutturati](nodejs-logging.md#nodejs-logging-advanced-emf).
**Configurazione del formato di log di una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione
1. Nella pagina di configurazione della funzione, scegli **Strumenti di monitoraggio e gestione**.
1. Nel riquadro **Configurazione della registrazione**, scegli **Modifica**.
1. In **Contenuto del log**, per **Formato del log** seleziona **Testo** o **JSON**.
1. Scegli **Save** (Salva).
**Modifica del formato di log di una funzione esistente (AWS CLI)**
+ Per modificare il formato di log di una funzione esistente, utilizza il comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Imposta l'opzione `LogFormat` in `LoggingConfig` su `JSON` o `Text`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**Configurazione del formato di log durante la creazione di una funzione (AWS CLI)**
+ Per configurare il formato di log quando crei una nuova funzione, utilizza l'opzione `--logging-config` nel comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Impostare `LogFormat` su `JSON` o su `Text`. Il comando di esempio seguente crea una funzione Node.js che genera i log in formato JSON strutturato.
Se non specifichi un formato di log quando crei una funzione, Lambda utilizzerà il formato di log predefinito per la versione di runtime selezionata. Per informazioni sui formati di registrazione predefiniti, consulta la pagina [Formati di log predefiniti](#monitoring-cloudwatchlogs-format-default).
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON
```
# Filtraggio a livello di log
Lambda può filtrare i log della funzione in modo che solo i log con un certo livello di dettaglio o inferiore vengano inviati a Logs. CloudWatch Puoi configurare il filtraggio a livello di log separatamente per i log di sistema della funzione (i log generati da Lambda) e i log delle applicazioni (i log generati dal codice della funzione).
Per [Runtime e metodi di registrazione supportati](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported), non è necessario apportare modifiche al codice della funzione per Lambda per filtrare i log delle applicazioni della funzione in Lambda.
Per tutti gli altri runtime e metodi di registrazione, il codice della funzione deve generare log eventi in `stdout` o `stderr` come oggetti in formato JSON contenenti una coppia chiave-valore con la chiave `"level"`. Ad esempio, Lambda interpreta il seguente output su `stdout` come un log di livello DEBUG.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
Se il campo del valore `"level"` non è valido o è assente, Lambda assegnerà all'output log il livello INFO. Affinché Lambda utilizzi il campo timestamp, è necessario specificare l'ora in un formato timestamp [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) valido. Se non fornisci un timestamp valido, Lambda assegnerà al log il livello INFO e aggiungerà un timestamp per tuo conto.
Quando assegni un nome alla chiave timestamp, segui le convenzioni del runtime che stai utilizzando. Lambda supporta le convenzioni di denominazione più comuni utilizzate dai runtime gestiti.
**Nota**
Per utilizzare il filtraggio a livello di log, la funzione deve essere configurata per utilizzare il formato di log JSON. Attualmente, il formato di log predefinito per tutti i runtime gestiti da Lambda è il testo normale. Per informazioni su come impostare il formato di log della funzione su JSON, consulta la pagina [Impostazione del formato di log della funzione](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format).
Per i log delle applicazioni (i log generati dal codice della funzione), puoi scegliere tra i seguenti livelli di log.
| Livello di log | Utilizzo standard |
| --- | --- |
| TRACE (dettaglio massimo) | Le informazioni più dettagliate utilizzate per tracciare il percorso di esecuzione del codice |
| DEBUG | Informazioni dettagliate per il debug del sistema |
| INFO | Messaggi che registrano il normale funzionamento della funzione |
| WARN | Messaggi relativi a potenziali errori che possono portare a comportamenti imprevisti se non risolti |
| ERRORE | Messaggi relativi a problemi che impediscono al codice di funzionare come previsto |
| FATAL (dettaglio minimo) | Messaggi relativi a errori gravi che causano l'interruzione del funzionamento dell'applicazione |
Quando si seleziona un livello di registro, Lambda invia i log a quel livello e successivamente a Logs. CloudWatch Ad esempio, se imposti il livello di log dell'applicazione di una funzione su WARN, Lambda non invia output log ai livelli INFO e DEBUG. Il livello di log dell'applicazione predefinito per il filtraggio dei log è INFO.
Quando Lambda filtra i log delle applicazioni della funzione, ai messaggi di log senza livello verrà assegnato il livello di log INFO.
Per i log di sistema (i log generati dal servizio Lambda), puoi scegliere tra i seguenti livelli di log.
| Livello di log | Utilizzo |
| --- | --- |
| DEBUG (dettaglio massimo) | Informazioni dettagliate per il debug del sistema |
| INFO | Messaggi che registrano il normale funzionamento della funzione |
| WARN (dettaglio minimo) | Messaggi relativi a potenziali errori che possono portare a comportamenti imprevisti se non risolti |
Quando si seleziona un livello di log, Lambda invia i log di quel livello e di livello inferiore. Ad esempio, se imposti il livello di log di sistema di una funzione su INFO, Lambda non invia output log a livello DEBUG.
Per impostazione predefinita, Lambda imposta il livello di log del sistema su INFO. Con questa impostazione, Lambda invia `"start"` e `"report"` registra automaticamente i messaggi a. CloudWatch Per ricevere log di sistema più o meno dettagliati, modifica il livello di log in DEBUG o WARN. Per visualizzare un elenco dei livelli di log a cui Lambda mappa i diversi log eventi di sistema, consulta la pagina [Strumento di mappatura degli eventi a livello di log di sistema](#monitoring-cloudwatchlogs-log-level-mapping).
## Configurazione del filtraggio a livello di log
Per configurare il filtro a livello di registro dell'applicazione e del sistema per la tua funzione, puoi utilizzare la console Lambda o il (). AWS Command Line Interface AWS CLI Puoi anche configurare il livello di registro di una funzione utilizzando i comandi [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)e l'API [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Lambda, la risorsa AWS Serverless Application Model (AWS SAM) e la [AWS::Serverless::Function CloudFormation[AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)risorsa.
Tieni presente che se imposti il livello di log della funzione nel codice, questa impostazione ha la precedenza su qualsiasi altra impostazione del livello di log che configuri. Ad esempio, se utilizzi il metodo `logging` `setLevel()` di Python per impostare il livello di registrazione di log della funzione su INFO, questa impostazione ha la precedenza su un'impostazione di WARN configurata utilizzando la console Lambda.
**Configurazione del livello di log dell'applicazione o di sistema di una funzione esistente (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. Nella pagina di configurazione della funzione, scegli **Strumenti di monitoraggio e gestione**.
1. Nel riquadro **Configurazione della registrazione**, scegli **Modifica**.
1. In **Contenuto del log**, per **Formato del log** assicurati che sia selezionato **JSON**.
1. Utilizzando i pulsanti di opzione, seleziona i valori di **Livello di log dell'applicazione** e **Livello di log del sistema** desiderati per la funzione.
1. Scegli **Save** (Salva).
**Configurazione del livello di log dell'applicazione o di sistema di una funzione esistente (AWS CLI)**
+ Per modificare il livello di log dell'applicazione o del sistema di una funzione esistente, utilizza il comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Utilizza `--logging-config` per impostare `SystemLogLevel` su `DEBUG`, `INFO` o `WARN`. Imposta `ApplicationLogLevel` su `DEBUG`, `INFO`, `WARN`, `ERROR` o `FATAL`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**Configurazione del filtraggio a livello di log durante la creazione di una funzione**
+ Per configurare il filtraggio a livello di log quando crei una nuova funzione, utilizza `--logging-config` per impostare le chiavi `SystemLogLevel` e `ApplicationLogLevel` nel comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Imposta `SystemLogLevel` su `DEBUG`, `INFO` o `WARN`. Imposta `ApplicationLogLevel` su `DEBUG`, `INFO`, `WARN`, `ERROR` o `FATAL`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## Strumento di mappatura degli eventi a livello di log di sistema
Per gli eventi di log a livello di sistema generati da Lambda, la tabella seguente definisce il livello di log assegnato a ciascun evento. Per ulteriori informazioni sugli eventi elencati nella tabella, consulta la pagina [Riferimento allo schema `Event` dell'API di telemetria Lambda](telemetry-schema-reference.md)
| Nome evento | Condizione | Livello di log assegnato |
| --- | --- | --- |
| initStart | runtimeVersion è impostato | INFO |
| initStart | runtimeVersion non è impostato | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status=success | WARN |
| initReport | initializationType\$1=on-demand | INFO |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status=success | WARN |
| restoreStart | runtimeVersion è impostato | INFO |
| restoreStart | runtimeVersion non è impostato | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status=success | WARN |
| restoreReport | status=success | INFO |
| restoreReport | status=success | WARN |
| rapida | - | INFO |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status=success | WARN |
| report | status=success | INFO |
| report | status=success | WARN |
| Estensione | state=success | INFO |
| Estensione | state\$1=success | WARN |
| logSubscription | - | INFO |
| telemetrySubscription | - | INFO |
| logsDropped | - | WARN |
**Nota**
L'[Accesso ai dati di telemetria in tempo reale per le estensioni tramite l'API Telemetry](telemetry-api.md) emette sempre il set completo di eventi della piattaforma. La configurazione del livello dei log di sistema a cui Lambda invia CloudWatch non influisce sul comportamento dell'API Lambda Telemetry.
## Filtraggio delle applicazioni a livello di log con runtime personalizzati
Quando configuri il filtraggio a livello di log dell'applicazione per la tua funzione, dietro le quinte Lambda imposta il livello di log dell'applicazione nel runtime utilizzando la variabile di ambiente `AWS_LAMBDA_LOG_LEVEL`. Lambda imposta anche il formato di log della funzione utilizzando la variabile di ambiente `AWS_LAMBDA_LOG_FORMAT`. Puoi utilizzare queste variabili per integrare i controlli di registrazione avanzati di Lambda in un [runtime personalizzato](runtimes-custom.md).
Per poter configurare le impostazioni di registrazione per una funzione utilizzando un runtime personalizzato con la console Lambda e APIs Lambda AWS CLI, configura il runtime personalizzato per controllare il valore di queste variabili di ambiente. È quindi possibile configurare i logger del runtime in base al formato di log e ai livelli di log selezionati.
# Lambda invia automaticamente i log delle funzioni a CloudWatch Logs.
Per impostazione predefinita, Lambda acquisisce automaticamente i log per tutte le chiamate di funzione e li invia a CloudWatch Logs, a condizione che il ruolo di esecuzione della funzione disponga delle autorizzazioni necessarie. Per impostazione predefinita, questi log sono archiviati in un gruppo di log denominato** /aws/lambda/. Per migliorare il debug, puoi inserire istruzioni di registrazione personalizzate nel codice, che Lambda integrerà perfettamente con CloudWatch Logs. Se desideri che la tua funzione invii i log a un altro gruppo, puoi configurarlo utilizzando la console Lambda, AWS CLI o l'API Lambda. Per ulteriori informazioni, consulta [Configurazione dei gruppi di CloudWatch log](monitoring-cloudwatchlogs-loggroups.md).
Puoi visualizzare i log per le funzioni Lambda tramite la console Lambda, la console CloudWatch, la console AWS Command Line Interface (AWS CLI) o l'API CloudWatch. Per ulteriori informazioni, consulta la pagina [Visualizzazione dei CloudWatch log per le funzioni Lambda](monitoring-cloudwatchlogs-view.md).
**Nota**
Potrebbero essere necessari da 5 a 10 minuti prima che i log vengano visualizzati dopo una chiamata di funzione.
## Autorizzazioni IAM richieste
Il [ruolo di esecuzione](lambda-intro-execution-role.md) richiede la seguente autorizzazione per caricare i log in CloudWatch Logs:
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
Per ulteriori informazioni, consulta [Utilizzo delle policy basate su identità (policy IAM) per CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html) nella *Guida per l'utente di Amazon CloudWatch*.
È possibile aggiungere le autorizzazioni CloudWatch Logs utilizzando la policy gestita `AWSLambdaBasicExecutionRole` AWS fornita da Lambda. Per aggiungere questa policy al ruolo, esegui il seguente comando:
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Per ulteriori informazioni, consulta [Utilizzo delle politiche AWS gestite nel ruolo di esecuzione](permissions-managed-policies.md).
## Prezzi
Non sono previsti costi aggiuntivi per l'utilizzo dei log di Lambda, ma vengono applicati i costi CloudWatch Logs standard. Per ulteriori informazioni, consultare la pagina dei [prezzi di CloudWatch](https://aws.amazon.com/cloudwatch/pricing/)
# Configurazione dei gruppi di CloudWatch log
Per impostazione predefinita, crea CloudWatch automaticamente un gruppo di log denominato in base alla funzione quando viene richiamata `/aws/lambda/` per la prima volta. Per configurare la tua funzione per l'invio dei log a un gruppo di log esistente o per creare un nuovo gruppo di log per la funzione, puoi utilizzare la console Lambda o la AWS CLI. Puoi anche configurare gruppi di log personalizzati utilizzando i comandi API [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)e [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Lambda e la risorsa AWS Serverless Application Model (AWS SAM) [AWS: :Serverless: :Function]().
È possibile configurare più funzioni Lambda per inviare i log allo stesso CloudWatch gruppo di log. Ad esempio, è possibile utilizzare un singolo gruppo di log per archiviare i log per tutte le funzioni Lambda che costituiscono una particolare applicazione. Quando si utilizza un gruppo di log personalizzato per una funzione Lambda, i flussi di log creati da Lambda includono il nome e la versione della funzione. Ciò garantisce che la mappatura tra i messaggi di log e le funzioni venga preservata, anche se si utilizza lo stesso gruppo di log per più funzioni.
Il formato di denominazione per i flussi di log per i gruppi di log personalizzati segue questa convenzione:
```
YYYY/MM/DD/[][]
```
Tieni presente che quando configuri un gruppo di log personalizzato, il nome selezionato per il gruppo di log deve seguire le regole di denominazione dei [CloudWatch log](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html). Inoltre, i nomi dei gruppi di log personalizzati non devono cominciare con la stringa `aws/`. Se crei un gruppo di log personalizzato che comincia con `aws/`, Lambda non sarà in grado di crearlo. Di conseguenza, i log della funzione non verranno inviati a. CloudWatch
**Modifica del gruppo di log di una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. Nella pagina di configurazione della funzione, scegli **Strumenti di monitoraggio e gestione**.
1. Nel riquadro **Configurazione della registrazione**, scegli **Modifica**.
1. **Nel riquadro **Logging group**, per il **gruppo di CloudWatch log**, scegli Personalizzato.**
1. In **Gruppo di log personalizzato**, inserisci il nome del gruppo di CloudWatch log a cui desideri che la funzione invii i log. Se immetti il nome di un gruppo di log esistente, la funzione utilizzerà quel gruppo. Se non esiste alcun gruppo di log con il nome immesso, Lambda creerà un nuovo gruppo di log per la funzione con tale nome.
**Modifica del gruppo di log di una funzione (AWS CLI)**
+ Per modificare il gruppo di log di una funzione esistente, utilizza il comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html).
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**Definizione di un gruppo di log personalizzato durante la creazione di una funzione (AWS CLI)**
+ Per specificare un gruppo di log personalizzato quando si crea una nuova funzione Lambda utilizzando AWS CLI, utilizzare l'`--logging-config`opzione. Il comando di esempio seguente crea una funzione Lambda Node.js che invia i log a un gruppo di log denominato `myLogGroup`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## Autorizzazioni del ruolo di esecuzione
Per inviare i log a CloudWatch Logs, la funzione deve disporre dell'autorizzazione [logs](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html):. PutLogEvents Quando configuri il gruppo di log della tua funzione utilizzando la console Lambda, Lambda aggiungerà questa autorizzazione al ruolo nelle seguenti condizioni:
+ La destinazione del servizio è impostata su Logs CloudWatch
+ Il ruolo di esecuzione della funzione non dispone delle autorizzazioni per caricare i log in CloudWatch Logs (la destinazione predefinita)
**Nota**
Lambda non aggiunge alcuna autorizzazione Put per le destinazioni di log di Amazon S3 o Firehose.
Quando Lambda aggiunge questo permesso, concede alla funzione il permesso di inviare i log a qualsiasi gruppo di log CloudWatch Logs.
Per evitare che Lambda aggiorni automaticamente il ruolo di esecuzione della funzione e modificarlo invece manualmente, espandi **Autorizzazioni** e deseleziona **Aggiungi autorizzazioni richieste.**
Quando configuri il gruppo di log della tua funzione utilizzando AWS CLI, Lambda non aggiungerà automaticamente l'`logs:PutLogEvents`autorizzazione. Aggiungi l'autorizzazione al ruolo di esecuzione della tua funzione, se non ne dispone già. Questa autorizzazione è inclusa nella politica [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor)gestita.
## CloudWatch registrazione per istanze gestite Lambda
Quando si utilizzano [le istanze gestite da Lambda](lambda-managed-instances.md), ci sono ulteriori considerazioni per l'invio dei log ai log: CloudWatch
### Requisiti di rete VPC
Le istanze gestite Lambda vengono eseguite su istanze di proprietà del cliente all'interno EC2 del tuo VPC. Per inviare i log a CloudWatch Logs and trace to X-Ray, devi assicurarti che AWS APIs siano instradabili dal tuo VPC. A questo scopo, sono disponibili numerose opzioni:
+ **AWS PrivateLink (consigliato)**: [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)Da utilizzare per creare endpoint VPC per i servizi CloudWatch Logs e X-Ray. Ciò consente alle istanze di accedere a questi servizi in modo privato senza richiedere un gateway Internet o un gateway NAT. Per ulteriori informazioni, consulta [Utilizzo dei CloudWatch log con gli endpoint VPC dell'interfaccia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html).
+ Gateway **NAT: configura un gateway** NAT per consentire l'accesso a Internet in uscita dalle sottoreti private.
+ **Gateway Internet**: per le sottoreti pubbliche, assicurati che il tuo VPC abbia un gateway Internet configurato.
Se CloudWatch Logs o APIs X-Ray non sono instradabili dal tuo VPC, i log e le tracce delle funzioni non verranno consegnati.
### Richiamazioni simultanee e attribuzione dei log
Gli ambienti di esecuzione di Lambda Managed Instances possono elaborare più chiamate contemporaneamente. Quando vengono eseguite più chiamate contemporaneamente, le relative voci di registro vengono interlacciate nello stesso flusso di log. Per filtrare e analizzare efficacemente i log delle chiamate simultanee, è necessario assicurarsi che ogni voce di registro includa l'ID della richiesta. AWS
Consigliamo uno dei seguenti approcci:
+ **Usa logger di runtime Lambda predefiniti (consigliato)**: le librerie di registrazione predefinite fornite dai runtime gestiti da Lambda includono automaticamente l'ID della richiesta in ogni voce di registro.
+ **Implementa la registrazione JSON strutturata**: se stai creando un [runtime personalizzato o hai bisogno di una registrazione personalizzata](runtimes-custom.md), implementa log in formato JSON che includono l'ID della richiesta in ogni voce. Le istanze gestite Lambda supportano solo il formato di log JSON. Includi il `requestId` campo nei log JSON per abilitare il filtraggio per chiamata:
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
Con l'attribuzione dell'ID della richiesta, puoi filtrare le voci di registro di CloudWatch Logs per una chiamata specifica utilizzando le query di Logs Insights. CloudWatch Esempio:
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Per ulteriori informazioni sui requisiti di registrazione delle istanze gestite di Lambda, vedere. [Comprendere l'ambiente di esecuzione di Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
# Visualizzazione dei CloudWatch log per le funzioni Lambda
Puoi visualizzare CloudWatch i log di Amazon per la tua funzione Lambda utilizzando la console Lambda, CloudWatch la console o il (). AWS Command Line Interface AWS CLI Segui le istruzioni riportate nelle sezioni seguenti per accedere ai log della funzione.
## Trasmetti in streaming i log delle funzioni con Logs Live Tail CloudWatch
Amazon CloudWatch Logs Live Tail ti aiuta a risolvere rapidamente i problemi delle tue funzioni visualizzando un elenco in streaming di nuovi eventi di registro direttamente nella console Lambda. Puoi visualizzare e filtrare i log importati dalle funzioni Lambda in tempo reale, in modo da poter rilevare e risolvere rapidamente i problemi.
**Nota**
Le sessioni Live Tail comportano costi al minuto in base al tempo di utilizzo della sessione. Per ulteriori informazioni sui prezzi, consulta la pagina [ CloudWatch dei prezzi di Amazon](https://aws.amazon.com/cloudwatch/pricing/).
### Confronto tra Live Tail e --log-type Tail
Esistono diverse differenze tra CloudWatch Logs Live Tail e l'opzione [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) nell'API Lambda `--log-type Tail` (in AWS CLI):
+ `--log-type Tail` restituisce solo i primi 4 KB dei log di invocazione. Live Tail non condivide questo limite e può ricevere fino a 500 eventi del log al secondo.
+ `--log-type Tail` acquisisce e invia i log con la risposta, il che può influire sulla latenza di risposta della funzione. Live Tail non influisce sulla latenza di risposta della funzione.
+ `--log-type Tail` supporta solo chiamate sincrone. Live Tail funziona sia per le invocazioni sincrone che asincrone.
**Nota**
[Lambda Managed Instances](lambda-managed-instances.md) non supporta l'opzione. `--log-type Tail` Usa CloudWatch Logs Live Tail o interroga direttamente CloudWatch Logs per visualizzare i log delle funzioni delle istanze gestite.
### Permissions
Le seguenti autorizzazioni sono necessarie per avviare e interrompere CloudWatch le sessioni di Logs Live Tail:
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Avviare una sessione Live Tail nella console Lambda
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere il nome della funzione.
1. Seleziona la scheda **Test**.
1. Nel riquadro **Test event**, scegli **CloudWatch Logs** Live Tail.
1. Per **Seleziona gruppi di log**, il gruppo di log della funzione è selezionato per impostazione predefinita. È possibile selezionare fino a cinque gruppi di log alla volta.
1. (Facoltativo) Per visualizzare solo gli eventi del log che contengono determinate parole o altre stringhe, inserisci la parola o la stringa nella casella **Aggiungi modello di filtro**. I filtri fanno distinzione tra maiuscole e minuscole. Puoi includere più termini e operatori di modelli in questo campo, comprese le espressioni regolari (regex). Per ulteriori informazioni sulla sintassi dei pattern, consulta [Filter pattern syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html). nella *Amazon CloudWatch Logs* User Guide.
1. Scegli **Avvia**. I log eventi corrispondenti vengono visualizzati nella finestra.
1. Per arrestare la sessione Live Tail, scegli **Arresta**.
**Nota**
La sessione Live Tail si interrompe automaticamente dopo 15 minuti di inattività o quando la sessione della console Lambda scade.
## Accedere ai log della funzione tramite la console
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Seleziona una funzione.
1. Selezionare la scheda **Monitor (Monitora)**.
1. Scegli **Visualizza CloudWatch i log** per aprire la console. CloudWatch
1. Scorri verso il basso e scegli il **flusso di log** per le invocazioni delle funzioni che desideri esaminare.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/log-stream.png)
Ogni istanza di una funzione Lambda ha un flusso di log dedicato. Se una funzione aumenta, ogni istanza simultanea ha il suo flusso di log. Ogni volta che viene creato un nuovo ambiente di esecuzione in risposta a una chiamata, viene generato un nuovo flusso di log. La convenzione di denominazione per i flussi di log è:
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
Un singolo ambiente di esecuzione scrive sullo stesso flusso di log durante il suo ciclo di vita. Il flusso di log contiene i messaggi provenienti da quell'ambiente di esecuzione e anche qualsiasi output del codice della funzione Lambda. Ogni messaggio ha un timestamp, compresi i log personalizzati. Anche se la funzione non registra alcun output dal codice, vengono generate tre istruzioni di log minime per ogni invocazione (START, END e REPORT):
![\[monitoraggio dell'osservabilità (figura 3)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-3.png)
Questi log mostrano:
+ **RequestId**— si tratta di un ID univoco generato per richiesta. Se la funzione Lambda ritenta una richiesta, questo ID non cambia e viene visualizzato nei log per ogni tentativo successivo.
+ **Start/End**: contrassegnano una singola chiamata ai segnalibri, quindi ogni riga di registro compresa tra queste appartiene alla stessa invocazione.
+ **Durata: il tempo** totale di invocazione per la funzione di gestione, codice escluso. `INIT`
+ **Durata fatturata**: applica la logica di arrotondamento ai fini della fatturazione.
+ **Dimensione della memoria**: la quantità di memoria allocata alla funzione.
+ **Memoria massima utilizzata**: la quantità massima di memoria utilizzata durante la chiamata.
+ **Durata di inizializzazione**: il tempo impiegato per eseguire la `INIT` sezione di codice, al di fuori del gestore principale.
## Accedi ai log con AWS CLI
AWS CLI È uno strumento open source che consente di interagire con i AWS servizi utilizzando i comandi nella shell della riga di comando. Per completare le fasi riportate in questa sezione, è necessario disporre della [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
È possibile utilizzare [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) per recuperare i log per una chiamata utilizzando l'opzione di comando `--log-type`. La risposta include un campo `LogResult` che contiene fino a 4 KB di log con codifica base64 del richiamo.
**Example recuperare un ID di log**
Nell'esempio seguente viene illustrato come recuperare un *ID di log* dal `LogResult` campo per una funzione denominata `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Verrà visualizzato l’output seguente:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example decodificare i log**
Nello stesso prompt dei comandi, utilizzare l'`base64` utilità per decodificare i log. Nell'esempio seguente viene illustrato come recuperare i log codificati in base64 per `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
Verrà visualizzato l’output seguente:
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L'utilità `base64` è disponibile su Linux, macOS e [Ubuntu su Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Gli utenti macOS potrebbero dover utilizzare `base64 -D`.
**Example Script get-logs.sh**
Nello stesso prompt dei comandi, utilizzare lo script seguente per scaricare gli ultimi cinque eventi di log. Lo script utilizza `sed` per rimuovere le virgolette dal file di output e rimane in sospensione per 15 secondi in attesa che i log diventino disponibili. L'output include la risposta di Lambda e l'output del comando `get-log-events`.
Copiare il contenuto del seguente esempio di codice e salvare nella directory del progetto Lambda come `get-logs.sh`.
L'**cli-binary-format**opzione è obbligatoria se utilizzi la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example (solo) macOS e Linux**
Nello stesso prompt dei comandi, gli utenti macOS e Linux potrebbero dover eseguire il seguente comando per assicurarsi che lo script sia eseguibile.
```
chmod -R 755 get-logs.sh
```
**Example recuperare gli ultimi cinque eventi di log**
Nello stesso prompt dei comandi, eseguire lo script seguente per ottenere gli ultimi cinque eventi di log.
```
./get-logs.sh
```
Verrà visualizzato l’output seguente:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Analisi dei log e registrazione strutturata
Con CloudWatch Logs Insights, puoi cercare e analizzare i dati di registro utilizzando una [sintassi di query](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) specializzata. Esegue interrogazioni su più gruppi di log e fornisce potenti filtri utilizzando il pattern matching tra espressioni [glob](https://en.wikipedia.org/wiki/Glob_(programming)) e [regolari](https://en.wikipedia.org/wiki/Regular_expression).
Puoi sfruttare queste funzionalità implementando la registrazione strutturata nelle tue funzioni Lambda. La registrazione strutturata organizza i log in un formato predefinito, semplificando le interrogazioni. L'utilizzo dei livelli di registro è un primo passo importante per generare log compatibili con i filtri che separano i messaggi informativi dagli avvisi o dagli errori. Ad esempio, si consideri il seguente codice Node.js:
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
Il file di CloudWatch registro risultante contiene un campo separato che specifica il livello di registro:
![\[monitoraggio dell'osservabilità (figura 10)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-10.png)
Una query di CloudWatch Logs Insights può quindi filtrare a livello di registro. Ad esempio, per ricercare solo gli errori, è possibile utilizzare la seguente query:
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### Registrazione strutturata JSON
JSON è comunemente usato per fornire una struttura per i log delle applicazioni. Nell'esempio seguente, i log sono stati convertiti in JSON per generare tre valori distinti:
![\[monitoraggio dell'osservabilità (figura 11)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-11.png)
La funzionalità CloudWatch Logs Insights rileva automaticamente i valori nell'output JSON e analizza i messaggi come campi, senza la necessità di glob o espressioni regolari personalizzate. Utilizzando i log strutturati in JSON, la seguente query trova le invocazioni in cui il file caricato era più grande di 1 MB, il tempo di caricamento era superiore a 1 secondo e l'invocazione non era un avvio a freddo:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
Questa query potrebbe produrre il seguente risultato:
![\[monitoraggio dell'osservabilità (figura 12)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-12.png)
I campi rilevati in JSON vengono compilati automaticamente nel menu *Campi rilevati* sul lato destro. I campi standard emessi dal servizio Lambda hanno il prefisso '@' e puoi eseguire query su questi campi nello stesso modo. I log Lambda includono sempre i campi @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize. Se X-Ray è abilitato per una funzione, i log includono anche @ e @xrayTraceId . xraySegmentId
Quando un'origine di AWS eventi come Amazon S3, Amazon SQS o EventBridge Amazon richiama la tua funzione, l'intero evento viene fornito alla funzione come input di un oggetto JSON. Registrando questo evento nella prima riga della funzione, puoi quindi eseguire query su qualsiasi campo annidato utilizzando Logs Insights. CloudWatch
### Query utili di Insights
La tabella seguente mostra esempi di query Insights che possono essere utili per il monitoraggio delle funzioni Lambda.
| Description | Esempio di sintassi della query |
| --- | --- |
| Gli ultimi 100 errori |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| Le prime 100 invocazioni con il fatturato più alto |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| Percentuale di avvii a freddo sul totale delle invocazioni |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Rapporto percentile della durata Lambda |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Rapporto percentile sull'utilizzo della memoria Lambda |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| Invocazioni che utilizzano il 100% della memoria assegnata |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| Memoria media utilizzata tra le invocazioni |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| Visualizzazione delle statistiche sulla memoria |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Invocazioni in cui Lambda è uscita |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| Invocazioni scadute |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| Rapporto sulla latenza |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| Memoria sovradimensionata |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## Visualizzazione dei log e pannelli di controllo
Per qualsiasi query di CloudWatch Logs Insights, puoi esportare i risultati in formato markdown o CSV. In alcuni casi, potrebbe essere più utile creare [visualizzazioni a partire dalle query](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html), purché esista almeno una funzione di aggregazione. La `stats` funzione consente di definire aggregazioni e raggruppamenti.
L'esempio precedente di *logInsightsJSON* filtrava in base alla dimensione e al tempo di caricamento ed escludeva le prime invocazioni. Ciò ha prodotto una tabella di dati. Per monitorare un sistema di produzione, può essere più utile visualizzare le dimensioni minime, massime e medie dei file per individuare i valori anomali. Per fare ciò, applica la funzione stats agli aggregati richiesti e raggruppa in base a un valore temporale come ogni minuto:
Ad esempio, si consideri la seguente interrogazione. Questa è la stessa query di esempio della [Registrazione strutturata JSON](#querying-logs-json) sezione, ma con funzioni di aggregazione aggiuntive:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
Abbiamo incluso questi aggregati perché potrebbe essere più utile visualizzare le dimensioni minime, massime e medie dei file per individuare i valori anomali. **Puoi visualizzare i risultati nella scheda Visualizzazione:**
![\[monitoraggio dell'osservabilità (figura 14)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-14.png)
Dopo aver completato la creazione della visualizzazione, puoi facoltativamente aggiungere il grafico a una dashboard. CloudWatch Per fare ciò, scegli **Aggiungi al pannello di controllo** sopra la visualizzazione. Ciò aggiunge la query come widget e consente di selezionare intervalli di aggiornamento automatici, semplificando il monitoraggio continuo dei risultati:
![\[monitoraggio dell'osservabilità (figura 15)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-observability-figure-15.png)
# Invio dei log delle funzioni Lambda a Firehose
La console Lambda offre ora la possibilità di inviare registri delle funzioni a Firehose. Ciò consente lo streaming in tempo reale dei log verso varie destinazioni supportate da Firehose, inclusi strumenti di analisi di terze parti ed endpoint personalizzati.
**Nota**
È possibile configurare i log delle funzioni Lambda da inviare a Firehose utilizzando la console AWS CLI Lambda e tutti gli SDK. AWS CloudFormation AWS
## Prezzi
Per informazioni sui prezzi, consulta i [prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Autorizzazioni richieste per la destinazione del registro di Firehose
Quando si utilizza la console Lambda per configurare Firehose come destinazione di registro della funzione, è necessario:
1. Le [autorizzazioni IAM richieste](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) per utilizzare CloudWatch Logs with Lambda.
1. Per [configurare i filtri di abbonamento con Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). Questo filtro definisce quali eventi di log vengono distribuiti al tuo flusso Firehose.
## Invio dei log delle funzioni Lambda a Firehose
Nella console Lambda, è possibile inviare i log delle funzioni direttamente a Firehose dopo aver creato una nuova funzione. Per farlo, completa le seguenti fasi.
1. Accedi alla console di gestione e apri laconsole .
1. Scegli il nome della tua funzione.
1. Scegli la scheda **Configurazione**.
1. Scegliete la scheda **Strumenti operativi e di monitoraggio**.
1. Nel riquadro Configurazione della registrazione, scegli Modifica.
1. Nella sezione «Contenuto del registro», seleziona un formato di registro.
1. Nella sezione Step 1 (Fase 1) completare i passaggi seguenti.
1. Seleziona un servizio di destinazione.
1. Scegli un gruppo di log esistente o creane uno nuovo.
**Nota**
Se scegli un gruppo di log esistente per una destinazione Firehose, assicurati che il gruppo di log che scegli sia un tipo di gruppo di `Delivery` log.
1. Scegliete uno stream Firehose.
1. Verrà visualizzato il gruppo di log `Delivery` CloudWatch.
1. Selezionare **Salva**.
**Nota**
Se il ruolo IAM fornito nella console non dispone dell'autorizzazione richiesta, la configurazione della destinazione avrà esito negativo. Per risolvere questo problema, fare riferimento a Autorizzazioni richieste per la destinazione del registro di Firehose per fornire le autorizzazioni richieste.
## Registri multi-account
È possibile configurare Lambda per inviare i log al flusso di distribuzione di Firehose in un account diverso. AWS Ciò richiede l'impostazione di una destinazione e la configurazione delle autorizzazioni appropriate in entrambi gli account.
Per istruzioni dettagliate sulla configurazione della registrazione tra account, inclusi i ruoli e le policy IAM richiesti, consulta [Configurazione di un nuovo abbonamento tra account nella documentazione di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) Logs.
# Invio di log delle funzioni Lambda ad Amazon S3
Puoi configurare la tua funzione Lambda per inviare i log direttamente ad Amazon S3 utilizzando la console Lambda. Questa funzionalità offre una soluzione economica per l'archiviazione dei log a lungo termine e consente potenti opzioni di analisi utilizzando servizi come Athena.
**Nota**
Puoi configurare i log delle funzioni Lambda da inviare ad Amazon S3 utilizzando la console AWS CLI Lambda e tutti gli SDK. AWS CloudFormation AWS
## Prezzi
Per informazioni sui prezzi, consulta i [prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Autorizzazioni necessarie per la destinazione del log Amazon S3
Quando utilizzi la console Lambda per configurare Amazon S3 come destinazione dei log della tua funzione, devi:
1. Le [autorizzazioni IAM richieste](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) per utilizzare CloudWatch Logs with Lambda.
1. Da a [Configura un filtro di sottoscrizioni CloudWatch Logs per inviare i log delle funzioni Lambda ad Amazon S3](#using-cwl-subscription-filter-lambda-s3). Questo filtro definisce quali eventi di log vengono distribuiti al bucket Amazon S3.
## Configura un filtro di sottoscrizioni CloudWatch Logs per inviare i log delle funzioni Lambda ad Amazon S3
Per inviare i log da CloudWatch Logs ad Amazon S3, devi creare un filtro di sottoscrizione. Questo filtro definisce quali eventi di log vengono distribuiti al bucket Amazon S3. L'argomento deve trovarsi nella stessa Regione del bucket Amazon S3.
### Creazione di un filtro di sottoscrizione per Amazon S3
1. Crea un bucket Amazon Simple Storage Service (Amazon S3). Consigliamo di utilizzare un bucket creato appositamente per CloudWatch Logs. Tuttavia, se intendi utilizzare un bucket esistente, puoi passare alla fase 2.
Esegui il comando seguente, sostituendo il segnaposto Regione con la Regione che desideri utilizzare:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**Nota**
`amzn-s3-demo-bucket2`è un esempio del nome del bucket Amazon S3. *È riservato.* Affinché questa procedura funzioni, è necessario sostituirla con il nome univoco del bucket Amazon S3.
Di seguito è riportato un output di esempio:
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Crea il ruolo IAM che concede a File di log CloudWatch l'autorizzazione per inserire dati nel flusso. Questa policy include una chiave di contesto della condizione globale per prevenire il problema di sicurezza noto come "confused deputy". Per ulteriori informazioni sulla prevenzione del problema del "confused deputy", consulta .
1. In primo luogo, utilizza un editor di testo per creare una policy di attendibilità in un file `~/TrustPolicyForCWL.json`, come segue:
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Utilizza il comando create-role per creare un ruolo IAM, specificando il file della policy di attendibilità. Annota il valore Role.Arn restituito, poiché ne avrai bisogno anche in una fase successiva:
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. Crea una policy di autorizzazioni per definire che operazioni possono essere eseguite da CloudWatch Logs nel tuo account. In primo luogo, utilizza un editor di testo per creare una policy di autorizzazione in un file `~/PermissionsForCWL.json`:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
Associa la policy di autorizzazioni al ruolo inserendo il comando seguente:
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. Scegli un gruppo di log esistente o creane uno nuovo.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. Configurazione della destinazione
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Invio di log delle funzioni Lambda ad Amazon S3
Nella console Lambda, puoi inviare i log delle funzioni direttamente ad Amazon S3 dopo aver creato una nuova funzione. Per farlo, completa le seguenti fasi.
1. Accedi alla console di gestione e apri laconsole .
1. Scegli il nome della tua funzione.
1. Scegli la scheda **Configurazione**.
1. Scegli la scheda Strumenti **operativi e di monitoraggio**.
1. Nel riquadro Configurazione della registrazione, scegli Modifica.
1. Nella sezione «Contenuto del registro», seleziona un formato di registro.
1. Nella sezione Step 1 (Fase 1) completare i passaggi seguenti.
1. Seleziona un servizio di destinazione.
1. Scegli un gruppo di log esistente o creane uno nuovo.
**Nota**
Se scegli un gruppo di log esistente per una destinazione Amazon S3, assicurati che il gruppo di log che scegli sia un tipo di gruppo di `Delivery` log.
1. Scegli un bucket Amazon S3 come destinazione per i log delle funzioni.
1. Verrà visualizzato il gruppo di log `Delivery` CloudWatch.
1. Selezionare **Salva**.
**Nota**
Se il ruolo IAM fornito nella console non dispone delle autorizzazioni richieste, la configurazione della destinazione avrà esito negativo. Per risolvere questo problema, consulta [Autorizzazioni richieste per la destinazione dei log di Amazon S3](#logging-s3-permissions).
## Registrazione multi-account
È possibile configurare Lambda per inviare i log a un bucket Amazon S3 in un account. AWS Ciò richiede l'impostazione di una destinazione e la configurazione delle autorizzazioni appropriate in entrambi gli account.
Per istruzioni dettagliate sulla configurazione della registrazione tra account, inclusi i ruoli e le policy IAM richiesti, consulta [Configurazione di un nuovo abbonamento tra account nella documentazione di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) Logs.
# Registrazione delle chiamate AWS Lambda API utilizzando AWS CloudTrail
AWS Lambda è integrato con [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), un servizio che fornisce una registrazione delle azioni intraprese da un utente, ruolo o un Servizio AWS. CloudTrail acquisisce le chiamate API per Lambda come eventi. Le chiamate acquisite includono le chiamate dalla console di Lambda e le chiamate di codice alle operazioni delle API di Lambda. Utilizzando le informazioni raccolte da CloudTrail, è possibile determinare la richiesta effettuata a Lambda, l'indirizzo IP da cui è stata effettuata, quando è stata effettuata e ulteriori dettagli.
Ogni evento o voce di log contiene informazioni sull’utente che ha generato la richiesta. Le informazioni di identità consentono di determinare quanto segue:
+ Se la richiesta è stata effettuata con le credenziali utente root o utente.
+ Se la richiesta è stata effettuata per conto di un utente del Centro identità IAM.
+ Se la richiesta è stata effettuata con le credenziali di sicurezza temporanee per un ruolo o un utente federato.
+ Se la richiesta è stata effettuata da un altro Servizio AWS.
CloudTrail è attivo nel tuo account Account AWS quando crei l'account e hai automaticamente accesso alla **cronologia degli CloudTrail eventi**. La **cronologia CloudTrail degli eventi** fornisce un record visualizzabile, ricercabile, scaricabile e immutabile degli ultimi 90 giorni di eventi di gestione registrati in un. Regione AWS*Per ulteriori informazioni, consulta [Lavorare con la cronologia degli CloudTrail eventi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) nella Guida per l'utente.AWS CloudTrail * Non sono CloudTrail previsti costi per la visualizzazione della **cronologia degli eventi**.
Per una registrazione continua degli eventi degli Account AWS ultimi 90 giorni, crea un trail o un data store di eventi [CloudTrailLake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**CloudTrail sentieri**
Un *trail* consente di CloudTrail inviare file di log a un bucket Amazon S3. Tutti i percorsi creati utilizzando il Console di gestione AWS sono multiregionali. È possibile creare un trail per una singola Regione o per più Regioni tramite AWS CLI. La creazione di un percorso multiregionale è consigliata in quanto consente di registrare l'intera attività del proprio Regioni AWS account. Se si crea un trail per una singola Regione, è possibile visualizzare solo gli eventi registrati nella Regione AWS del trail. Per ulteriori informazioni sui trail, consulta [Creating a trail for your Account AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e [Creating a trail for an organization](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) nella *Guida per l'utente di AWS CloudTrail *.
Puoi inviare gratuitamente una copia dei tuoi eventi di gestione in corso al tuo bucket Amazon S3 CloudTrail creando un percorso, tuttavia ci sono costi di storage di Amazon S3. [Per ulteriori informazioni sui CloudTrail prezzi, consulta la pagina Prezzi.AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/) Per informazioni sui prezzi di Amazon S3, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/).
**CloudTrail Archivi di dati sugli eventi di Lake**
*CloudTrail Lake* ti consente di eseguire query basate su SQL sui tuoi eventi. CloudTrail [Lake converte gli eventi esistenti in formato JSON basato su righe in formato Apache ORC.](https://orc.apache.org/) ORC è un formato di archiviazione a colonne ottimizzato per il recupero rapido dei dati. Gli eventi vengono aggregati in *archivi di dati degli eventi*, che sono raccolte di eventi immutabili basate sui criteri selezionati applicando i [selettori di eventi avanzati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). I selettori applicati a un archivio di dati degli eventi controllano quali eventi persistono e sono disponibili per l'esecuzione della query. *Per ulteriori informazioni su CloudTrail Lake, consulta [Working with AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) nella Guida per l'utente.AWS CloudTrail *
CloudTrail Gli archivi e le richieste di dati sugli eventi di Lake comportano dei costi. Quando crei un datastore di eventi, scegli l'[opzione di prezzo](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) da utilizzare per tale datastore. L'opzione di prezzo determina il costo per l'importazione e l'archiviazione degli eventi, nonché il periodo di conservazione predefinito e quello massimo per il datastore di eventi. [Per ulteriori informazioni sui CloudTrail prezzi, consulta la sezione Prezzi.AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/)
## Eventi relativi ai dati Lambda in CloudTrail
Gli [eventi di dati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) forniscono informazioni sulle operazioni delle risorse eseguite su o in una risorsa (ad esempio, lettura o scrittura su un oggetto Amazon S3). Queste operazioni sono definite anche operazioni del piano dei dati. Gli eventi di dati sono spesso attività che interessano volumi elevati di dati. Per impostazione predefinita, CloudTrail non registra la maggior parte degli eventi relativi ai dati e la **cronologia degli CloudTrail eventi** non li registra.
Un evento CloudTrail relativo ai dati che viene registrato per impostazione predefinita per i servizi supportati è`LambdaESMDisabled`. Per ulteriori informazioni sull'utilizzo di questo evento per risolvere i problemi relativi agli strumenti di mappatura dell'origine degli eventi Lambda, consulta [Utilizzo CloudTrail per la risoluzione dei problemi relativi alle sorgenti di eventi Lambda disabilitate](#cloudtrail-ESM-troubleshooting).
Per gli eventi di dati sono previsti costi aggiuntivi. Per ulteriori informazioni sui CloudTrail prezzi, consulta la sezione [AWS CloudTrail Prezzi](https://aws.amazon.com/cloudtrail/pricing/).
Puoi registrare gli eventi relativi ai dati per il tipo di `AWS::Lambda::Function` risorsa utilizzando la CloudTrail console o AWS CLI le operazioni CloudTrail dell'API. Per ulteriori informazioni su come registrare gli eventi di dati, consulta [Registrazione degli eventi di dati con Console di gestione AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) e [Registrazione degli eventi di dati con AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) nella *Guida per l'utente di AWS CloudTrail *.
La tabella seguente elenca il tipo di risorse Lambda per i quali è possibile registrare gli eventi relativi ai dati. La colonna **Tipo di evento Data (console)** mostra il valore da scegliere dall'elenco dei **tipi di evento Data** sulla CloudTrail console. La colonna del **valore resources.type** mostra il `resources.type` valore da specificare durante la configurazione dei selettori di eventi avanzati utilizzando o. AWS CLI CloudTrail APIs La CloudTrail colonna **Dati APIs registrati mostra le chiamate API registrate per** il tipo di risorsa. CloudTrail
| Tipo di evento di dati (console) | valore resources.type | Dati registrati APIs su CloudTrail |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
È possibile configurare selettori di eventi avanzati per filtrare in base ai campi `eventName`, `readOnly`, e `resources.ARN` per registrare solo gli eventi che sono importanti per l'utente. L'esempio seguente è la vista JSON di una configurazione di eventi di dati che registra gli eventi solo per una funzione specifica. Per ulteriori informazioni su questi campi, consulta [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) nella *Documentazione di riferimento delle API di AWS CloudTrail *.
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## Eventi di gestione Lambda in CloudTrail
[Gli eventi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) di gestione forniscono informazioni sulle operazioni di gestione eseguite sulle risorse del tuo Account AWS. Queste operazioni sono definite anche operazioni del piano di controllo (control-plane). Per impostazione predefinita, CloudTrail registra gli eventi di gestione.
Lambda supporta la registrazione delle seguenti azioni come eventi di gestione nei CloudTrail file di registro.
**Nota**
Nel file di CloudTrail registro, `eventName` potrebbero includere informazioni sulla data e sulla versione, ma si riferisce comunque alla stessa azione pubblica dell'API. Ad esempio, l'operazione `GetFunction` potrebbe apparire come `GetFunction20150331v2`. L'elenco seguente specifica quando il nome dell'evento è diverso dal nome dell'operazione API.
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)(nome dell'evento:`AddPermission20150331v2`)
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)(nome dell'evento:`CreateAlias20150331`)
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)(nome dell'evento:`CreateEventSourceMapping20150331`)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)(nome dell'evento:`CreateFunction20150331`)
(I parametri `Environment` e `ZipFile` sono omessi dai log CloudTrail per `CreateFunction`.)
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)(nome dell'evento:`DeleteAlias20150331`)
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)(nome dell'evento:`DeleteEventSourceMapping20150331`)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)(nome dell'evento:`DeleteFunction20150331`)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)(nome dell'evento:`DeleteFunctionConcurrency20171031`)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)(nome dell'evento:`GetAlias20150331`)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html)(nome dell'evento:`PublishLayerVersion20181031`)
(Il `ZipFile` parametro viene omesso dai CloudTrail registri per`PublishLayerVersion`.)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)(nome dell'evento:) `PublishVersion20150331`
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)(nome dell'evento:`PutFunctionConcurrency20171031`)
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html)(nome dell'evento:`RemovePermission20150331v2`)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)(nome dell'evento:`TagResource20170331v2`)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)(nome dell'evento:`UntagResource20170331v2`)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)(nome dell'evento:`UpdateAlias20150331`)
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)(nome dell'evento:`UpdateEventSourceMapping20150331`)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)(nome dell'evento:`UpdateFunctionCode20150331v2`)
(Il `ZipFile` parametro viene omesso dai CloudTrail registri per`UpdateFunctionCode`.)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)(nome dell'evento:) `UpdateFunctionConfiguration20150331v2`
(Il `Environment` parametro viene omesso dai CloudTrail registri per`UpdateFunctionConfiguration`.)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## Utilizzo CloudTrail per la risoluzione dei problemi relativi alle sorgenti di eventi Lambda disabilitate
Quando si modifica lo stato di una mappatura delle sorgenti di eventi utilizzando l'azione [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API, la chiamata API viene registrata come evento di gestione. CloudTrail Gli strumenti di mappatura dell'origine degli eventi possono anche passare direttamente allo stato `Disabled` a causa di errori.
Per i seguenti servizi, Lambda pubblica l'evento `LambdaESMDisabled` dei dati CloudTrail quando l'origine dell'evento passa allo stato Disabilitato:
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
Lambda non supporta questo evento per alcun altro tipo di strumento di mappatura dell'origine degli eventi.
Per ricevere avvisi quando le mappature delle sorgenti degli eventi per i servizi supportati passano allo `Disabled` stato, configura un allarme in Amazon CloudWatch utilizzando l'evento. `LambdaESMDisabled` CloudTrail Per ulteriori informazioni sulla configurazione di un CloudWatch allarme, consulta [Creazione di CloudWatch allarmi per CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) eventi: esempi.
L'entità `serviceEventDetails` nel messaggio dell'evento `LambdaESMDisabled` contiene uno dei seguenti codici di errore.
**`RESOURCE_NOT_FOUND`**
La risorsa specificata nella richiesta non esiste.
**`FUNCTION_NOT_FOUND`**
La funzione associata all'origine eventi non esiste.
**`REGION_NAME_NOT_VALID`**
Il nome di una regione fornito all'origine o alla funzione evento non è valido.
**`AUTHORIZATION_ERROR`**
Le autorizzazioni non sono state impostate o non sono configurate correttamente.
**`FUNCTION_IN_FAILED_STATE`**
Il codice della funzione non viene compilato, ha rilevato un'eccezione irrecuperabile o si è verificata una distribuzione non valida.
## Esempi di eventi Lambda
Un evento rappresenta una singola richiesta proveniente da qualsiasi fonte e include informazioni sull'operazione API richiesta, la data e l'ora dell'operazione, i parametri della richiesta e così via. CloudTrail i file di registro non sono una traccia ordinata dello stack delle chiamate API pubbliche, quindi gli eventi non vengono visualizzati in un ordine specifico.
L'esempio seguente mostra le voci di CloudTrail registro per le `DeleteFunction` azioni `GetFunction` e.
**Nota**
La voce `eventName` potrebbe includere informazioni sulla data e sulla versione, ad esempio `"GetFunction20150331"`, ma si riferisce comunque alla stessa API pubblica.
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
Per informazioni sul contenuto dei CloudTrail record, consultate il [contenuto dei CloudTrail record](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) nella *Guida AWS CloudTrail per l'utente*.
# Visualizza le chiamate alla funzione Lambda utilizzando AWS X-Ray
Puoi utilizzarli AWS X-Ray per visualizzare i componenti dell'applicazione, identificare i punti deboli in termini di prestazioni e risolvere le richieste che hanno provocato un errore. Le funzioni Lambda inviano dati di traccia a X-Ray e X-Ray elabora i dati per generare una mappa di servizio e riepiloghi di traccia ricercabili.
Lambda supporta due modalità di tracciamento per X-Ray: e. `Active` `PassThrough` Con il `Active` tracciamento, Lambda crea automaticamente segmenti di traccia per le chiamate di funzioni e li invia a X-Ray. `PassThrough`mode, d'altra parte, propaga semplicemente il contesto di tracciamento ai servizi a valle. Se hai abilitato il `Active` tracciamento per la tua funzione, Lambda invia automaticamente le tracce a X-Ray per le richieste campionate. In genere, un servizio upstream, come Amazon API Gateway o un'applicazione ospitata su Amazon EC2 dotata di strumentazione con l'SDK X-Ray, decide se tracciare le richieste in entrata, quindi aggiunge tale decisione di campionamento come intestazione di tracciamento. Lambda utilizza quell'intestazione per decidere se inviare tracce o meno. Le tracce dei produttori di messaggi upstream, come Amazon SQS, vengono automaticamente collegate alle tracce delle funzioni Lambda downstream, creando end-to-end una visualizzazione dell'intera applicazione. Per ulteriori informazioni, consulta [Tracciamento delle applicazioni guidate dagli eventi](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html) nella *Guida per gli sviluppatori di AWS X-Ray *.
**Nota**
Il tracciamento X-Ray non è attualmente supportato per le funzioni Lambda con Streaming gestito da Amazon per Apache Kafka (Amazon MSK), Apache Kafka gestito dal cliente, Amazon MQ con ActiveMQ e RabbitMQ attivi oppure mappature delle origini degli eventi Amazon DocumentDB.
Per attivare il tracciamento attivo sulla funzione Lambda con la console, attenersi alla seguente procedura:
**Per attivare il tracciamento attivo**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. Scegliere **Configuration** (Configurazione) e quindi **Monitoring and operations tools** (Strumenti di monitoraggio e operazioni).
1. In **Strumenti di monitoraggio aggiuntivi** scegli **Modifica**.
1. In **CloudWatch Application Signals e AWS X-Ray**, scegli **Enable** for **Lambda service trace**.
1. Scegli **Save** (Salva).
La funzione ha bisogno dell'autorizzazione per caricare i dati di traccia su X-Ray. Quando si attiva il tracciamento nella console Lambda, Lambda aggiunge le autorizzazioni necessarie al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione. Altrimenti, aggiungi la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)policy al ruolo di esecuzione.
X-Ray non traccia tutte le richieste nell'applicazione. X-Ray applica un algoritmo di campionamento per garantire che il tracciamento avvenga in modo efficiente, continuando allo stesso tempo a fornire un campione rappresentativo di tutte le richieste. La frequenza di campionamento è di una richiesta al secondo e del 5% delle altre richieste. Non è possibile configurare la frequenza di campionamento di X-Ray per le funzioni.
## Informazioni sui monitoraggi di X-Ray
In X-Ray, una *traccia* registra informazioni su una richiesta elaborata da uno o più *servizi*. Lambda registra 2 segmenti per traccia, che creano due nodi sul grafico del servizio. L'immagine seguente evidenzia questi due nodi:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/xray-servicemap-function.png)
Il primo nodo a sinistra rappresenta il servizio Lambda che riceve la richiesta di chiamata. Il secondo nodo rappresenta la specifica funzione Lambda.
Il segmento registrato per il servizio Lambda, `AWS::Lambda`, copre tutti i passaggi necessari per preparare l'ambiente di esecuzione Lambda. Ciò include la pianificazione di MicroVM, la creazione o lo sblocco di un ambiente di esecuzione con le risorse configurate, nonché il download del codice per la funzione e di tutti i livelli.
Il segmento `AWS::Lambda::Function` è destinato al lavoro svolto dalla funzione.
**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.
Questa modifica influisce sui sottosegmenti del segmento della funzione. I paragrafi seguenti descrivono sia il vecchio che il nuovo formato per questi sottosegmenti.
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.
**Struttura a segmenti Lambda vecchio stile AWS X-Ray**
La struttura X-Ray vecchio stile per il segmento `AWS::Lambda` è simile alla seguente:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
In questo formato, il segmento della funzione ha sottosegmenti per `Initialization`, `Invocation` e `Overhead`. Solo per [Lambda SnapStart](snapstart.md), c'è anche un sottosegmento `Restore` (non mostrato in questo diagramma).
Il sottosegmento `Initialization` rappresenta la fase iniziale del ciclo di vita dell'ambiente di esecuzione Lambda. In questa fase, Lambda inizializza le estensioni, inizializza il runtime ed esegue il codice di inizializzazione della funzione.
Il sottosegmento `Invocation` rappresenta la fase di invocazione in cui Lambda richiama il gestore di funzioni. Questo inizia con la registrazione del runtime e dell'estensione e termina quando il runtime è pronto per inviare la risposta.
[( SnapStart Solo Lambda) Il `Restore` sottosegmento mostra il tempo impiegato da Lambda per ripristinare un'istantanea, caricare il runtime ed eseguire eventuali hook di runtime successivi al ripristino.](snapstart-runtime-hooks.md) Il processo di ripristino degli snapshot può includere il tempo dedicato ad attività esterne alla MicroVM. Questa volta è riportato nel segmento secondario `Restore`. Non ti viene addebitato il tempo trascorso fuori dalla microVM per il ripristino di una snapshot.
Il sottosegmento `Overhead` rappresenta la fase che si verifica tra il momento in cui il runtime invia la risposta e il segnale per la successiva invocazione. Durante questo periodo, il runtime termina tutte le attività correlate a un'invocazione e si prepara a congelare la sandbox.
**Importante**
È possibile utilizzare l'SDK X-Ray per estendere il sottosegmento `Invocation` con sottosegmenti aggiuntivi per chiamate a valle, annotazioni e metadati. Non è possibile accedere direttamente al segmento di funzione o registrare la parola eseguita al di fuori dell'ambito di chiamata del gestore.
Per ulteriori informazioni sulle fasi dell'ambiente di esecuzione Lambda, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
Nel diagramma seguente è illustrato un esempio di traccia che utilizza la struttura di X-Ray vecchio stile.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Nota i due segmenti dell'esempio. Entrambi sono nominati **my-function**, ma uno ha l'origine `AWS::Lambda` e l'altro ha l'origine `AWS::Lambda::Function`. Se il segmento `AWS::Lambda` mostra un errore, il servizio Lambda ha avuto un problema. Se il `AWS::Lambda::Function` segmento mostra un errore, la funzione ha avuto un problema.
**Nota**
Occasionalmente, potresti notare un ampio divario tra le fasi di inizializzazione e invocazione della funzione nelle tracce X-Ray. Per le funzioni che utilizzano la [simultaneità fornita](provisioned-concurrency.md), ciò è dovuto al fatto che Lambda inizializza le istanze della funzione con largo anticipo rispetto all'invocazione. Per le funzioni che utilizzano la [concorrenza non riservata (su richiesta)](lambda-concurrency.md), Lambda può inizializzare in modo proattivo un'istanza di funzione, anche in assenza di chiamata. Visivamente, entrambi questi casi si presentano come un intervallo di tempo tra le fasi di inizializzazione e invocazione.
**Struttura dei segmenti Lambda di nuova AWS X-Ray concezione**
La struttura X-Ray nuovo stile per il segmento `AWS::Lambda` è simile alla seguente:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
In questo nuovo formato, il sottosegmento `Init` rappresenta la fase iniziale del ciclo di vita dell'ambiente di esecuzione Lambda.
Nel nuovo formato non è presente alcun segmento di invocazione. I sottosegmenti dei clienti sono invece collegati direttamente al segmento `AWS::Lambda::Function`. Questo segmento contiene i seguenti parametri come annotazioni:
+ `aws.responseLatency`: il tempo impiegato per l'esecuzione della funzione
+ `aws.responseDuration`: il tempo impiegato per trasferire la risposta al cliente
+ `aws.runtimeOverhead`: la quantità di tempo supplementare necessaria al completamento del runtime
+ `aws.extensionOverhead`: la quantità di tempo supplementare necessaria al completamento delle estensioni
Nel diagramma seguente è illustrato un esempio di traccia che utilizza la struttura di X-Ray nuovo stile.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
Nota i due segmenti dell'esempio. Entrambi sono nominati **my-function**, ma uno ha l'origine `AWS::Lambda` e l'altro ha l'origine `AWS::Lambda::Function`. Se il segmento `AWS::Lambda` mostra un errore, il servizio Lambda ha avuto un problema. Se il `AWS::Lambda::Function` segmento mostra un errore, la funzione ha avuto un problema.
Vedere i seguenti argomenti per un'introduzione specifica della lingua all'analisi in Lambda:
+ [Strumentazione del codice Node.js in AWS Lambda](nodejs-tracing.md)
+ [Strumentazione del codice Python in AWS Lambda](python-tracing.md)
+ [Strumentazione del codice Ruby in AWS Lambda](ruby-tracing.md)
+ [Strumentazione del codice Java in AWS Lambda](java-tracing.md)
+ [Strumentazione del codice Go in AWS Lambda](golang-tracing.md)
+ [Strumentazione del codice C\$1 in AWS Lambda](csharp-tracing.md)
Per un elenco completo dei servizi che supportano la strumentazione attiva, consulta [Servizi Servizi AWS](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges) supportati nella Guida per gli sviluppatori di AWS X-Ray .
## Comportamento di tracciamento predefinito in Lambda
Se la funzione di `Active` tracciamento non è attivata, Lambda utilizza come impostazione predefinita `PassThrough` la modalità di tracciamento.
In `PassThrough` modalità, Lambda inoltra l'intestazione di tracciamento X-Ray ai servizi a valle, ma non invia le tracce automaticamente. Questo è vero anche se l'intestazione di tracciamento contiene la decisione di campionare la richiesta. Se il servizio upstream non fornisce un'intestazione di tracciamento a raggi X, Lambda genera un'intestazione e decide di non campionare. Tuttavia, puoi inviare le tue tracce richiamando le librerie di tracciamento dal codice della funzione.
**Nota**
In precedenza, Lambda inviava le tracce automaticamente quando i servizi upstream, come Amazon API Gateway, aggiungevano un'intestazione di tracciamento. Non inviando tracce automaticamente, Lambda ti offre il controllo necessario per tracciare le funzioni che ritieni importanti. Se la tua soluzione dipende da questo comportamento di tracciamento passivo, passa al `Active` tracciamento.
## Autorizzazioni del ruolo di esecuzione
Lambda richiede le seguenti autorizzazioni per inviare i dati di traccia a X-Ray. Aggiungerle al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione.
+ [Radiografia: PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [radiografia: PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
Queste autorizzazioni sono incluse nella politica [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)gestita.
## Abilitazione del tracciamento `Active` con l'API Lambda
Per gestire la configurazione di tracciamento con AWS CLI o AWS SDK, utilizza le seguenti operazioni API:
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
**Il AWS CLI comando di esempio seguente abilita il tracciamento attivo su una funzione denominata my-function.**
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
La modalità di tracciamento fa parte della configurazione specifica della versione quando si pubblica una versione della funzione. Non è possibile modificare la modalità di tracciamento in una versione pubblicata.
## Abilitazione del tracciamento con `Active` CloudFormation
Per attivare il tracciamento su una `AWS::Lambda::Function` risorsa in un CloudFormation modello, utilizzate la `TracingConfig` proprietà.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configurazione del tracciamento**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Per una `AWS::Serverless::Function` risorsa AWS Serverless Application Model (AWS SAM), utilizzate la `Tracing` proprietà.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configurazione del tracciamento**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Monitorare le prestazioni delle funzioni con Lambda Insights di Amazon CloudWatch
Amazon CloudWatch Lambda Insights raccoglie e aggrega parametri e registri delle prestazioni del runtime delle funzioni Lambda per le applicazioni serverless. In questa pagina viene descritto come abilitare e utilizzare Lambda Insights per eseguire la diagnosi dei problemi relativi alle funzioni Lambda.
**Topics**
+ [Come Lambda Insights monitora le applicazioni serverless](#monitoring-insights-how)
+ [Prezzi](#monitoring-insights-pricing)
+ [Runtime supportati](#monitoring-insights-runtimes)
+ [Attivazione di Lambda Insights nella console Lambda](#monitoring-insights-enabling-console)
+ [Attivazione di Lambda Insights a livello di programmazione](#monitoring-insights-enabling-programmatically)
+ [Uso del pannello di controllo di Lambda Insights](#monitoring-insights-multifunction)
+ [Esempio di flusso di lavoro per rilevare anomalie delle funzioni](#monitoring-insights-anomalies)
+ [Esempio di flusso di lavoro utilizzando query per risolvere i problemi di una funzione](#monitoring-insights-queries)
+ [Fasi successive](#monitoring-console-next-up)
## Come Lambda Insights monitora le applicazioni serverless
CloudWatch Lambda Insights è una soluzione di monitoraggio e risoluzione dei problemi per applicazioni serverless in esecuzione su AWS Lambda. La soluzione raccoglie, aggrega e riassume le metriche a livello di sistema, tra cui il tempo della CPU, la memoria, l'utilizzo del disco e della rete. Vengono inoltre raccolte, aggregate e riepilogate informazioni diagnostiche quali avvii a freddo e arresti del worker Lambda per aiutare a isolare i problemi con le funzioni Lambda e risolverli rapidamente.
Lambda Insights utilizza una nuova [estensione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) CloudWatch Lambda Insights che viene fornita come [livello Lambda](chapter-layers.md). Quando si abilita questa estensione su una funzione Lambda per un runtime supportato, essa raccoglie parametri a livello di sistema ed emette un singolo evento di log delle prestazioni per ogni chiamata di tale funzione Lambda. CloudWatch utilizza la formattazione dei parametri incorporata per estrarre i parametri dagli eventi di log. Per ulteriori informazioni, consulta l'argomento relativo all'[Uso delle estensioni AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html).
Il livello Lambda Insights estende `CreateLogStream` e `PutLogEvents` per il gruppo di log `/aws/lambda-insights/`.
## Prezzi
Quando so abilita Lambda Insights per la funzione Lambda, Lambda Insights riporta 8 parametri per funzione e ogni chiamata di funzione invia circa 1 KB di dati di log a CloudWatch. Paghi solo in base ai parametri e ai registri riportati per la tua funzione da Lambda Insights. Non sono previste tariffe minime né policy di utilizzo del servizio obbligatorie. Non si paga per Lambda Insights se la funzione non viene richiamata. Per informazioni sui prezzi, consulta la pagina [Prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Runtime supportati
È possibile utilizzare Lambda Insights con qualsiasi runtime che supporta le [estensioni Lambda](runtimes-extensions-api.md).
## Attivazione di Lambda Insights nella console Lambda
È possibile abilitare il monitoraggio Lambda Insights avanzato su funzioni Lambda nuove ed esistenti. Quando si abilita Lambda Insights su una funzione nella console Lambda per un runtime supportato, Lambda aggiunge l'[estensione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) Lambda Insights come livello alla funzione e verifica o prova ad allegare la policy [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) al [ruolo di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) della funzione.
**Per attivare Lambda Insights nella console Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione.
1. Scegli la scheda **Configurazione**.
1. Dal menu a sinistra, scegli **Strumenti di monitoraggio e operazioni**.
1. Nel riquadro **Strumenti di monitoraggio aggiuntivi** scegli **Modifica**.
1. In **CloudWatch Lambda Insights**, attiva **Monitoraggio avanzato**.
1. Selezionare **Salva**.
## Attivazione di Lambda Insights a livello di programmazione
È inoltre possibile abilitare Lambda Insights utilizzando la AWS Command Line Interface (AWS CLI), la CLI (SAM) AWS Serverless Application Model, CloudFormation o il AWS Cloud Development Kit (AWS CDK). Quando si abilita Lambda Insights a livello di programmazione su una funzione per un runtime supportato, CloudWatch collega la policy [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) al [ruolo di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) della funzione.
Per ulteriori informazioni, consulta le [Nozioni di base su Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html) nella *Guida per l'utente di Amazon CloudWatch*.
## Uso del pannello di controllo di Lambda Insights
Il pannello di controllo Lambda Insights ha due visualizzazioni nella console CloudWatch: la panoramica multifunzione e la vista a funzione singola. La panoramica multi-funzione aggrega i parametri di runtime per le funzioni Lambda nell'account AWS attuale e nella regione. La vista a funzione singola mostra i parametri di runtime disponibili per una singola funzione Lambda.
È possibile utilizzare la panoramica multifunzione del pannello di controllo Lambda Insights nella console CloudWatch per identificare le funzioni Lambda sovrautilizzate e sottoutilizzate. È possibile utilizzare la visualizzazione a funzione singola del pannello di controllo Lambda Insights nella console CloudWatch per risolvere i problemi delle singole richieste.
**Per visualizzare i parametri di runtime per tutte le funzioni**
1. Aprire la pagina [Multifunzione](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) nella console CloudWatch.
1. Scegli tra gli intervalli di tempo predefiniti oppure scegli un intervallo di tempo personalizzato.
1. (Facoltativo) Scegliere **Add to dashboard (Aggiungi a pannello di controllo)** per aggiungere i widget al dashboard CloudWatch.
![\[La panoramica multifunzione sul pannello di controllo Lambda Insights.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**Per visualizzare le metriche di runtime di una singola funzione**
1. Aprire la pagina [Funzione singola](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions) nella console CloudWatch.
1. Scegli tra gli intervalli di tempo predefiniti oppure scegli un intervallo di tempo personalizzato.
1. (Facoltativo) Scegliere **Add to dashboard (Aggiungi a pannello di controllo)** per aggiungere i widget al dashboard CloudWatch.
![\[La vista a funzione singola sul pannello di controllo Lambda Insights.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
Per ulteriori informazioni, vedere [Creazione e utilizzo dei widget nei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html).
## Esempio di flusso di lavoro per rilevare anomalie delle funzioni
È possibile utilizzare la panoramica multifunzione sul pannello di controllo Lambda Insights per identificare e rilevare anomalie della memoria di calcolo con la funzione. Ad esempio, se la panoramica multifunzione indica che una funzione utilizza una grande quantità di memoria, è possibile visualizzare metriche dettagliate sull'utilizzo della memoria nel riquadro **Uso memoria**. Puoi quindi accedere al pannello di controllo Parametri per abilitare il rilevamento delle anomalie o creare un allarme.
**Per abilitare il rilevamento delle anomalie per una funzione**
1. Aprire la pagina [Multifunzione](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) nella console CloudWatch.
1. In **Riepilogo funzione**, scegliere il nome della funzione.
La vista a funzione singola si apre con le metriche di runtime della funzione.
![\[Il riquadro di riepilogo delle funzioni nel pannello di controllo Lambda Insights.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. Nel riquadro **Uso memoria** scegliere i tre punti verticali, quindi scegliere **Visualizza in metriche** per aprire il pannello di controllo **Parametri** .
![\[Il menu del riquadro Memory Usage (Utilizzo memoria).\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. Nella scheda **Graphed metrics** (Parametri grafici), nella colonna **Actions** (Operazioni), scegli la prima icona per abilitare il rilevamento delle anomalie per la funzione.
![\[Scheda Graphed metrics (Parametri nel grafico) del riquadro Memory Usage (Uso memoria).\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
Per ulteriori informazioni, consulta [Utilizzo del rilevamento delle anomalie di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
## Esempio di flusso di lavoro utilizzando query per risolvere i problemi di una funzione
È possibile utilizzare la visualizzazione a funzione singola nel pannello di controllo Lambda Insights per identificare la causa principale di un picco nella durata della funzione. Ad esempio, se la panoramica multifunzione indica un notevole aumento della durata della funzione, è possibile sospendere o scegliere ciascuna funzione nel riquadro **Durata** per determinare quale funzione sta causando l'aumento. È quindi possibile accedere alla visualizzazione a funzione singola ed esaminare i **registri applicazioni** per determinare la causa principale.
**Per eseguire query su una funzione**
1. Aprire la pagina [Multifunzione](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) nella console CloudWatch.
1. Nel riquadro **Durata** scegliere la funzione per filtrare le metriche della durata.
![\[Funzione scelta nel riquadro Durata.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. Aprire la pagina [Funzione singola](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions).
1. Scegli l'elenco a discesa **Filtra metriche per nome funzione**, quindi scegli la funzione.
1. Per visualizzare i **1000 registri applicazioni più recenti**, scegliere la scheda **Registri applicazioni**.
1. Esaminare il **timestamp** e il **messaggio** per identificare la richiesta di chiamata per cui si desidera risolvere i problemi.
![\[I 1000 registri applicazioni più recenti.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. Per visualizzare le **1000 invocazioni più recenti**, scegliere la scheda **Invocazioni** .
1. Selezionare il **timestamp** o il **messaggio** per la richiesta di invocazione per cui si desidera risolvere i problemi.
![\[Selezione di una richiesta di chiamata recente.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. Scegliere l'elenco a discesa **Visualizza registri** quindi scegliere **Visualizza registri prestazioni**.
Viene visualizzata una query generata automaticamente per la funzione nel pannello di controllo **Logs Insights (Analisi registri)** .
1. Scegliere **Esegui query** per generare un messaggio **Log** per la richiesta di chiamata.
![\[Esecuzione di query sulla funzione selezionata nel pannello di controllo Logs Insights (Analisi registri).\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/lambdainsights-query.png)
## Fasi successive
+ Informazioni su come creare un pannello di controllo di CloudWatch Logs in [Creazione di un pannello di controllo](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) nella *Guida per l'utente di Amazon CloudWatch*.
+ Scopri come aggiungere query a un pannello di controllo di CloudWatch Logs in [Aggiunta di query a pannello di controllo o esportazione dei risultati della query](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) nella *Guida per l'utente di Amazon CloudWatch*.
# Monitoraggio delle applicazioni Lambda
La sezione **Applicazioni** della console Lambda include una scheda **Monitoraggio** in cui è possibile esaminare un pannello di controllo di Amazon CloudWatch con parametri aggregati per le risorse dell'applicazione.
**Per monitorare un'applicazione Lambda**
1. Aprire la [pagina Applicazioni](https://console.aws.amazon.com/lambda/home#/applications) della console Lambda.
1. Selezionare **Monitoring (Monitoraggio)**.
1. Per maggiori dettagli sui parametri in qualsiasi grafico, scegli **Visualizza nei parametri** dal menu a discesa.
![\[Un widget di monitoraggio.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/applications-monitoring-widget.png)
Il grafico viene visualizzato in una nuova scheda, con i parametri pertinenti elencati sotto il grafico. Puoi personalizzare la visualizzazione di questo grafico, modificando i parametri e le risorse mostrate, le statistiche, il periodo e altri fattori per comprendere meglio la situazione attuale.
Per impostazione predefinita, la console Lambda mostra un pannello di controllo di base. Puoi personalizzare questa pagina aggiungendo uno o più pannelli di controllo Amazon CloudWatch al modello dell'applicazione con il tipo di risorsa [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html). Quando il modello include uno o più pannelli di controllo, la pagina mostra i pannelli di controllo anziché il pannello di controllo predefinito. Puoi passare da un pannello di controllo all'altro con il menu a discesa in alto a destra della pagina. Nell'esempio seguente viene creato un pannello di controllo con un singolo widget che rappresenta graficamente il numero di chiamate di una funzione denominata `my-function`.
**Example Modello di pannello di controllo delle funzioni**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
Per ulteriori informazioni sulla creazione di pannelli di controllo e widget di CloudWatch, consulta [Struttura e sintassi del corpo del pannello di controllo](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) nella *Documentazione di riferimento delle API di Amazon CloudWatch*.
# Monitoraggio delle prestazioni delle applicazioni con Amazon CloudWatch Application Signals
Amazon CloudWatch Application Signals è una soluzione di monitoraggio delle prestazioni delle applicazioni (APM) che consente a sviluppatori e operatori di monitorare lo stato e le prestazioni delle loro applicazioni serverless create con Lambda. Puoi abilitare Application Signals con un clic dalla console Lambda e non è necessario aggiungere alcun codice di strumentazione o dipendenze esterne alla funzione Lambda. Dopo aver abilitato Application Signals, è possibile visualizzare tutti i parametri e le tracce raccolte nella console CloudWatch. In questa pagina viene descritto come abilitare e visualizzare i dati di telemetria di Application Signals per le applicazioni.
**Topics**
+ [In che modo Application Signals si integra con Lambda](#monitoring-application-signals-how)
+ [Prezzi](#monitoring-application-signals-pricing)
+ [Runtime supportati](#monitoring-application-signals-runtimes)
+ [Abilitazione di Application Signals nella console Lambda](#monitoring-application-signals-console)
+ [Utilizzo del pannello di controllo di Application Signals](#monitoring-application-signals-dashboard)
## In che modo Application Signals si integra con Lambda
Application Signals strumenta automaticamente le funzioni Lambda utilizzando le librerie [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/) avanzate, fornite tramite un [livello Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) Application Signals legge i dati raccolti dal livello e genera pannelli di controllo con parametri delle prestazioni chiave per le applicazioni.
Puoi collegare questo livello con un clic [abilitando Application Signals](#monitoring-application-signals-console) nella console Lambda. Quando attivi Application Signals dalla console, Lambda esegue le seguenti operazioni per conto tuo:
+ Aggiorna il ruolo di esecuzione della funzione per includere `CloudWatchLambdaApplicationSignalsExecutionRolePolicy`. [ Questa policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html) fornisce l'accesso in scrittura a AWS X-Ray e ai gruppi di log CloudWatch utilizzati per Application Signals.
+ Aggiunge un livello alla funzione che la strumenta automaticamente per acquisire dati di telemetria come richieste, disponibilità, latenza, errori e guasti. Per garantire che Application Signals funzioni correttamente, rimuovi qualsiasi codice di strumentazione dell'SDK X-Ray esistente dalla tua funzione. Il codice di strumentazione dell'SDK X-Ray personalizzato può interferire con la strumentazione fornita dal livello.
+ Aggiunge la variabile di ambiente `AWS_LAMBDA_EXEC_WRAPPER` alla funzione e ne imposta il valore su `/opt/otel-instrument`. Questa variabile di ambiente modifica il comportamento di avvio della funzione per utilizzare il livello di Application Signals ed è necessaria per una corretta strumentazione. Se questa variabile di ambiente esiste già, assicurati che sia impostata sul valore richiesto.
## Prezzi
L'utilizzo di Application Signals per le funzioni Lambda comporta dei costi. Per informazioni sui prezzi, consulta la pagina [Prezzi di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Runtime supportati
L'integrazione di Application Signals con Lambda funziona con i seguenti runtime:
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Abilitazione di Application Signals nella console Lambda
Puoi abilitare Application Signals su qualsiasi funzione Lambda esistente utilizzando un [runtime supportato](#monitoring-application-signals-runtimes). La procedura seguente descrive come abilitare Application Signals nella console Lambda.
**Per abilitare Application Signals nella console Lambda**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione.
1. Scegli la scheda **Configurazione**.
1. Dal menu a sinistra, scegli **Strumenti di monitoraggio e operazioni**.
1. Nel riquadro **Strumenti di monitoraggio aggiuntivi** scegli **Modifica**.
1. In **CloudWatch Application Signals e AWS X-Ray** e in **Application Signals**, seleziona **Abilita**.
1. Selezionare **Salva**.
Se è la prima volta che abiliti Application Signals per la tua funzione, devi anche configurare una sola volta il rilevamento servizi per Application Signals nella console CloudWatch. Dopo aver completato questa configurazione una tantum del rilevamento servizi, Application Signals rileva automaticamente tutte le funzioni Lambda aggiuntive per le quali abiliti Application Signals, in tutte le regioni.
**Nota**
Dopo aver richiamato la funzione aggiornata, possono essere necessari fino a 10 minuti prima che i dati di servizio inizino a comparire nel pannello di controllo di Application Signals nella console CloudWatch.
## Utilizzo del pannello di controllo di Application Signals
Dopo aver abilitato Application Signals per la tua funzione, puoi visualizzare i parametri dell'applicazione nella console CloudWatch. Puoi visualizzare rapidamente il pannello di controllo di Application Signals associato dalla console Lambda con i seguenti passaggi:
**Per visualizzare il pannello di controllo di Application Signals relativo alla tua funzione**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione.
1. Selezionare la scheda **Monitor (Monitora)**.
1. Scegli il pulsante **Visualizza Application Signals**. Verrà aperta direttamente la panoramica di Application Signals per il tuo servizio nella console CloudWatch.
Ad esempio, la schermata seguente mostra i parametri relativi a latenza, numero di richieste, disponibilità, tasso di guasti e tasso di errore per una funzione in una finestra temporale di 10 minuti.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Per sfruttare al meglio l'integrazione con Application Signals, puoi creare obiettivi a livello di servizio (SLO) per la tua applicazione. Ad esempio, puoi creare SLO di latenza per garantire che l'applicazione risponda rapidamente alle richieste degli utenti e SLO di disponibilità per monitorare il tempo di attività. Gli SLO possono aiutarti a rilevare il peggioramento delle prestazioni o le interruzioni prima che abbiano un impatto sugli utenti. Per ulteriori informazioni, consulta [Service level objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) nella Guida per l'utente di Amazon CloudWatch.
# Esecuzione da remoto del debug delle funzioni Lambda con Visual Studio Code
Con la funzionalità di debug remoto nel [AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/), puoi eseguire il debug delle funzioni Lambda in esecuzione direttamente nel cloud AWS. Ciò è utile quando si esaminano problemi difficili da replicare localmente o da diagnosticare solo con i log.
Con il debug da remoto, puoi:
+ Impostare punti di interruzione nel codice della funzione Lambda.
+ Eseguire il codice in tempo reale.
+ Ispezionare le variabili e lo stato durante il runtime.
+ Funzioni di debug Lambda implementate su AWS, incluse quelle in VPC o con autorizzazioni IAM specifiche.
## Runtime supportati
Il debug da remoto è supportato per i seguenti runtime:
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**Nota**
Il debug da remoto è supportato per le architetture sia x86\$164 sia arm64.
## Sicurezza e debug da remoto
Il debug da remoto opera entro i limiti di sicurezza Lambda esistenti. Gli utenti possono collegare livelli a una funzione utilizzando l'autorizzazione `UpdateFunctionConfiguration`, che ha già la possibilità di accedere alle variabili di ambiente e alla configurazione della funzione. Il debug da remoto non va oltre queste autorizzazioni esistenti. Aggiunge invece ulteriori controlli di sicurezza attraverso il tunneling sicuro e la gestione automatica delle sessioni. Inoltre, il debug da remoto è interamente una funzionalità controllata dal cliente che richiede autorizzazioni e azioni esplicite:
+ **Creazione di tunnel IoT sicuri**: il Toolkit AWS deve creare un tunnel IoT sicuro, cosa che si verifica solo con l'autorizzazione esplicita dell'utente che usa `iot:OpenTunnel`.
+ **Gestione di allegati e token del livello di debug**: il processo di debug mantiene la sicurezza attraverso questi controlli:
+ Il livello di debug deve essere collegato alla funzione Lambda e questo processo richiede le seguenti autorizzazioni: `lambda:UpdateFunctionConfiguration` e `lambda:GetLayerVersion`.
+ Un token di sicurezza (generato tramite `iot:OpenTunnel`) deve essere aggiornato nella variabile di ambiente della funzione prima di ogni sessione di debug, il che richiede anch'esso `lambda:UpdateFunctionConfiguration`.
+ Per motivi di sicurezza, questo token viene ruotato automaticamente e il livello di debug viene rimosso automaticamente alla fine di ogni sessione di debug e non può essere riutilizzato.
**Nota**
Il debug da remoto è supportato per le architetture sia x86\$164 sia arm64.
## Prerequisiti
Prima di iniziare il debug da remoto, assicurati di disporre di quanto riportato di seguito:
1. Una funzione Lambda implementata sul tuo account AWS.
1. AWS Toolkit for Visual Studio Code. Consulta [Configurazione del AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html) per le istruzioni di installazione.
1. La versione del Toolkit AWS installata deve essere la **3.69.0** o successiva.
1. Credenziali AWS configurate in AWS Toolkit for Visual Studio Code. Per ulteriori informazioni, consulta [Autenticazione e controllo degli accessi](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control).
## Debug da remoto delle funzioni Lambda
Esegui questi passaggi per avviare una sessione di debug da remoto:
1. Apri l’Esploratore AWS in VS Code selezionando l'icona AWS nella barra laterale sinistra.
1. Espandi la sezione Lambda per vedere le tue funzioni.
1. Fai clic con il pulsante destro del mouse sulla funzione di cui desideri eseguire il debug.
1. Dal menu contestuale, seleziona **Richiama da remoto**.
1. Nella finestra di invocazione che si apre, seleziona la casella **Abilita debug**.
1. Fai clic su **Richiama** per avviare la sessione di debug remota.
**Nota**
Le funzioni Lambda hanno un limite combinato di 250 MB per il codice della funzione e tutti i livelli collegati. Il livello di debug da remoto aggiunge circa 40 MB alle dimensioni della funzione.
Una sessione di debug da remoto termina quando:
+ Scegliere **Rimuovi configurazione debug** dalla schermata di configurazione Richiama da remoto.
+ Selezionare l'icona di disconnessione nei controlli di debug di VS Code.
+ Selezionare il file del gestore nell'editor VS Code.
**Nota**
Il livello di debug viene rimosso automaticamente dopo 60 secondi di inattività dopo l'ultima invocazione.
## Disabilitazione de debug da remoto
Puoi disabilitare questa funzionalità in tre modi:
+ **Nega aggiornamenti delle funzioni**: imposta `lambda:UpdateFunctionConfiguration` su `deny`.
+ **Limita autorizzazioni IoT**: nega le autorizzazioni relative all'IoT.
+ **Blocca livelli di debug**: nega `lambda:GetLayerVersion` per i seguenti ARN:
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**Nota**
La disabilitazione di questa funzionalità impedisce l'aggiunta del livello di debug durante gli aggiornamenti della configurazione delle funzioni.
## Informazioni aggiuntive
Per ulteriori informazioni sull'utilizzo di Lambda in VS Code, consulta [Sviluppo locale di funzioni Lambda con VS Code](foundation-iac-local-development.md).
Per istruzioni dettagliate sulla risoluzione dei problemi, sui casi d'uso avanzati e sulla disponibilità delle regioni, consulta [Debug remoto delle funzioni Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) nella Guida per l'utente di AWS Toolkit for Visual Studio Code.