L'accesso nei runtime di seconda generazione è diverso da quello nei runtime di prima generazione. Uno dei cambiamenti più importanti durante l'upgrade ai runtime più recenti è che la registrazione preintegrata con App Engine non è supportata nei runtime di seconda generazione e i log non vengono correlati automaticamente. Se esegui la migrazione ai 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 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 i log dalle tue applicazioni, dalle risorse on-premise e dalle risorse di altri cloud provider.
Differenze principali
La seguente tabella illustra le differenze nella registrazione 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 dell'app nel log delle richieste. L'accesso nei runtime di prima generazione utilizza il campo protoPayload.line.logMessage del log delle richieste per incorporare i log delle app. |
App Engine non incorpora
i log delle app nel log di richiesta associato.
App Engine omette l'attributo protoPayload.line nel log
della richiesta.
I log delle app vengono indirizzati in base al metodo di registrazione:
|
Visualizzare i 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 delle app nidificati al suo interno.
|
I runtime di seconda generazione includono log di più tipi, ad esempio
log delle richieste in appengine.googleapis.com/request_log , stdout ,
stderr , logs/python e molti altri, a seconda di come
la tua app emette 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 delle richieste e dei log delle app in Logs Explorer. Per ulteriori informazioni, vedi Correlare i log delle richieste con i log delle app e Visualizzare i log correlati in Esplora log. |
Integrazione di Cloud Trace | Integrato automaticamente con Cloud Trace per la raccolta dei dati di latenza. | Devi integrare manualmente la tua app con Cloud Trace per raccogliere i dati per la latenza da App Engine. Per maggiori informazioni, consulta Strumentazione per Cloud Trace. |
Correlazione del livello di errore | Registra l'errore generato nei log di richiesta di App Engine con un livello di gravità ERROR. Error Reporting correla automaticamente questi dettagli nella dashboard Error Reporting. | Per impostazione predefinita, App Engine non integra Error Reporting nei runtime di seconda generazione. Per configurare l'integrazione della registrazione con Error Reporting, consulta Strumentare le app utilizzando le librerie client . |
Livello di gravità | Esplora log assegna un livello di gravità ai log delle richieste e il livello di gravità riflette la gravità più elevata di qualsiasi voce di log dell'app correlata alla voce di log delle richieste. Ad esempio, se una richiesta fa sì che la tua app emetta una voce di log di avviso, Esplora log visualizzerà un'icona di avviso accanto alla voce di log della richiesta. Quando espandi la voce della richiesta, visualizzi la voce di log di avviso nidificata all'interno della voce della richiesta. | Per impostazione predefinita, tutti i log delle richieste hanno gravità DEFAULT o INFO .
Anche se i log delle richieste sono correlati ai log dell'app e
Esplora log è configurato per visualizzare i log correlati,
i log delle richieste non riflettono la gravità dei log dell'app associati.
|
API Logservice | L'API Logservice fa parte dell'SDK dei servizi in bundle. | L'API Logservice è stata rimossa dall'SDK Bundled Services. Per saperne di più, consulta l'elenco delle API disponibili. |
Prima di iniziare la migrazione
Abilita l'API Cloud Logging nel progetto che contiene la tua app.
Assicurati che la tua app disponga dell'autorizzazione per scrivere i log.
Per impostazione predefinita, il service account predefinito della tua app dispone dell'autorizzazione per scrivere i log.
Se la tua app utilizza un service account diverso o se hai modificato le autorizzazioni per il account di servizio predefinito, assicurati che l'account che utilizzi disponga dell'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 dell'app in modo che utilizzi Cloud Logging:
- Installa le librerie client di Cloud per Cloud Logging
- Scrivere log con Cloud Logging
- Correlare i log delle richieste con i log delle app
- Visualizza i log
- Testare l'app
Installazione delle librerie client 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 segue:
google-cloud-logging
Scrivere log con il modulo di logging Python standard
In ogni file che scrive voci di log:
- Importa la libreria client di Cloud Logging.
- Crea un'istanza del client Cloud Logging.
- Esegui il metodo
setup_logging()
del client Cloud Logging, che collega il listener predefinito come gestore di logging per il logger radice Python.
Ad esempio:
Dopo aver collegato il gestore, tutti i log a livello INFO
o superiore
emessi nella tua applicazione verranno inviati a Logging
per impostazione predefinita:
Correlare 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 due modi:
- Configurazione del client Cloud Logging nell'applicazione e correlazione dei log.
- Utilizzo di un identificatore
trace
constdout
estderr
.
Il comportamento di logging nei runtime di prima e seconda generazione differisce nei seguenti modi:
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 tramiteappengine.googleapis.com/request_log
.La seguente immagine mostra i log delle richieste e delle app correlati nei runtime di prima generazione:
Nei 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 dell'app verrà visualizzato separatamente in base al nome del log in Esplora log.L'immagine seguente mostra i log delle richieste e delle app separati nei runtime di seconda generazione:
Le sezioni seguenti descrivono come utilizzare il client Cloud Logging o
il logging strutturato con stdout
e stderr
per correlare i log.
Utilizzare il modulo di logging di Python
Per aggiungere la correlazione delle richieste ai log delle app registrati dal modulo di logging 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 Python logging
, ad esempio logging.info()
e logging.error()
. Questi
log vengono indirizzati a logs/python
.
App Engine aggiunge anche questo campo trace
al log delle richieste associato,
il che consente di visualizzare le voci di log correlate in Esplora log.
Utilizza stdout
e stderr
Se utilizzi stdout
e stderr
per scrivere le voci di log, queste vengono visualizzate in Esplora log. Tuttavia, per attivare 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 su stdout e stderr.
Questo approccio aggiunge l'identificatore della traccia della richiesta nei log dell'applicazione:
- Estrazione dell'identificatore di traccia dall'intestazione della richiesta
X-Cloud-Trace-Context
. - Scrivendo l'ID in un campo denominato
logging.googleapis.com/trace
nella voce di log strutturata. Per maggiori informazioni sull'intestazioneX-Cloud-Trace-Context
, vedi Forzare la tracciabilità di una richiesta.
Visualizza i log
Puoi visualizzare i log delle app e delle richieste in diversi modi:
- Utilizza Esplora log da Cloud Logging nella console Google Cloud .
- Utilizza Google Cloud CLI per visualizzare i log utilizzando gcloud.
- Leggi i log in modo programmatico utilizzando vari metodi.
Utilizzare 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 GAE Application.
Puoi filtrare Logs Explorer per servizio, versione e altri criteri di App Engine. Puoi anche cercare voci specifiche nei log. Per i dettagli, consulta Utilizzo di Esplora log.
Se invii voci di testo semplici all'output standard, non puoi utilizzare Logs Visualizzatore per filtrare le voci dell'app in base alla gravità, né puoi vedere quali log dell'app corrispondono a richieste specifiche. Puoi comunque utilizzare altri tipi di filtri in Esplora log, ad esempio testo e timestamp.
Visualizzare le voci di log correlate in Esplora log
In Esplora log, per visualizzare le voci di log secondarie correlate a una voce di log principale, espandi la voce di log.
Ad esempio, per visualizzare la voce di log delle richieste di App Engine e le voci di log dell'applicazione:
Nel pannello di navigazione della console Google Cloud , seleziona Logging, quindi Esplora log:
In Tipo di risorsa, seleziona GAE Application.
Per visualizzare e correlare i log delle richieste, seleziona request_log in Nome log. In alternativa, per eseguire la correlazione in base ai log delle richieste, fai clic su Correlazione per e seleziona request_log.
Nel riquadro Risultati delle query, fai clic su Espandi per espandere una voce di log. Quando viene espanso, ogni log delle richieste mostra 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 secondari. Esplora log lo fa mettendo in correlazione
il campo trace
nei log delle app e un determinato log delle richieste, presupponendo che l'applicazione
utilizzi la libreria google-cloud-logging
.
L'immagine seguente mostra i log delle app raggruppati per il campo trace
:
Utilizza Google Cloud CLI
Per visualizzare i log di App Engine dalla riga di comando, utilizza il seguente comando:
gcloud app logs tail
Per saperne di più, consulta gcloud app logs tail.
Lettura programmatica dei log
Se vuoi leggere i log in modo programmatico, puoi utilizzare uno dei seguenti metodi:
- Utilizza un sink 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 ha esito positivo 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 dell'app generati dalla tua 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 gradualmente il traffico per l'app aggiornata. Monitora attentamente l'app per rilevare eventuali problemi prima di indirizzare più traffico verso l'app aggiornata.