{"id":1394,"date":"2020-05-15T13:21:38","date_gmt":"2020-05-15T11:21:38","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1394"},"modified":"2021-05-21T10:47:03","modified_gmt":"2021-05-21T08:47:03","slug":"best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/","title":{"rendered":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Le applicazioni, nel momento in cui passano in produzione, perdono la capacit\u00e0 di fornire direttamente informazioni su cosa sta succedendo dietro le quinte del codice, diventano delle scatole nere e quindi si ha la necessit\u00e0 di tracciare e monitorare efficacemente il loro comportamento. <strong>Il logging<\/strong> \u00e8 sicuramente la procedura pi\u00f9 semplice e diretta per approcciare il problema. Siamo infatti in grado di istruire il programma, in fase di sviluppo, ad emettere informazioni durante il suo funzionamento, e queste saranno utili per svolgere attivit\u00e0 di troubleshooting o semplicemente per effettuare analisi.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Quando si parla di <strong>Python<\/strong>, il modulo gi\u00e0 incluso per il logging \u00e8 progettato per funzionare direttamente con una fase di setup veramente minimale. Indipendentemente dal livello di esperienza come sviluppatore e del modulo di logging di Python, lo scopo di questo articolo \u00e8 di essere il pi\u00f9 esauriente possibile e di indagare a fondo le metodologie che permettono di sfruttare il logging al massimo.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Una nota a margine: questo articolo si compone di due parti. La seconda parte verter\u00e0 su come approcciarsi ai servizi di AWS, utilizzando una combinazione di <strong>AWS Kinesis Data Firehose<\/strong> e <strong>AWS ElasticSearch<\/strong> per realizzare un sistema efficace di ricerca ed analisi dei log attraverso la <strong>dashboard di Kibana<\/strong> e di permetterne la copia su S3 per mantenere uno storico dei log a portata di mano.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Le basi del modulo di logging di Python<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Prima di iniziare il nostro viaggio, facciamoci una semplice domanda: <strong>che cos\u2019\u00e8 un Logger?<\/strong> In pratica si tratta di un oggetto con cui uno sviluppatore interagisce per permettere la stampa di informazioni. Sono strumenti che utilizziamo per indicare al sistema che governa il programma come e cosa si voglia loggare.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Se prendiamo una istanza generica di un logger, possiamo inviare messaggi quando vogliamo senza preoccuparci della sua implementazione sottostante. Ad esempio, se si scrive <\/span><span style=\"font-weight: 400;\">logger.info(&#8220;Logging a variable %s&#8221;, variable1) <\/span><span style=\"font-weight: 400;\">si va ad indicare la seguente situazione:<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1386\" src=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/blog_puthon.png\" alt=\"\" width=\"283\" height=\"364\" srcset=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/blog_puthon.png 283w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/blog_puthon-233x300.png 233w\" sizes=\"(max-width: 283px) 100vw, 283px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">La <\/span><a href=\"https:\/\/docs.python.org\/3\/library\/\"><span style=\"font-weight: 400;\">Libreria standard di Python<\/span><\/a><span style=\"font-weight: 400;\"> fornisce un modulo di logging che permette di iniziare ad utilizzarlo senza nessun tipo di installazione aggiuntiva. Per aderire alle <strong>best practice<\/strong> che richiedono di evitare la semplice scrittura in console di quello che vogliamo riportare, il modulo di Python per il logging offre diversi vantaggi:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">supporto per il multi-threading;<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">livelli di logging;<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">pi\u00f9 flessibilit\u00e0;<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">separazione tra dati e formattazione.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Si pu\u00f2 esprimere il potenziale del logging proprio perch\u00e9 si va a separare il contenuto del log dalla sua forma. Prendendo in esame la sua forma, \u00e8 necessario considerare tre aspetti principali:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><b>Level<\/b><span style=\"font-weight: 400;\">: il livello minimo di priorit\u00e0 dei messaggi di cui fare log. In ordine crescente di severit\u00e0, i livelli sono: DEBUG, INFO, WARNING, ERROR e CRITICAL. Di base il livello \u00e8 settato su WARNING, ci\u00f2 significa che il modulo di logging di Python filtrer\u00e0 tutti i messaggi impostati a DEBUG o INFO.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>handler<\/b><span style=\"font-weight: 400;\">: determina dove verranno salvati i log. Se non specificato, la libreria di logging utilizzer\u00e0 uno <\/span><a href=\"https:\/\/docs.python.org\/3.7\/howto\/logging.html#what-happens-if-no-configuration-is-provided\"><span style=\"font-weight: 400;\">StreamHandler<\/span><\/a><span style=\"font-weight: 400;\"> per inviare i messaggi al sys.stderr o, per meglio intenderci, verso la console. Gestisce anche la formattazione.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>format<\/b><span style=\"font-weight: 400;\">: di base, la libreria propone la seguente formattazione: &lt;LEVEL&gt;:&lt;LOGGER_NAME&gt;:&lt;MESSAGE&gt;. Naturalmente \u00e8 data la possibilit\u00e0 di modificare lo stile delle righe di log, aggiungendo eventualmente informazioni custom, ma questa parte verr\u00e0 affrontata pi\u00f9 avanti.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\"><strong>Il modulo di logging di Python<\/strong> fornisce diverse modalit\u00e0 di configurazione dei logger. Le configurazioni consentono di combinare handler, formati e livelli per andare incontro a necessit\u00e0 specifiche. Cominciamo dalla configurazione pi\u00f9 semplice, quella mediante <\/span><span style=\"font-weight: 400;\">basicConfig()<\/span><span style=\"font-weight: 400;\">.\u00a0<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">basicConfig()<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Utilizzando il metodo <\/span><span style=\"font-weight: 400;\">basicConfig()<\/span><span style=\"font-weight: 400;\"> \u00e8 possibile <strong>configurare rapidamente il comportamento desiderato<\/strong> del proprio logger di root. Altri approcci gestibili per progetti di grandi dimensioni includono invece l&#8217;utilizzo di configurazioni di logging basate su file o su dizionario.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Tuttavia, puntare su <\/span><span style=\"font-weight: 400;\">basicConfig()<\/span><span style=\"font-weight: 400;\"> \u00e8 il modo preferito per iniziare a descrivere come affrontare al meglio la configurazione del logging.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Il modulo di logging, come detto poc&#8217;anzi, \u00e8 settato su WARNING come livello predefinito. Ci\u00f2 significa che, in determinate situazioni, si potrebbe non avere visibilit\u00e0 durante la ricerca di errori o, in generale, qualora si debba condurre una root cause analysis. In base ai suoi standard, il modulo di logging invia i log direttamente alla console. Altre opzioni, possibili e raccomandate, prevedono l\u2019uso di StreamHandler o SocketHandler per lo streaming in rete e di FileHandler per accedere direttamente al disco.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Anche se il salvataggio su file ha i suoi vantaggi, come quello di evitare potenziali errori relativi alla rete ed essere facile da configurare, in quest\u2019epoca, in cui le applicazioni sono distribuite sulla rete e si ridimensionano rapidamente, gestire gruppi di file, memorizzati localmente su macchine diverse, pu\u00f2 non essere una scelta pratica. Al contrario, questo approccio pu\u00f2 essere visto come un modo pratico per creare una copia di backup su file dei log, gi\u00e0 aggregati su una destinazione di rete.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Un esempio di basicConfig()<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Di seguito viene presentato un esempio che utilizza <\/span><span style=\"font-weight: 400;\">basicConfig()<\/span><span style=\"font-weight: 400;\"> con alcuni parametri di default per loggare su file. Il livello configurati \u00e8 DEBUG; ci\u00f2 permette di scrivere log con livello di severit\u00e0 pari o maggiore a DEBUG. Come informazione extra, sono provviste alcune regole di formattazione.<\/span><\/p>\n<p>&nbsp;<\/p>\n<pre>import logging\r\n\r\nlogging.basicConfig(level=logging.DEBUG,\r\n                    filename='basic_config_test1.log',\r\n                    format='%(asctime)s %(levelname)s:%(message)s')\r\n\r\n\r\ndef basic_config_test1():\r\n   logging.debug(\"debug log test\")\r\n   logging.error(\"error log test\")\r\n<\/pre>\n<p>Lanciando il codice, un nuovo basic_config_test1.log file viene generato con il seguente contenuto, fatta eccezione per le date, che dipendono chiaramente dal tempo di esecuzione.<\/p>\n<pre>2020-05-08 17:19:29,220 DEBUG:debug log test\r\n2020-05-08 17:19:29,221 ERROR:error log test\r\n<\/pre>\n<p>NOTA: il metodo basicConfig() si riferisce alla configurazione del root logger e sortisce il suo effetto soltanto la prima volta in cui viene chiamato a runtime.<\/p>\n<p>DEBUG-level log sono ora visibili, e tali log sono stampati con la seguente struttura personalizzata:<\/p>\n<p>%(asctime)s: ora e giorno in formato locale dell\u2019esecuzione della riga<br \/>\n%(levelname)s: livello di severit\u00e0 del messaggio<br \/>\n%(message)s: messaggio vero e proprio<\/p>\n<p>Per completare il tutto ecco una tabella descrittiva delle opzioni del metodo basicConfig():<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1389\" src=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/Screenshot-2020-05-15-at-11.36.37.png\" alt=\"table\" width=\"1284\" height=\"584\" srcset=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/Screenshot-2020-05-15-at-11.36.37.png 1284w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/Screenshot-2020-05-15-at-11.36.37-400x182.png 400w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/Screenshot-2020-05-15-at-11.36.37-1024x466.png 1024w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/Screenshot-2020-05-15-at-11.36.37-768x349.png 768w\" sizes=\"(max-width: 1284px) 100vw, 1284px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">Questo \u00e8 un modo semplice e pratico per configurare piccoli script. Seguendo le best practice di Python raccomandiamo di gestire <strong>un&#8217;istanza del logger per ogni modulo dell&#8217;applicazione<\/strong>, ma \u00e8 comprensibile che l\u2019utilizzo delle sole funzionalit\u00e0 del metodo <\/span><span style=\"font-weight: 400;\">basicConfig() <\/span><span style=\"font-weight: 400;\">possa risultare impegnativo e poco pulito. Ora ci concentreremo sulle tecniche per migliorare la soluzione di logging di base.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Best practice: una istanza di logging per ogni modulo<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Seguendo gli standard sulle best practice, possiamo impostare una soluzione a singolo logger per istanza. Un buon approccio, che si adatta molto bene, \u00e8 facile da configurare e dunque dovrebbe essere preso in considerazione quando si ha a che fare con <strong>applicazioni di grandi dimensioni<\/strong> che devono essere ridimensionate, \u00e8 sfruttare il metodo <\/span><span style=\"font-weight: 400;\">getLogger()<\/span><span style=\"font-weight: 400;\"> integrato.<\/span><\/p>\n<p>&nbsp;<\/p>\n<pre>logger = logging.getLogger(__name__)<\/pre>\n<p>Il metodo presentato crea un nuovo logger, differente da quello di root. L\u2019argomento __name__ corrisponde al fully qualified name del modulo dal quale il metodo viene richiamato. Questo permette inoltre di tenere in considerazione il nome del logger come parte integrante di una riga di log, creando dinamicamente il nome del logger sulla base del modulo con il quale si sta lavorando in quel momento.<\/p>\n<p>\u00c8 possibile recuperare il nome del logger con %(name)s come mostrato nel seguente esempio.<\/p>\n<pre># logging_test1.py\r\n\r\nimport logging\r\n\r\nlogging.basicConfig(level=logging.DEBUG,\r\n                   filename='basic_config_test1.log',\r\n                   format='%(asctime)s %(name)s %(levelname)s:%(message)s')\r\n\r\nlogger = logging.getLogger(__name__)\r\n\r\n\r\ndef basic_config_test1():\r\n   logger.debug(\"debug log test 1\")\r\n   logger.error(\"error log test 1\")\r\n\r\n\r\n# logging_test2.py\r\n\r\nimport logging\r\nimport logging_test1\r\n\r\nlogger = logging.getLogger(__name__)\r\n\r\n\r\n\r\ndef basic_config_test2():\r\n   logger.debug(\"debug log test 2\")\r\n   logger.error(\"error log test 2\")\r\n<\/pre>\n<p>Ora si \u00e8 creata una <strong>configurazione decisamente migliore;<\/strong> ogni modulo descrive se stesso all\u2019interno del log stream e tutto risulta molto pi\u00f9 chiaro. Ciononostante, il logger creato nel modulo logging_test2, utilizzer\u00e0 la stessa configurazione del logger creato nel modulo logging_test1, ovvero la configurazione del root logger. Come gi\u00e0 accennato, la seconda invocazione di basicConfig() non sortir\u00e0 effetto. Di conseguenza, eseguire sia basic_config_test1() che basic_config_test2() risulter\u00e0 nella creazione di un singolo file basic_config_test1.log con il seguente contenuto.<\/p>\n<pre>2020-05-09 19:37:59,607 logging_test1 DEBUG:debug log test 1\r\n2020-05-09 19:37:59,607 logging_test1 ERROR:error log test 1\r\n2020-05-09 19:38:05,183 logging_test2 DEBUG:debug log test 2\r\n2020-05-09 19:38:05,183 logging_test2 ERROR:error log test 2\r\n<\/pre>\n<p>A seconda del contesto dell\u2019applicazione, usare una singola configurazione per ogni logger istanziato nei moduli potrebbe non essere sufficiente. Nella prossima sezione verr\u00e0 analizzato come generare e distribuire le configurazioni di logging tra moduli diversi mediante fileConfig() o dictConfig().<\/p>\n<h2>Usare fileConfig() e dictConfig()<\/h2>\n<p>Anche se utilizzare basicConfig() rappresenta un modo rapido per iniziare a organizzare il logging, le configurazioni basate su file o dizionario offrono pi\u00f9 opzioni per andare incontro alle proprie esigenze, consentire pi\u00f9 di un logger nella propria applicazione e inviare il log a destinazioni diverse in base a fattori specifici .<\/p>\n<p>Questo \u00e8 anche il metodo preferito di framework come Django e Flask per impostare il logging nei progetti. Nelle prossime sezioni, daremo un&#8217;occhiata pi\u00f9 da vicino su come impostare una corretta configurazione basata su file o dizionario.<\/p>\n<h2>fileConfig()<\/h2>\n<p>I file di configurazione devono aderire a questa struttura, contenente alcuni elementi chiave.<\/p>\n<p>[loggers]: nome dei logger che si devono configurare.<br \/>\n[handlers]: handler da usare per logger specifici (es. consoleHandler, fileHandler).<br \/>\n[formatters]: il formato da applicare ad ogni logger.<\/p>\n<p>Ogni sezione del file (denominata al plurale) dovrebbe includere una o pi\u00f9 chiavi, separate da virgola, da collegare alla configurazione principale:<\/p>\n<pre>[loggers]\r\nkeys=root,secondary\r\n<\/pre>\n<p>The keys are used to traverse the file and read appropriate configurations for each section. The keys are defined as [_], where the section name is logger, handler, or formatter which are predefined as said before.<\/p>\n<p>Le chiavi sono utilizzate per attraversare il file e leggere le configurazioni appropriate per ogni singola sezione. Le chiavi sono definite secondo la forma [_], dove pu\u00f2 valere logger, handler o formatter come descritto poc\u2019anzi.<\/p>\n<p>Un semplice file di configurazione per il logging (logging.ini) \u00e8 mostrato di seguito.<\/p>\n<pre>[loggers]\r\nkeys=root,custom\r\n\r\n[handlers]\r\nkeys=fileHandler,streamHandler\r\n\r\n[formatters]\r\nkeys=formatter\r\n\r\n[logger_root]\r\nlevel=DEBUG\r\nhandlers=fileHandler\r\n\r\n[logger_custom]\r\nlevel=ERROR\r\nhandlers=streamHandler\r\n\r\n[handler_fileHandler]\r\nclass=FileHandler\r\nlevel=DEBUG\r\nformatter=formatter\r\nargs=(\"\/path\/to\/log\/test.log\",)\r\n\r\n[handler_streamHandler]\r\nclass=StreamHandler\r\nlevel=ERROR\r\nformatter=formatter\r\n\r\n[formatter_formatter]\r\nformat=%(asctime)s %(name)s - %(levelname)s:%(message)s\r\n<\/pre>\n<p>Le best practice di Python raccomandano di mantenere <strong>un solo handler per logger,<\/strong> basandosi sul concetto di eredit\u00e0 del logger per la propagazione delle propriet\u00e0. Ci\u00f2 significa che \u00e8 sufficiente specificare una configurazione in un logger padre per averla ereditata da tutti i logger figli senza doverla impostare in ognuno di essi. Un buon esempio di ci\u00f2 \u00e8 un uso intelligente del logger root come genitore.<\/p>\n<p>Ritornando al discorso principale, una volta preparato un file di configurazione, \u00e8 possibile collegarlo ad un logger con queste semplici righe di codice:<\/p>\n<pre>import logging.config\r\n\r\nlogging.config.fileConfig('\/path\/to\/logging.ini',\r\n                          disable_existing_loggers=False)\r\nlogger = logging.getLogger(__name__)\r\n<\/pre>\n<p>Questo esempio include il parametro disable_existing_loggers valorizzato a False, garantendo che tutti i logger preesistenti non vengano rimossi quando lo snippet di codice viene eseguito; questo \u00e8 indubbiamente un buon consiglio, perch\u00e8 molti moduli sono soliti definire un root logger ancora prima che fileConfig() venga chiamato.<\/p>\n<h2>dictConfig()<\/h2>\n<p>L\u2019esempio di configurazione del logger cos\u00ec come visto finora si pu\u00f2 descrivere anche mediante una comune struttura a dizionario. Tale dizionario seguir\u00e0 la struttura presentata gi\u00e0 con fileConfig() con sezioni concernenti logger, handler e formatter pi\u00f9 la presenza di alcuni parametri globali di utilit\u00e0. Di seguito un esempio:<\/p>\n<pre>import logging.config\r\n\r\n\r\nconfig = {\r\n   \"version\": 1,\r\n   \"disable_existing_loggers\": False,\r\n   \"formatters\": {\r\n       \"standard\": {\r\n           \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n           \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n       }\r\n   },\r\n   \"handlers\": {\r\n       \"standard\": {\r\n           \"class\": \"logging.StreamHandler\",\r\n           \"formatter\": \"standard\"\r\n       }\r\n   },\r\n   \"loggers\": {\r\n       \"\": {\r\n           \"handlers\": [\"standard\"],\r\n           \"level\": logging.INFO\r\n       }\r\n   }\r\n}\r\n<\/pre>\n<p>Per applicare questa configurazione \u00e8 sufficiente passare questo oggetto come parametro del dict config:<\/p>\n<pre>logging.config.dictConfig(config)<\/pre>\n<p>dictConfig() di base disabilita gli altri logger, a meno che disable_existing_loggers sia valorizzato a False cos\u00ec come fileConfig()nell\u2019esempio precedente.<\/p>\n<p>Tale configurazione pu\u00f2 anche essere salvata in un file YAML e da l\u00ec configurata. Molti sviluppatori spesso preferiscono utilizzare dictConfig() rispetto a fileConfig(), questo perch\u00e8 ha molti pi\u00f9 spunti di configurazione, pi\u00f9 facile da leggere e pi\u00f9 mantenibile.<\/p>\n<h2>Formattare i log secondo lo standard JSON<\/h2>\n<p>Grazie al modo in cui \u00e8 progettato, \u00e8 facile estendere il modulo di logging. Poich\u00e9 l\u2019obiettivo \u00e8 automatizzare il logging e integrarlo con Kibana, si desidera un formato pi\u00f9 adatto per l&#8217;aggiunta di propriet\u00e0 personalizzate e pi\u00f9 compatibile con i carichi di lavoro personalizzati. Quindi \u00e8 necessario configurare un <strong>formattatore JSON.<\/strong><\/p>\n<p>Se si vuole, \u00e8 possibile loggare in formato JSON creando un formattatore personalizzato che trasforma i record di log in una stringa codificata JSON:<\/p>\n<pre>import logging\r\nimport json\r\n\r\n\r\nclass JsonFormatter:\r\n   def format(self, record):\r\n       formatted_record = dict()\r\n\r\n       for key in ['created', 'levelname', 'pathname', 'msg']:\r\n           formatted_record[key] = getattr(record, key)\r\n\r\n       return json.dumps(formatted_record, indent=4)\r\n\r\n\r\nhandler = logging.StreamHandler()\r\nhandler.formatter = JsonFormatter()\r\n\r\nlogger = logging.getLogger(__name__)\r\nlogger.addHandler(handler)\r\n\r\nlogger.error(\"Test\")\r\n<\/pre>\n<p>Se non si vuole creare da zero il proprio formattatore custom, si pu\u00f2 fare riferimento a diverse librerie, sviluppate dalla community Python, che permettono di convertire i propri log in formato JSON. Una di queste \u00e8 python-json-logger . Per prima cosa bisogna installare la libreria nel proprio ambiente di sviluppo:<\/p>\n<pre>pip install python-json-logger<\/pre>\n<p>Ora \u00e8 possibile aggiornare la configurazione del dizionario per modificare un formattatore esistente o creare un nuovo formattatore da zero che generi stringhe in JSON come nell\u2019esempio seguente. Per usare un formattatore JSON basta specificare pythonjsonlogger.jsonlogger.JsonFormatter come valore della propriet\u00e0 &#8220;class&#8221;. Nella chiave &#8220;format&#8221; si possono definire gli attributi da aggiungere ai record di log:<\/p>\n<pre>import logging.config \r\n\r\n\r\nconfig = {\r\n   \"version\": 1,\r\n   \"disable_existing_loggers\": False,\r\n   \"formatters\": {\r\n       \"standard\": {\r\n           \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n           \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n       },\r\n \"json\": {\r\n    \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n    \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n    \"class\": \"pythonjsonlogger.jsonlogger.JsonFormatter\"\r\n }\r\n   },\r\n   \"handlers\": {\r\n       \"standard\": {\r\n           \"class\": \"logging.StreamHandler\",\r\n           \"formatter\": \"json\"\r\n       }\r\n   },\r\n   \"loggers\": {\r\n       \"\": {\r\n           \"handlers\": [\"standard\"],\r\n           \"level\": LogLevel.INFO.value\r\n       }\r\n   }\r\n}\r\n\r\nlogging.config.dictConfig(config)\r\nlogger = logging.getLogger(__name__)\r\n<\/pre>\n<p>I log inviati alla console, attraverso l\u2019handler standard, verranno scritti in formato JSON.<\/p>\n<p>Una volta inclusa la classe pythonjsonlogger.jsonlogger.JsonFormatter nel proprio file di configurazione di logging, la funzione dictConfig() \u00e8 in grado di creare un\u2019istanza di questo formattatore, ammesso che il codice venga eseguito in un ambiente di lavoro nel quale \u00e8 possibile importare il modulo python-json-logger.<\/p>\n<h2>Aggiungere informazioni contestuali ai propri log<\/h2>\n<p>Se si ha la necessit\u00e0 di aggiungere un p\u00f2 di contesto ai propri log, il modulo di logging di Python fornisce la possibilit\u00e0 di <strong>aggiungere attributi custom.<\/strong> Un modo elegante per arricchire i propri log richiede l\u2019uso della classe LoggerAdapter.<\/p>\n<pre>logger = logging.LoggerAdapter(logger, {\"custom_key1\": \"custom_value1\", \"custom_key2\": \"custom_value2\"})<\/pre>\n<p>Ci\u00f2 aggiunge effettivamente attributi personalizzati a tutti i record che attraversano quel logger.<br \/>\nSi noti che ci\u00f2 influisce su tutti i record di log nell&#8217;applicazione, comprese le librerie o altri framework che potrebbero essere in uso e per i quali si stanno emettendo log. Questo snippet pu\u00f2 essere usato per aggiungere attributi quali ID di richiesta univoci su tutte le righe di log, per tenere traccia delle richieste, o per aggiungere ulteriori informazioni contestuali.<\/p>\n<h2>Python: gestione delle exception e tracebacks<\/h2>\n<p><strong>Di default<\/strong> gli errori non includono nessuna informazione di traceback. Il log mostrer\u00e0 semplicemente l\u2019eccezione come errore, senza dettagli aggiuntivi. Per essere sicuri che logging.error() mostri l\u2019intero traceback, \u00e8 necessario aggiungere la propriet\u00e0 exc_info valorizzata a True. Per mostrare la differenza, si provi a loggare una eccezione con e senza exc_info.<\/p>\n<pre>import logging.config\r\n\r\n\r\nconfig = {\r\n  \"version\": 1,\r\n  \"disable_existing_loggers\": False,\r\n  \"formatters\": {\r\n      \"standard\": {\r\n          \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n          \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n      },\r\n      \"json\": {\r\n          \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n          \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n          \"class\": \"pythonjsonlogger.jsonlogger.JsonFormatter\"\r\n      }\r\n  },\r\n  \"handlers\": {\r\n      \"standard\": {\r\n          \"class\": \"logging.StreamHandler\",\r\n          \"formatter\": \"json\"\r\n      }\r\n  },\r\n  \"loggers\": {\r\n      \"\": {\r\n          \"handlers\": [\"standard\"],\r\n          \"level\": logging.INFO\r\n      }\r\n  }\r\n}\r\n\r\nlogging.config.dictConfig(config)\r\nlogger = logging.getLogger(__name__)\r\n\r\n\r\ndef test():\r\n   try:\r\n       raise NameError(\"fake NameError\")\r\n   except NameError as e:\r\n       logger.error(e)\r\n       logger.error(e, exc_info=True)\r\n<\/pre>\n<p>Se eseguiamo il metodo test(), quest\u2019ultimo generer\u00e0 il seguente output:<\/p>\n<pre>{\"asctime\": \"2020-05-10T16:43:12+0200\", \"name\": \"logging_test\", \"levelname\": \"ERROR\", \"message\": \"fake NameError\"}\r\n \r\n{\"asctime\": \"2020-05-10T16:43:12+0200\", \"name\": \"logging_test\", \"levelname\": \"ERROR\", \"message\": \"fake NameError\", \"exc_info\": \"Traceback (most recent call last):\\n  File \\\"\/Users\/aleric\/Projects\/logging-test\/src\/logging_test.py\\\", line 39, in test\\n    raise NameError(\\\"fake NameError\\\")\\nNameError: fake NameError\"}\r\n<\/pre>\n<p>Come possiamo vedere, la prima riga non fornisce molte informazioni sull&#8217;errore a parte un messaggio generico fake NameError; invece, la seconda riga, aggiungendo la propriet\u00e0 exc_info = True, mostra il traceback completo, che include informazioni sui metodi coinvolti e numeri di riga da seguire per vedere dove \u00e8 stata sollevata l&#8217;eccezione.<\/p>\n<p>In alternativa si pu\u00f2 ottenere lo stesso risultato usando logger.exception() da un exception handler come nell&#8217;esempio seguente:<\/p>\n<pre>def test():\r\n   try:\r\n       raise NameError(\"fake NameError\")\r\n   except NameError as e:\r\n       logger.error(e)\r\n       logger.exception(e)\r\n<\/pre>\n<p>Questo snippet permette di recuperare le stesse informazioni di traceback dell\u2019esempio precedente. Ci\u00f2 ha anche il vantaggio di impostare il livello di priorit\u00e0 del logging su logging.ERROR.<\/p>\n<p>Indipendentemente dal metodo utilizzato per acquisire il traceback, la disponibilit\u00e0 di tutte le informazioni sulle eccezioni complete nei log \u00e8 fondamentale per il monitoraggio e la risoluzione dei problemi delle prestazioni delle applicazioni.<\/p>\n<h2>Catturare eccezioni non gestite<\/h2>\n<p>Anche pensando a diversi scenari, \u00e8 chiaro che non \u00e8 possibile gestire ogni possibile eccezione che la propria applicazione pu\u00f2 generare. \u00c8 comunque possibile loggare eccezioni non gestite in modo da poterle esaminare in seguito.<\/p>\n<p>Un&#8217;eccezione risulta non gestita se generata al di fuori di un blocco try \/ except o se \u00e8 di un tipo diverso da quelli specificati in uno o pi\u00f9 statement except.<\/p>\n<p>Se un&#8217;eccezione non viene gestita nel metodo che in cui viene generata, viene trasmessa al metodo superiore che pu\u00f2, eventualmente, contenere la logica di gestione della stessa. Questo meccanismo trasmette l\u2019eccezione fino al metodo main, ammesso che i metodi sottostanti non contengano la logica di gestione di quella tipologia di eccezione.<\/p>\n<p>Se non viene gestita l&#8217;interprete invocher\u00e0 sys.excepthook(). Le informazioni di traceback non verranno loggate se non esplicitamente specificato all\u2019interno di un handler non predefinito (ad esempio un fileHandler).<\/p>\n<p>\u00c8 possibile utilizzare <strong>la libreria traceback di Python<\/strong> per formattare il traceback ed includerlo nel log record.<\/p>\n<p>Per esaminare il comportamento descritto sopra, modifichiamo la funzione di esempio in modo che venga generata un\u2019eccezione non gestita dal blocco try \/ except:<\/p>\n<pre>import logging.config\r\nimport traceback\r\n\r\nconfig = {\r\n  \"version\": 1,\r\n  \"disable_existing_loggers\": False,\r\n  \"formatters\": {\r\n      \"standard\": {\r\n          \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n          \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n      },\r\n      \"json\": {\r\n          \"format\": \"%(asctime)s %(name)s %(levelname)s %(message)s\",\r\n          \"datefmt\": \"%Y-%m-%dT%H:%M:%S%z\",\r\n          \"class\": \"pythonjsonlogger.jsonlogger.JsonFormatter\"\r\n      }\r\n  },\r\n  \"handlers\": {\r\n      \"standard\": {\r\n          \"class\": \"logging.StreamHandler\",\r\n          \"formatter\": \"json\"\r\n      }\r\n  },\r\n  \"loggers\": {\r\n      \"\": {\r\n          \"handlers\": [\"standard\"],\r\n          \"level\": logging.INFO\r\n      }\r\n  }\r\n}\r\n\r\nlogging.config.dictConfig(config)\r\nlogger = logging.getLogger(__name__)\r\n\r\n\r\ndef test():\r\n   try:\r\n       raise OSError(\"fake OSError\")\r\n   except NameError as e:\r\n       logger.error(e, exc_info=True)\r\n   except:\r\n       logger.error(\"Uncaught exception: %s\", traceback.format_exc())\r\n<\/pre>\n<p>Se eseguiamo il codice verr\u00e0 lanciata un\u2019eccezione di tipo OSError non gestita dalla logica di try-except. Nonostante ci\u00f2, grazie alla porzione di codice definita nel secondo blocco except, l\u2019eccezione verr\u00e0 comunque loggata:<\/p>\n<pre>{\"asctime\": \"2020-05-10T17:04:05+0200\", \"name\": \"logging_test\", \"levelname\": \"ERROR\", \"message\": \"Uncaught exception: Traceback (most recent call last):\\n  File \\\"\/Users\/aleric\/Projects\/logging-test\/src\/logging_test4.py\\\", line 38, in test\\n    raise OSError(\\\"fake OSError\\\")\\nOSError: fake OSError\\n\"}<\/pre>\n<p>Loggare il traceback completo di ogni eccezione, gestita o meno, garantisce una<strong> visibilit\u00e0 cruciale<\/strong> sugli errori generati in real-time, e permette di investigare le cause generanti.<\/p>\n<p>Questa \u00e8 la fine della parte uno di due del nostro articolo. Nella prossima parte vedremo <strong>come aggregare i log usando Amazon Kinesis Data Firehose ed Amazon ElasticSearch Service, e Kibana per analizzare i log in una dashboard<\/strong> centralizzata ed altamente customizzabile.<\/p>\n<p>Rimanete sintonizzati \ud83d\ude42<\/p>\n<p><a href=\"https:\/\/blog.besharp.it\/it\/parte-ii-best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-amazon-kinesis-data-firehose-e-amazon-elasticsearch-service\/\" target=\"_blank\" rel=\"noopener\">Vai alla Parte II<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Le applicazioni, nel momento in cui passano in produzione, perdono la capacit\u00e0 di fornire direttamente informazioni su cosa sta succedendo [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":1447,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[477],"tags":[269,261,265,273],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v21.9.1 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service - Proud2beCloud Blog<\/title>\n<meta name=\"description\" content=\"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Parte I: Best practice per il logging su Python\" \/>\n<meta property=\"og:description\" content=\"Logging su Python e integrazione con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/\" \/>\n<meta property=\"og:site_name\" content=\"Proud2beCloud Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-05-15T11:21:38+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2021-05-21T08:47:03+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/copertine-blog-Recuperato-38.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1667\" \/>\n\t<meta property=\"og:image:height\" content=\"1251\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Alessandro Gaggia\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\" \/>\n<meta name=\"twitter:description\" content=\"Logging su Python e integrazione con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/copertine-blog-Recuperato-38.png\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Alessandro Gaggia\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/\",\"url\":\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/\",\"name\":\"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service - Proud2beCloud Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\"},\"datePublished\":\"2020-05-15T11:21:38+00:00\",\"dateModified\":\"2021-05-21T08:47:03+00:00\",\"author\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/f27fc12d10867c6ea6e0158ce4dd8924\"},\"description\":\"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.besharp.it\/it\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\",\"url\":\"https:\/\/blog.besharp.it\/it\/\",\"name\":\"Proud2beCloud Blog\",\"description\":\"il blog di beSharp\",\"alternateName\":\"Proud2beCloud Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.besharp.it\/it\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/f27fc12d10867c6ea6e0158ce4dd8924\",\"name\":\"Alessandro Gaggia\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f58dc28050f26409e22ab60346d06220?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f58dc28050f26409e22ab60346d06220?s=96&d=mm&r=g\",\"caption\":\"Alessandro Gaggia\"},\"description\":\"Head of software development di beSharp, Full-Stack developer, mi occupo di garantire lo stato dell\u2019arte di tutta la nostra codebase. Scrivo codice in quasi ogni linguaggio, ma prediligo Typescript. Respiro Informatica, Game design, Cinema, Fumetti e buona cucina. Disegno per passione!\",\"url\":\"https:\/\/blog.besharp.it\/it\/author\/alessandro-gaggia\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service - Proud2beCloud Blog","description":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/","og_locale":"it_IT","og_type":"article","og_title":"Parte I: Best practice per il logging su Python","og_description":"Logging su Python e integrazione con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service","og_url":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/","og_site_name":"Proud2beCloud Blog","article_published_time":"2020-05-15T11:21:38+00:00","article_modified_time":"2021-05-21T08:47:03+00:00","og_image":[{"width":1667,"height":1251,"url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/copertine-blog-Recuperato-38.png","type":"image\/png"}],"author":"Alessandro Gaggia","twitter_card":"summary_large_image","twitter_title":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service","twitter_description":"Logging su Python e integrazione con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service","twitter_image":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2020\/05\/copertine-blog-Recuperato-38.png","twitter_misc":{"Scritto da":"Alessandro Gaggia","Tempo di lettura stimato":"14 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/","url":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/","name":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service - Proud2beCloud Blog","isPartOf":{"@id":"https:\/\/blog.besharp.it\/it\/#website"},"datePublished":"2020-05-15T11:21:38+00:00","dateModified":"2021-05-21T08:47:03+00:00","author":{"@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/f27fc12d10867c6ea6e0158ce4dd8924"},"description":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service","breadcrumb":{"@id":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.besharp.it\/it\/best-practice-per-il-logging-su-python-e-come-integrarsi-con-la-dashboard-di-kibana-tramite-aws-kinesis-data-firehose-ed-amazon-elasticsearch-service\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.besharp.it\/it\/"},{"@type":"ListItem","position":2,"name":"Parte I: Best practice per il logging su Python e come integrarsi con la dashboard di Kibana tramite AWS Kinesis Data Firehose ed Amazon Elasticsearch Service"}]},{"@type":"WebSite","@id":"https:\/\/blog.besharp.it\/it\/#website","url":"https:\/\/blog.besharp.it\/it\/","name":"Proud2beCloud Blog","description":"il blog di beSharp","alternateName":"Proud2beCloud Blog","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.besharp.it\/it\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"it-IT"},{"@type":"Person","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/f27fc12d10867c6ea6e0158ce4dd8924","name":"Alessandro Gaggia","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/f58dc28050f26409e22ab60346d06220?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f58dc28050f26409e22ab60346d06220?s=96&d=mm&r=g","caption":"Alessandro Gaggia"},"description":"Head of software development di beSharp, Full-Stack developer, mi occupo di garantire lo stato dell\u2019arte di tutta la nostra codebase. Scrivo codice in quasi ogni linguaggio, ma prediligo Typescript. Respiro Informatica, Game design, Cinema, Fumetti e buona cucina. Disegno per passione!","url":"https:\/\/blog.besharp.it\/it\/author\/alessandro-gaggia\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/1394"}],"collection":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/comments?post=1394"}],"version-history":[{"count":0,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/1394\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media\/1447"}],"wp:attachment":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media?parent=1394"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/categories?post=1394"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/tags?post=1394"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}