Il logging dei runtime di seconda generazione è diverso da quelli di prima generazione. Una delle principali modifiche quando esegui l'upgrade a runtime più recenti è che il logging preintegrato con App Engine non è supportato nei runtime di seconda generazione e i log non sono correlati automaticamente. Se stai eseguendo la migrazione a runtime di seconda generazione, devi utilizzare la libreria client Cloud Logging.
Questa guida descrive come aggiornare l'app per utilizzare Cloud Logging e ottenere quasi le stesse funzionalità di filtro e correlazione dei log che erano disponibili con l'integrazione di logging in App Engine.
Cloud Logging è un sistema di gestione dei log in tempo reale con supporto per archiviazione, ricerca, analisi e monitoraggio. Cloud Logging raccoglie automaticamente i log dalle risorse Google Cloud. Puoi anche raccogliere log dalle tue applicazioni, risorse on-premise e risorse di altri cloud provider.
Differenze principali
La tabella seguente illustra le differenze nel logging tra i runtime di prima e seconda generazione:
Runtime di prima generazione | Runtime di seconda generazione | |
---|---|---|
Log delle richieste e delle app (chiamati anche log delle applicazioni) |
App Engine incorpora tutti i log delle app all'interno del log delle richieste. La registrazione per i runtime di prima generazione utilizza il campo protoPayload.line.logMessage del log delle richieste per incorporare i log dell'app. |
App Engine non incorpora i log delle app all'interno del log delle richieste associato.
App Engine omette l'attributo protoPayload.line nel log
delle richieste.
I log delle app vengono indirizzati in base al tuo metodo di logging:
|
Visualizzazione dei log in Esplora log |
I runtime di prima generazione contengono un solo tipo di log,
appengine.googleapis.com/request_log . Quando espandi un log delle richieste, puoi visualizzare i log dell'app nidificati al di sotto.
|
I runtime di seconda generazione includono log di più tipi, ad esempio i log delle richieste in appengine.googleapis.com/request_log , stdout , stderr , logs/python e molti altri, a seconda di come l'app invia i log.
I log interni di Google sono disponibili anche in /var/log/google_init.log .
Poiché i log delle app non sono correlati automaticamente ai log delle richieste, sono necessari passaggi aggiuntivi per visualizzare la visualizzazione nidificata dei log delle richieste e delle app in Esplora log. Per maggiori informazioni, consulta Correlare i log delle richieste con i log delle app e Visualizzare i log correlati in Esplora log. |
Integrazione di Cloud Trace | Integrazione automatica con Cloud Trace per la raccolta dei dati di latenza. | Per raccogliere i dati relativi alla latenza da App Engine, devi integrare manualmente l'app con Cloud Trace. Per maggiori informazioni, consulta Strumento per Cloud Trace. |
Correlazione a livello di errore | Registra l'errore generato nei log delle richieste di App Engine con un livello di gravità ERROR. Error Reporting mette automaticamente in correlazione questi dettagli nella dashboard di Error Reporting. | Per impostazione predefinita, App Engine non integra Error Reporting nei runtime di seconda generazione. Per configurare l'integrazione del logging con Error Reporting, consulta Strumento per le app utilizzando le librerie client . |
Livello di gravità | Esplora log assegna un livello di gravità ai log delle richieste e questo livello riflette la massima gravità di qualsiasi voce di log dell'app correlata alla voce del log delle richieste. Ad esempio, se una richiesta comporta l'emissione di una voce di log di avviso da parte dell'app, Esplora log mostrerà un'icona di avviso accanto alla voce del log delle richieste. Quando espandi la voce della richiesta, vedrai la voce di log degli avvisi nidificata all'interno della voce della richiesta. | Per impostazione predefinita, tutti i log delle richieste hanno una gravità pari a DEFAULT o INFO .
Anche se i log delle richieste sono correlati ai log delle app ed
Esplora log è configurato per visualizzare i log correlati,
i log delle richieste non riflettono la gravità dei log delle app associati.
|
API Logservice | L'API Logservice fa parte dell'SDK dei servizi in bundle. | L'API Logservice è stata rimossa dall'SDK dei servizi in bundle. Per maggiori informazioni, consulta l'elenco delle API disponibili. |
Prima di avviare la migrazione
Abilita l'API Cloud Logging nel progetto che contiene la tua app.
Assicurati che la tua app abbia l'autorizzazione per scrivere log.
Per impostazione predefinita, l'account di servizio predefinito dell'app dispone dell'autorizzazione per scrivere i log.
Se la tua app utilizza un account di servizio diverso o se hai modificato le autorizzazioni per l'account di servizio predefinito, assicurati che l'account che utilizzi abbia l'autorizzazione
logging.logEntries.create
per scrivere i log.Acquisisci familiarità con i diversi tipi di log in App Engine.
Panoramica del processo di migrazione
Per eseguire la migrazione della tua app in modo da utilizzare Cloud Logging:
- Installa le librerie client di Cloud per Cloud Logging
- Scrivi i log con Cloud Logging
- Correlare i log delle richieste con i log delle app
- Visualizza i log
- Testare l'app
Installazione delle librerie client di Cloud per Cloud Logging
Per installare e aggiornare i file di configurazione, aggiungi le librerie client di Cloud per Cloud Logging all'elenco delle dipendenze nel file requirements.txt
, come in questo modo:
google-cloud-logging
Scrivi i log con il modulo di logging Python standard
In ogni file che scrive le voci di log:
- Importa la libreria client di Cloud Logging.
- Crea un'istanza per il client Cloud Logging.
- Esegui il metodo
setup_logging()
del client Cloud Logging, che collega il suo listener predefinito come gestore di logging per il logger root Python.
Ad esempio:
Dopo aver collegato il gestore, tutti i log a livello di INFO
o superiore
emessi nell'applicazione verranno inviati a Logging
per impostazione predefinita:
Correla i log delle richieste con i log delle app
Alcune funzionalità disponibili nei runtime di prima generazione, come la correlazione automatica dei log delle richieste con i log delle app, non sono disponibili nei runtime di seconda generazione.
Le app che utilizzano runtime di seconda generazione possono ottenere un comportamento di logging nidificato simile a quello dei runtime di prima generazione in uno dei seguenti modi:
- Configurazione del client Cloud Logging nell'applicazione e relativi log.
- Viene utilizzato un identificatore
trace
constdout
estderr
.
Il comportamento del logging nei runtime di prima e seconda generazione è diverso per i seguenti motivi:
Nei runtime di prima generazione, App Engine incorpora tutti i log delle app emessi durante la gestione di una richiesta nel campo
protoPayload.line.logMessage
del log delle richieste. Questi log sono visibili in Esplora log fino al giornoappengine.googleapis.com/request_log
.L'immagine seguente mostra i log correlati di richieste e app nei runtime di prima generazione:
In runtime di seconda generazione, App Engine omette l'attributo
protoPayload.line
nel log delle richieste. I contenuti dei log dell'app non sono presenti nei log delle richieste JSON in Esplora log. Ogni log delle app verrà visualizzato separatamente in base al nome di log in Esplora log.L'immagine seguente mostra log separati per richieste e app nei runtime di seconda generazione:
Le sezioni seguenti spiegano come utilizzare il client Cloud Logging o il logging strutturato con stdout
e stderr
per la correlazione dei log.
Usa il modulo di logging in Python
Per aggiungere la correlazione della richiesta ai log dell'app registrati dal modulo di logging di Python, configura la libreria client di Cloud Logging.
Quando esegui il metodo client.setup_logging()
all'avvio dell'applicazione, questo metodo aggiunge il campo trace
e i dettagli della richiesta HTTP ai log dell'app scritti dal modulo logging
Python, ad esempio logging.info()
e logging.error()
. Questi log vengono indirizzati a logs/python
.
Inoltre, App Engine aggiunge questo campo trace
al log delle richieste associato,
in modo da poter visualizzare le voci di log correlate in Esplora log.
Utilizza stdout
e stderr
Se utilizzi stdout
e stderr
per scrivere voci di log, queste voci vengono visualizzate in Esplora log. Tuttavia, per abilitare il filtro e la correlazione con i log delle richieste, devi formattare le voci come oggetto JSON e fornire metadati specifici. Per
maggiori informazioni su questo approccio, consulta Scrivere log strutturati in stdout e stderr.
Questo approccio aggiunge l'identificatore di traccia della richiesta nei log dell'applicazione tramite:
- Estrazione dell'identificatore della traccia dall'intestazione della richiesta
X-Cloud-Trace-Context
. - Scrivere l'ID in un campo denominato
logging.googleapis.com/trace
nella voce di log strutturato. Per ulteriori informazioni sull'intestazioneX-Cloud-Trace-Context
, consulta Forzare il tracciamento di una richiesta.
visualizza i log
Puoi visualizzare i log delle app e delle richieste in diversi modi:
- Utilizza Esplora log di Cloud Logging nella console Google Cloud.
- Utilizza Google Cloud CLI per visualizzare i log utilizzando gcloud.
- Leggere i log in modo programmatico utilizzando vari metodi.
Utilizza Esplora log
Puoi visualizzare i log delle app e delle richieste utilizzando Esplora log:
Vai a Esplora log nella console Google Cloud:
Seleziona un progetto Google Cloud esistente nella parte superiore della pagina.
In Tipo di risorsa, seleziona Applicazione GAE.
Puoi filtrare Esplora log in base al servizio, alla versione e ad altri criteri di App Engine. Puoi anche cercare voci specifiche nei log. Per maggiori dettagli, consulta Utilizzo di Esplora log.
Se invii semplici voci di testo all'output standard, non puoi utilizzare il visualizzatore log per filtrare le voci dell'app in base alla gravità, né visualizzare quali log dell'app corrispondono a richieste specifiche. Puoi continuare a utilizzare altri tipi di filtri in Esplora log, come testo e timestamp.
Visualizza le voci di log correlate in Esplora log
In Esplora log, per visualizzare le voci di log figlio correlate a una voce di log padre, espandi la voce di log.
Ad esempio, per visualizzare le voci del log delle richieste di App Engine e delle applicazioni, segui questi passaggi:
Nel pannello di navigazione della console Google Cloud, seleziona Logging, quindi Esplora log:
In Tipo di risorsa, seleziona Applicazione GAE.
Per visualizzare e correlare i log delle richieste, in Nome log seleziona request_log. In alternativa, per creare la correlazione in base ai log delle richieste, fai clic su Correla per e seleziona request_log.
Nel riquadro Risultati delle query, fai clic su Espandi per espandere una voce di log. All'espansione, ogni log delle richieste mostrerà i log delle app associati.
Dopo aver creato un filtro per i log, ogni log delle richieste mostra i log delle app corrispondenti
come log figlio. Esplora log lo raggiunge mettendo in relazione
il campo trace
nei log dell'app e un determinato log delle richieste, supponendo che l'applicazione
utilizzi la libreria google-cloud-logging
.
L'immagine seguente mostra i log delle app raggruppati in base al campo trace
:
Utilizza Google Cloud CLI
Per visualizzare i log di App Engine dalla riga di comando, utilizza questo comando:
gcloud app logs tail
Per ulteriori informazioni, consulta gcloud app logs tail.
Lettura dei log in modo programmatico
Se vuoi leggere i log in modo programmatico, puoi utilizzare uno di questi metodi:
- Usa un sink di log in Pub/Sub e uno script per eseguire il pull da Pub/Sub.
- Chiama l'API Cloud Logging tramite la libreria client per il tuo linguaggio di programmazione.
- Chiama direttamente gli endpoint REST dell'API Cloud Logging.
Testa la tua app
La migrazione va a buon fine se riesci a eseguire il deployment dell'app senza errori. Per verificare che Cloud Logging funzioni, segui questi passaggi:
Vai a Esplora log ed espandi una voce di log delle richieste.
Assicurati che i log generati dall'app durante l'elaborazione di una richiesta siano nidificati all'interno del log delle richieste.
Se tutti gli endpoint dell'app funzionano come previsto, utilizza la suddivisione del traffico per aumentare lentamente il traffico dell'app aggiornata. Monitora attentamente l'app per rilevare eventuali problemi prima di instradare ulteriore traffico all'app aggiornata.