Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo dei log Lambda API
Importante
La telemetria Lambda API sostituisce i Lambda Logs. API Sebbene i log API rimangano perfettamente funzionanti, in futuro consigliamo di utilizzare solo la telemetria. API Puoi sottoscrivere la tua estensione a uno stream di telemetria utilizzando la telemetria o i log. API API Dopo la sottoscrizione utilizzando uno di questiAPIs, qualsiasi tentativo di sottoscrizione utilizzando l'altro restituisce un errore. API
Lambda acquisisce automaticamente i log di runtime e li trasmette ad Amazon. CloudWatch Questo flusso di registri contiene i log generati dal codice funzione e dalle estensioni e anche i log generati da Lambda nell'ambito del richiamo della funzione.
Le estensioni Lambda possono utilizzare i Lambda Runtime Logs API per sottoscrivere i flussi di log direttamente dall'ambiente di esecuzione Lambda. Lambda trasmette i log all'estensione e l'estensione può quindi elaborare, filtrare e inviare i log a qualsiasi destinazione preferita.
The Logs API consente alle estensioni di sottoscrivere tre diversi flussi di log:
Log di funzioni che la funzione Lambda genera e scrive in
stdout
ostderr
.Log di estensione generati dal codice di estensione.
Log si piattaforma Lambda, che registrano eventi ed errori relativi a richiami ed estensioni.
Nota
Lambda invia tutti i log a CloudWatch, anche quando un'estensione sottoscrive uno o più flussi di log.
Argomenti
Sottoscrizione ai log di ricezione
Un'estensione Lambda può sottoscrivere per ricevere i log inviando una richiesta di iscrizione ai Logs. API
Per sottoscrivere i log di ricezione, è necessario l'identificatore di estensione (Lambda-Extension-Identifier
). Innanzitutto registrare l'estensione per ricevere l'identificatore dell'estensione. Quindi iscriviti ai log API durante l'inizializzazione. Al termine della fase di inizializzazione, Lambda non elabora le richieste di sottoscrizione.
Nota
L'APIabbonamento a Logs è idempotente. Le richieste di sottoscrizione duplicate non comportano sottoscrizioni duplicate.
Utilizzo della memoria
L'utilizzo della memoria aumenta linearmente man mano che aumenta il numero di abbonati. Le sottoscrizioni consumano risorse di memoria perché ogni sottoscrizione apre un nuovo buffer di memoria per archiviare i log. Per ottimizzare l'utilizzo della memoria, è possibile regolare la configurazione di buffering. L'utilizzo della memoria buffer conta per il consumo complessivo della memoria nell'ambiente di esecuzione.
Protocolli destinazione
È possibile scegliere uno dei seguenti protocolli per ricevere i log:
-
HTTP(consigliato) — Lambda invia i log a un HTTP endpoint locale (
http://sandbox.localdomain:${PORT}/${PATH}
) come matrice di record in formato. JSON Il parametro$PATH
è facoltativo. Nota che solo HTTP è supportato, non. HTTPS È possibile scegliere di ricevere i log tramite PUT oPOST. -
TCP— Lambda invia i log a una TCP porta in formato Newline JSON delimited
(). NDJSON
Si consiglia di utilizzare anziché. HTTP TCP ConTCP, la piattaforma Lambda non è in grado di riconoscere quando invia i log al livello dell'applicazione. Pertanto, se l'estensione si blocca si potrebbero perdere i log. HTTPnon condivide questa limitazione.
Si consiglia inoltre di configurare il HTTP listener locale o la TCP porta prima di sottoscrivere i registri di ricezione. Durante l'installazione, tenere presente quanto segue:
-
Lambda invia i log solo alle destinazioni che si trovano all'interno dell'ambiente di esecuzione.
-
Lambda ritenta il tentativo di inviare i log (con backoff) se non è presente alcun listener o se la POST richiesta or genera un errore. PUT Se il sottoscrittore del log si blocca, continuerà a ricevere i log dopo che Lambda riavvia l'ambiente di esecuzione.
-
Lambda riserva la porta 9001. Non ci sono altre restrizioni o raccomandazioni sul numero di porta.
Configurazione buffering
Lambda può tamponare i log e consegnarli al sottoscrittore. È possibile configurare questo comportamento nella richiesta di sottoscrizione specificando i seguenti campi facoltativi. Si noti che Lambda utilizza il valore predefinito per qualsiasi campo non specificato.
timeoutMs— Il tempo massimo (in millisecondi) di bufferizzazione di un batch. Valore predefinito: 1.000 Minimo: 25. Massimo: 30.000
maxBytes— La dimensione massima (in byte) dei log da memorizzare nel buffer. Valore predefinito: 262.144. Minimo: 262.144. Massimo: 1.048.576.
maxItems— Il numero massimo di eventi da memorizzare nel buffer. Valore predefinito: 10.000 Minimo: 1.000. Massimo: 10.000.
Durante la configurazione del buffering, prendere nota dei seguenti punti:
Lambda svuota i log se uno qualsiasi dei flussi di input è chiuso, ad esempio, se il runtime si arresta in modo anomalo.
Ogni sottoscrittore può specificare una configurazione di buffering diversa durante la richiesta di sottoscrizione.
Considerare la dimensione del buffer necessaria per leggere i dati. Aspettarsi di ricevere payload grandi come
2*maxBytes+metadata
, dovemaxBytes
è configurato nella richiesta di sottoscrizione. Ad esempio, Lambda aggiunge i byte di metadati seguenti a ciascun record:{ "time": "2020-08-20T12:31:32.123Z", "type": "function", "record": "Hello World" }
Se il server di sottoscrizione non è in grado di elaborare i log in ingresso abbastanza rapidamente, Lambda potrebbe eliminare i log per mantenere limitato l'utilizzo della memoria. Per indicare il numero di record eliminati, Lambda invia un log
platform.logsDropped
. Per ulteriori informazioni, consulta Lambda: non vengono visualizzati tutti i log della mia funzione.
Esempio di sottoscrizione
L'esempio seguente mostra una richiesta di sottoscrizione ai log della piattaforma e delle funzioni.
PUT http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs HTTP/1.1 { "schemaVersion": "2020-08-15", "types": [ "platform", "function" ], "buffering": { "maxItems": 1000, "maxBytes": 262144, "timeoutMs": 100 }, "destination": { "protocol": "HTTP", "URI": "http://sandbox.localdomain:8080/lambda_logs" } }
Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta di HTTP 200 risposte di successo.
HTTP/1.1 200 OK "OK"
Codice di esempio per Logs API
Per un codice di esempio che mostra come inviare log a una destinazione personalizzata, consulta Usare AWS Lambda le estensioni per inviare log a destinazioni personalizzate
Per esempi di codice in Python e Go che mostrano come sviluppare un'estensione Lambda di base e sottoscrivere i logAPI, consulta AWS Lambda Extensions
Riferimento ai log API
È possibile recuperare l'APIendpoint Logs dalla variabile di ambiente. AWS_LAMBDA_RUNTIME_API
Per inviare una API richiesta, utilizzate il prefisso che precede il percorso2020-08-15/
. API Per esempio:
http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs
La API specifica Open per la API versione Logs 2020-08-15 è disponibile qui: .zip logs-api-request
Subscribe
Per sottoscrivere uno o più flussi di log disponibili nell'ambiente di esecuzione Lambda, le estensioni inviano una API richiesta Subscribe.
Percorso – /logs
Metodo: PUT
Parametri corpo
destination
- Consultare Protocolli destinazione. Campo obbligatorio: sì Tipo: stringhe.
buffering
- Consultare Configurazione buffering. Campo obbligatorio: no. Tipo: stringhe.
types
– Un array dei tipi di log da ricevere. Campo obbligatorio: sì Tipo: array di stringhe Valori validi: «piattaforma», «funzione», «estensione».
schemaVersion
– Obbligatorio: no. Valore di default: "2020-08-15". Impostare su "2021-03-18" per l'estensione in modo da ricevere messaggi platform.runtimeDone.
Parametri di risposta
Le API specifiche Open per le risposte all'abbonamento, versione 2020-08-15, sono disponibili per i protocolli and: HTTP TCP
Codice di risposta
-
200 – Richiesta completata con successo
-
202 – Richiesta accettata. Risposta ad una richiesta di sottoscrizione durante il test locale.
-
4XX – Richiesta non valida
-
500 – Errore servizio
Se la richiesta ha esito positivo, il sottoscrittore riceve una risposta di HTTP 200 risposte positive.
HTTP/1.1 200 OK "OK"
Se la richiesta fallisce, il sottoscrittore riceve una risposta di errore. Ad esempio:
HTTP/1.1 400 OK { "errorType": "Logs.ValidationError", "errorMessage": URI port is not provided; types should not be empty" }
Messaggi di log
The Logs API consente alle estensioni di sottoscrivere tre diversi flussi di log:
Funzione – Log che la funzione Lambda genera e scrive in
stdout
ostderr
.Estensione – Log generati dal codice di estensione.
Piattaforma – Log generati dalla piattaforma runtime, che registrano eventi ed errori relativi a richiami ed estensioni.
Log delle funzioni
La funzione Lambda e le estensioni interne generano log di funzioni e li scrivono in stdout
o stderr
.
L'esempio seguente mostra il formato di un messaggio di registro delle funzioni. {«time»: «2020-08-20T 12:31:32.123 Z», «type»: «function», «record»: "found»: "found. ERROR Stack trace:\n\my-function (line 10)\n" }
Log di estensioni
Le estensioni possono generare log di estensioni. Il formato del log è uguale a quello di un log di funzioni.
Log di piattaforma
Lambda genera messaggi di log per eventi della piattaforma come platform.start
, platform.end
e platform.fault
.
Facoltativamente, è possibile sottoscrivere la versione 2021-03-18 dello schema Logs, che include il messaggio di registro. API platform.runtimeDone
Esempio di messaggi di log di piattaforma
Nell'esempio seguente vengono illustrati i log di inizio e di fine della piattaforma. Questi registri indicano l'ora di inizio e l'ora di fine della chiamata per la chiamata specificata. requestId
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.start", "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"} } { "time": "2020-08-20T12:31:32.123Z", "type": "platform.end", "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"} }
La piattaforma. initRuntimeDoneil messaggio di registro mostra lo stato della Runtime init
sottofase, che fa parte della fase del ciclo di vita di Init. In caso Runtime init
di esito positivo, il runtime invia una API richiesta /next
di runtime (per i on-demand
tipi di provisioned-concurrency
inizializzazione) o restore/next
(per il tipo di inizializzazione). snap-start
L'esempio seguente mostra una piattaforma di successo. initRuntimeDonemessaggio di registro per il tipo di snap-start
inizializzazione.
{ "time":"2022-07-17T18:41:57.083Z", "type":"platform.initRuntimeDone", "record":{ "initializationType":"snap-start", "status":"success" } }
La piattaforma. initReportil messaggio di registro mostra quanto è durata la Init
fase e quanti millisecondi ti sono stati fatturati durante questa fase. Quando il tipo di inizializzazione è provisioned-concurrency
, Lambda invia questo messaggio durante la chiamata. Quando il tipo di inizializzazione è snap-start
, Lambda invia questo messaggio dopo aver ripristinato lo snapshot. L'esempio seguente mostra una piattaforma. initReportmessaggio di registro per il tipo di snap-start
inizializzazione.
{ "time":"2022-07-17T18:41:57.083Z", "type":"platform.initReport", "record":{ "initializationType":"snap-start", "metrics":{ "durationMs":731.79, "billedDurationMs":732 } } }
Il registro dei report della piattaforma include metriche sulla chiamata specificata. requestId Il campo initDurationMs
è incluso nel log solo se la chiamata include un avvio a freddo. Se la traccia AWS X-Ray è attiva, il log include i metadati X-Ray. Nell'esempio seguente viene illustrato un log di rapporto della piattaforma per una chiamata che includeva un avvio a freddo.
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.report", "record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56", "metrics": {"durationMs": 101.51, "billedDurationMs": 300, "memorySizeMB": 512, "maxMemoryUsedMB": 33, "initDurationMs": 116.67 } } }
Il log della piattaforma acquisisce errori di runtime o dell'ambiente di esecuzione. L'esempio seguente mostra un messaggio di log di errore della piattaforma.
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.fault", "record": "RequestId: d783b35e-a91d-4251-af17-035953428a2c Process exited before completing request" }
Nota
AWS sta attualmente implementando modifiche al servizio Lambda. A causa di queste modifiche, potresti notare piccole differenze tra la struttura e il contenuto dei messaggi di registro di sistema e dei segmenti di traccia emessi da diverse funzioni Lambda nel tuo. Account AWS
Uno degli output di registro interessati da questa modifica è il campo del registro degli errori della piattaforma. "record"
Gli esempi seguenti mostrano "record"
campi illustrativi nei vecchi e nuovi formati. Il nuovo stile di registro degli errori contiene un messaggio più conciso
Queste modifiche verranno implementate nelle prossime settimane e tutte le funzioni, Regioni AWS ad eccezione della Cina e delle GovCloud regioni, passeranno all'utilizzo dei messaggi di registro e dei segmenti di traccia di nuovo formato.
Esempio record del registro degli errori della piattaforma (vecchio stile)
"record":"RequestId: ...\tError: Runtime exited with error: exit status 255\nRuntime.ExitError"
Esempio record del registro degli errori della piattaforma (nuovo stile)
"record":"RequestId: ... Status: error\tErrorType: Runtime.ExitError"
Lambda genera un registro delle estensioni della piattaforma quando un'estensione si registra con le estensioni. API L'esempio seguente mostra un messaggio dell'estensione della piattaforma.
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.extension", "record": {"name": "Foo.bar", "state": "Ready", "events": ["INVOKE", "SHUTDOWN"] } }
Lambda genera un registro di sottoscrizione dei log della piattaforma quando un'estensione sottoscrive i log. API Nell'esempio seguente viene illustrato un messaggio di sottoscrizione log.
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.logsSubscription", "record": {"name": "Foo.bar", "state": "Subscribed", "types": ["function", "platform"], } }
Lambda genera un log eliminato dei log di piattaforma quando un'estensione non è in grado di elaborare il numero di log che sta ricevendo. Nell'esempio seguente viene mostrato unplatform.logsDropped
messaggio di log.
{ "time": "2020-08-20T12:31:32.123Z", "type": "platform.logsDropped", "record": {"reason": "Consumer seems to have fallen behind as it has not acknowledged receipt of logs.", "droppedRecords": 123, "droppedBytes" 12345 } }
La piattaforma. restoreStartil messaggio di registro mostra l'ora di inizio della Restore
fase (solo tipo di snap-start
inizializzazione). Esempio:
{ "time":"2022-07-17T18:43:44.782Z", "type":"platform.restoreStart", "record":{} }
La piattaforma. restoreReportil messaggio di registro mostra quanto è durata la Restore
fase e quanti millisecondi ti sono stati fatturati durante questa fase (snap-start
solo per il tipo di inizializzazione). Esempio:
{ "time":"2022-07-17T18:43:45.936Z", "type":"platform.restoreReport", "record":{ "metrics":{ "durationMs":70.87, "billedDurationMs":13 } } }
Messaggi runtimeDone
della piattaforma
Se si imposta la versione dello schema su "2021-03-18" nella richiesta di sottoscrizione, Lambda invia un messaggio platform.runtimeDone
dopo il completamento della chiamata della funzione o con un errore. L'estensione può utilizzare questo messaggio per arrestare tutta la raccolta di dati di telemetria per questa chiamata di funzione.
Lambda genera il messaggio di platform.runtimeDone
log quando il runtime invia una richiesta Next
or Error
runtimeAPI. Il platform.runtimeDone
log informa gli utenti dei Logs API che l'invocazione della funzione è stata completata. Le estensioni possono utilizzare queste informazioni per decidere quando inviare tutti i dati di telemetria raccolti durante tale chiamata.
Esempi
Lambda invia il platform.runtimeDone
messaggio dopo che il runtime ha inviato la NEXT richiesta al termine dell'invocazione della funzione. Negli esempi seguenti vengono illustrati i messaggi relativi a ciascuno dei valori di stato: riuscita, errore e timeout.
Esempio di messaggio di riuscita
{ "time": "2021-02-04T20:00:05.123Z", "type": "platform.runtimeDone", "record": { "requestId":"6f7f0961f83442118a7af6fe80b88", "status": "success" } }
Esempio di messaggio di errore
{ "time": "2021-02-04T20:00:05.123Z", "type": "platform.runtimeDone", "record": { "requestId":"6f7f0961f83442118a7af6fe80b88", "status": "failure" } }
Esempio di messaggio di timeout
{ "time": "2021-02-04T20:00:05.123Z", "type": "platform.runtimeDone", "record": { "requestId":"6f7f0961f83442118a7af6fe80b88", "status": "timeout" } }
Esempio Piattaforma di esempio. restoreRuntimeDone messaggio (solo tipo di snap-start
inizializzazione)
La piattaforma. restoreRuntimeDoneil messaggio di registro mostra se la Restore
fase ha avuto successo o meno. Lambda invia questo messaggio quando il runtime invia una richiesta di restore/next
runtimeAPI. Ci sono tre stati possibili: riuscito, errore e timeout. L'esempio seguente mostra una piattaforma di successo. restoreRuntimeDonemessaggio di registro.
{ "time":"2022-07-17T18:43:45.936Z", "type":"platform.restoreRuntimeDone", "record":{ "status":"success" } }