2016-06-08 14 views
14

Come suggerisce la documentazione AWS:Utilizzo della registrazione di pitone con AWS Lambda

import logging 
logger = logging.getLogger() 
logger.setLevel(logging.INFO) 
def my_logging_handler(event, context): 
    logger.info('got event{}'.format(event)) 
    logger.error('something went wrong') 

Ora ho fatto:

import logging 
logging.basicConfig(level = logging.INFO) 
logging.info("Hello World!") 

Il primo frammento di stampe di codice nella console Cloud Watch, ma la seconda no.

Non ho notato alcuna differenza poiché i due frammenti utilizzano il root logger.

+0

Ti manca "return" Hello World! "" – error2007s

+0

Perché non fare lo stesso del primo frammento di codice? Ottieni il logger che è già istanziato e quindi usa detto logger. –

+1

@ HEADLESS_0NE: Posso usare il primo. Ma mi piacerebbe capire perché questo comportamento. –

risposta

2

Probabilmente non fa riferimento allo stesso registratore, in realtà. Nel primo frammento, registrare il ritorno di: logging.Logger.manager.loggerDict

Restituirà un dict dei logger già inizializzati.

Inoltre, dalla documentazione logging, una nota importante sulla logging.basicConfig:

La configurazione di base per il sistema di registrazione con la creazione di uno StreamHandler con un Formatter predefinito e aggiungendolo al logger principale. Le funzioni debug(), info(), warning(), error() e critical() chiameranno basicConfig() automaticamente se non sono definiti handler per il logger root.

Questa funzione non fa nulla se il registratore di root ha già configurato gestori per esso.

Fonte: https://docs.python.org/2/library/logging.html#logging.basicConfig

+0

I frammenti sono separati. Quindi il secondo frammento non è configurato, quindi configurerà il logger root. E se chiamo logging.info userà il root logger. Per me non fa differenza dal primo frammento. –

+0

@ HEADLESS_0NE è proprio qui. Sembra che in lambda un logger sia già configurato. Se faccio quanto sopra ma imposta il livello su DEBUG, vedo più registri di quelli che sto producendo (non sto producendo nessuno di questi): '[DEBUG] \t 2016-10-29T09: 01: 28.376Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t Acquisizione 0 [DEBUG] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({ 'compensare': 0}) per aspettare i seguenti futures su [] [DEBUG] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({ 'Offset': 0}) done in attesa di futures' dipendente –

6

ho avuto un problema simile, e ho il sospetto che il contenitore lambda sta chiamando logging.basicConfig di aggiungere i gestori prima che il codice Lambda viene importato. Sembra una cattiva forma ...

Soluzione temporanea per verificare se i gestori di logger di root erano configurati e, in tal caso, rimuoverli, aggiungere il mio formattatore e il livello di registro desiderato (utilizzando basicConfig) e ripristinare i gestori.

si veda questo articolo Python logging before you run logging.basicConfig?

4

Copiato direttamente dalla risposta superiore nella questione @ collegamenti risposta di StevenBohrer a (questo ha fatto il trucco per me, sostituire l'ultima riga con il mio config):

root = logging.getLogger() 
if root.handlers: 
    for handler in root.handlers: 
     root.removeHandler(handler) 
logging.basicConfig(format='%(asctime)s %(message)s',level=logging.DEBUG) 
+0

funziona come un fascino –

0

in sostanza, la patch di registrazione scimmia AWS deve essere gestita in un modo molto particolare, in cui:

  1. il livello di registrazione è impostato dal livello superiore dello script (ad esempio, ., In fase di importazione)
  2. Le dichiarazioni di registro a cui è interessato vengono richiamati dall'interno della funzione lambda

Dal momento che è generalmente considerata una buona forma di non eseguire codice arbitrario nel modulo Python di importazione, di solito si dovrebbe essere in grado per ristrutturare il codice in modo che il sollevamento pesante avvenga solo all'interno della funzione lambda.

Problemi correlati