Avere visibilità sulla tua applicazione Java è fondamentale per capire come funziona adesso, come ha funzionato in passato e per aumentare la tua comprensione di come potrebbe funzionare in futuro. Più spesso che no, l’analisi dei log è il modo più veloce per individuare ciò che è andato storto, rendendo così il logging in Java fondamentale per garantire le prestazioni e la salute della vostra applicazione, nonché per minimizzare e ridurre qualsiasi tempo di inattività. Avere una soluzione centralizzata di log e monitoraggio aiuta a ridurre il tempo medio di riparazione migliorando l’efficacia del vostro team Ops o DevOps.

Seguendo le buone pratiche otterrete più valore dai vostri log e ne renderete più facile l’utilizzo. Sarete in grado di individuare più facilmente la causa principale degli errori e delle scarse prestazioni e risolvere i problemi prima che abbiano un impatto sugli utenti finali. Quindi oggi, permettetemi di condividere alcune delle migliori pratiche su cui dovreste giurare quando lavorate con le applicazioni Java.

Utilizzare una libreria di log standard

Il log in Java può essere fatto in diversi modi. Puoi usare una libreria di log dedicata, un’API comune, o anche solo scrivere i log su file o direttamente su un sistema di log dedicato. Tuttavia, quando scegliete la libreria di log per il vostro sistema pensate in anticipo. Le cose da considerare e valutare sono le prestazioni, la flessibilità, gli appender per nuove soluzioni di centralizzazione dei log e così via. Se ti leghi direttamente ad un singolo framework il passaggio ad una nuova libreria può richiedere una notevole quantità di lavoro e di tempo. Tenetelo a mente e scegliete l’API che vi darà la flessibilità di cambiare le librerie di log in futuro. Proprio come con il passaggio da Log4j a Logback e a Log4j 2, quando si usa l’API SLF4J l’unica cosa da fare è cambiare la dipendenza, non il codice.

Se sei nuovo alle librerie di log Java, dai un’occhiata alle nostre guide per principianti:

  • Log4j Tutorial
  • Logback Tutorial
  • Log4j2 Tutorial
  • SLF4J Tutorial

Seleziona i tuoi applicatori con cura

Gli applicatori definiscono dove i tuoi eventi di log saranno consegnati. Gli applicatori più comuni sono gli applicatori Console e File. Anche se utili e ampiamente conosciuti, potrebbero non soddisfare le tue esigenze. Per esempio, potresti voler scrivere i tuoi log in modo asincrono o potresti voler spedire i tuoi log in rete usando appender come quello per Syslog, come questo:

<Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout pattern="%d %level %c - %m%n"/> </Console> <Syslog name="Syslog" host="logsene-syslog-receiver.sematext.com" port="514" protocol="TCP" format="RFC5424" appName="11111111-2222-3333-4444-555555555555" facility="LOCAL0" mdcId="mdc" newLine="true"/></Appenders>

Tuttavia, tieni presente che usare appender come quello mostrato sopra rende la tua pipeline di log suscettibile a errori di rete e interruzioni di comunicazione. Questo potrebbe comportare che i log non vengano spediti a destinazione, il che potrebbe non essere accettabile. Vuoi anche evitare che i log influenzino il tuo sistema se l’appender è progettato in modo da bloccare. Per saperne di più controlla il nostro post sul blog Logging libraries vs Log shippers.

Use Meaningful Messages

Una delle cose cruciali quando si tratta di creare i log, ma una delle cose non così facili è usare messaggi significativi. I vostri eventi di log dovrebbero includere messaggi che sono unici per la situazione data, descriverli chiaramente e informare la persona che li legge. Immaginate che si sia verificato un errore di comunicazione nella vostra applicazione. Potresti fare così:

LOGGER.warn("Communication error");

Ma potresti anche creare un messaggio come questo:

LOGGER.warn("Error while sending documents to events Elasticsearch server, response code %d, response message %s. The message sending will be retried.", responseCode, responseMessage);

Puoi facilmente vedere che il primo messaggio informerà la persona che guarda i log su alcuni problemi di comunicazione. Quella persona probabilmente avrà il contesto, il nome del logger e il numero di linea in cui è avvenuto l’avvertimento, ma questo è tutto. Per ottenere più contesto quella persona dovrebbe guardare il codice, sapere a quale versione del codice l’errore è collegato, e così via. Questo non è divertente e spesso non è facile, e certamente non è qualcosa che si vuole fare mentre si cerca di risolvere un problema di produzione il più velocemente possibile.

Il secondo messaggio è migliore. Fornisce informazioni esatte su che tipo di errore di comunicazione si è verificato, cosa stava facendo l’applicazione in quel momento, quale codice di errore ha ottenuto e quale è stata la risposta del server remoto. Infine, informa anche che l’invio del messaggio sarà ritentato. Lavorare con tali messaggi è sicuramente più facile e piacevole.

Infine, pensate alla dimensione e alla verbosità del messaggio. Non registrate informazioni troppo prolisse. Questi dati devono essere memorizzati da qualche parte per essere utili. Un messaggio molto lungo non sarà un problema, ma se quella linea si ripete centinaia di volte in un minuto e avete molti log verbosi, mantenere una conservazione più lunga di tali dati può essere problematico e, alla fine della giornata, costerà anche di più.

Logging Java Stack Traces

Una delle parti molto importanti del logging Java sono le tracce dello stack Java. Date un’occhiata al seguente codice:

package com.sematext.blog.logging;import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;import java.io.IOException;public class Log4JExceptionNoThrowable { private static final Logger LOGGER = LogManager.getLogger(Log4JExceptionNoThrowable.class); public static void main(String args) { try { throw new IOException("This is an I/O error"); } catch (IOException ioe) { LOGGER.error("Error while executing main thread"); } }}

Il codice di cui sopra provocherà un’eccezione e un messaggio di log che verrà stampato sulla console con la nostra configurazione predefinita sarà il seguente:

11:42:18.952 ERROR - Error while executing main thread

Come potete vedere non ci sono molte informazioni. Sappiamo solo che il problema si è verificato, ma non sappiamo dove è successo, o qual era il problema, ecc. Non molto informativo.

Ora, guardate lo stesso codice con una dichiarazione di log leggermente modificata:

package com.sematext.blog.logging;import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;import java.io.IOException;public class Log4JException { private static final Logger LOGGER = LogManager.getLogger(Log4JException.class); public static void main(String args) { try { throw new IOException("This is an I/O error"); } catch (IOException ioe) { LOGGER.error("Error while executing main thread", ioe); } }}

Come potete vedere, questa volta abbiamo incluso l’oggetto eccezione stesso nel nostro messaggio di log:

LOGGER.error("Error while executing main thread", ioe);

Questo risulterebbe nel seguente log di errore nella console con la nostra configurazione predefinita:

11:30:17.527 ERROR - Error while executing main threadjava.io.IOException: This is an I/O error at com.sematext.blog.logging.Log4JException.main(Log4JException.java:13)

Contiene informazioni rilevanti – i.Cioè il nome della classe, il metodo dove si è verificato il problema, e infine il numero di linea dove il problema si è verificato. Naturalmente, in situazioni di vita reale, le tracce dello stack saranno più lunghe, ma dovreste includerle per darvi abbastanza informazioni per un debug corretto.

Per saperne di più su come gestire le tracce dello stack Java con Logstash vedete Handling Multiline Stack Traces with Logstash o guardate Logagent che lo può fare per voi out of the box.

Registrare le eccezioni Java

Quando si ha a che fare con eccezioni Java e tracce di stack non si dovrebbe pensare solo all’intero stack trace, alle linee in cui il problema è apparso, e così via. Dovreste anche pensare a come non trattare le eccezioni.

Evitare di ignorare silenziosamente le eccezioni. Non volete ignorare qualcosa di importante. Per esempio, non fate così:

try { throw new IOException("This is an I/O error");} catch (IOException ioe) {}

Inoltre, non registrate semplicemente un’eccezione e lanciatela oltre. Questo significa che avete appena spinto il problema su per lo stack di esecuzione. Evitate anche cose come questa:

try { throw new IOException("This is an I/O error");} catch (IOException ioe) { LOGGER.error("I/O error occurred during request processing", ioe); throw ioe;}

Se siete interessati a saperne di più sulle eccezioni, leggete la nostra guida sulla gestione delle eccezioni Java dove copriamo tutto, da cosa sono a come catturarle e risolverle.

Utilizzate un livello di log appropriato

Quando scrivete il codice della vostra applicazione pensate due volte a un dato messaggio di log. Non ogni bit di informazione è ugualmente importante e non ogni situazione inaspettata è un errore o un messaggio critico. Inoltre, usa i livelli di log in modo coerente – informazioni di un tipo simile dovrebbero essere su un livello di gravità simile.

Sia la facciata SLF4J che ogni framework di log Java che userai forniscono metodi che possono essere usati per fornire un livello di log adeguato. Per esempio:

LOGGER.error("I/O error occurred during request processing", ioe);

Log in JSON

Se abbiamo intenzione di registrare e guardare i dati manualmente in un file o nell’output standard allora il logging pianificato andrà più che bene. È più facile da usare – siamo abituati a questo. Ma questo è fattibile solo per applicazioni molto piccole e anche allora si suggerisce di usare qualcosa che permetta di correlare i dati delle metriche con i log. Fare queste operazioni in una finestra di terminale non è divertente e a volte non è semplicemente possibile. Se vuoi memorizzare i log nel sistema di gestione e centralizzazione dei log dovresti registrare in JSON. Questo perché il parsing non è gratuito – di solito significa usare espressioni regolari. Naturalmente, puoi pagare quel prezzo nel log shipper, ma perché farlo se puoi facilmente registrare in JSON. Registrare in JSON significa anche una facile gestione delle tracce di stack, quindi un altro vantaggio. Beh, puoi anche semplicemente registrare su una destinazione compatibile con Syslog, ma questa è un’altra storia.

Nella maggior parte dei casi, per abilitare la registrazione in JSON nel tuo framework di registrazione Java è sufficiente includere la configurazione corretta. Per esempio, supponiamo di avere il seguente messaggio di log incluso nel nostro codice:

LOGGER.info("This is a log message that will be logged in JSON!");

Per configurare Log4J 2 per scrivere i messaggi di log in JSON dovremmo includere la seguente configurazione:

<?xml version="1.0" encoding="UTF-8"?><Configuration status="WARN"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <JSONLayout compact="true" eventEol="true"> </JSONLayout> </Console> </Appenders> <Loggers> <Root level="info"> <AppenderRef ref="Console"/> </Root> </Loggers></Configuration>

Il risultato sarebbe il seguente:

{"instant":{"epochSecond":1596030628,"nanoOfSecond":695758000},"thread":"main","level":"INFO","loggerName":"com.sematext.blog.logging.Log4J2JSON","message":"This is a log message that will be logged in JSON!","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1,"threadPriority":5}

Mantieni la struttura del log coerente

La struttura dei tuoi eventi di log dovrebbe essere coerente. Questo non è solo vero all’interno di una singola applicazione o di un insieme di microservizi, ma dovrebbe essere applicato a tutto il tuo stack di applicazioni. Con eventi di log strutturati in modo simile sarà più facile esaminarli, confrontarli, correlarli o semplicemente memorizzarli in un archivio di dati dedicato. È più facile esaminare i dati provenienti dai vostri sistemi quando sapete che hanno campi comuni come la gravità e il nome dell’host, così potete facilmente affettare e tagliare i dati in base a queste informazioni. Per l’ispirazione, date un’occhiata a Sematext Common Schema anche se non siete un utente Sematext.

Naturalmente, mantenere la struttura non è sempre possibile, perché il vostro stack completo consiste di server sviluppati esternamente, database, motori di ricerca, code, ecc, ognuno dei quali ha il proprio set di log e formati di log. Tuttavia, per mantenere la sanità mentale tua e del tuo team, riduci al minimo il numero di diverse strutture di messaggi di log che puoi controllare.

Un modo per mantenere una struttura comune è quello di utilizzare lo stesso modello per i tuoi log, almeno quelli che utilizzano lo stesso framework di log. Per esempio, se le tue applicazioni e i tuoi microservizi usano Log4J 2 potresti usare uno schema come questo:

<PatternLayout> <Pattern>%d %p %c{35}:%L - %m%n</Pattern></PatternLayout>

Utilizzando un unico schema o un insieme molto limitato di schemi puoi essere sicuro che il numero di formati di log rimarrà piccolo e gestibile.

Aggiungi contesto ai tuoi log

Il contesto informativo è importante e per noi sviluppatori e DevOps un messaggio di log è un’informazione. Guardate la seguente voce di log:

 An error occurred!

Sappiamo che un errore è apparso da qualche parte nell’applicazione. Non sappiamo dove è successo, non sappiamo che tipo di errore era, sappiamo solo quando è successo. Ora guardate un messaggio con informazioni leggermente più contestuali:

 com.sematext.blog.logging.ParsingErrorExample - A parsing error occurred for user with id 1234!

Lo stesso record di log, ma molte più informazioni contestuali. Sappiamo il thread in cui è successo, sappiamo a quale classe è stato generato l’errore. Abbiamo anche modificato il messaggio per includere l’utente per il quale l’errore si è verificato, in modo da poter risalire all’utente se necessario. Potremmo anche includere informazioni aggiuntive come i contesti diagnostici. Pensate a ciò di cui avete bisogno e includetelo.

Per includere informazioni sul contesto non dovete fare molto quando si tratta del codice che è responsabile della generazione del messaggio di log. Per esempio, il PatternLayout in Log4J 2 ti dà tutto ciò di cui hai bisogno per includere le informazioni sul contesto. Puoi usare un pattern molto semplice come questo:

<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level - %msg%n"/>

Che risulterà in un messaggio di log simile al seguente:

17:13:08.059 INFO - This is the first INFO level log message!

Ma puoi anche includere un pattern che includerà molte più informazioni:

<PatternLayout pattern="%d{HH:mm:ss.SSS} %c %l %-5level - %msg%n"/>

Che risulterà in un messaggio di log come questo:

17:24:01.710 com.sematext.blog.logging.Log4j2 com.sematext.blog.logging.Log4j2.main(Log4j2.java:12) INFO - This is the first INFO level log message!

Java Logging in Containers

Pensa all’ambiente in cui la tua applicazione verrà eseguita. C’è una differenza nella configurazione del logging quando stai eseguendo il tuo codice Java in una VM o su una macchina bare-metal, è diverso quando lo esegui in un ambiente containerizzato e, naturalmente, è diverso quando esegui il tuo codice Java o Kotlin su un dispositivo Android.

Per impostare il logging in un ambiente containerizzato devi scegliere l’approccio che vuoi adottare. Puoi usare uno dei driver di log forniti – come journald, logagent, Syslog, o file JSON. Per farlo, ricordate che la vostra applicazione non dovrebbe scrivere il file di log nella memoria effimera del contenitore, ma nell’output standard. Questo può essere fatto facilmente configurando il vostro framework di log per scrivere il log sulla console. Per esempio, con Log4J 2 dovresti semplicemente usare la seguente configurazione dell’appender:

<Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout pattern="%d{HH:mm:ss.SSS} - %m %n"/> </Console></Appenders>

Puoi anche omettere completamente i driver di log e spedire i log direttamente alla tua soluzione di log centralizzata come il nostro Sematext Cloud:

<Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout pattern="%d %level %c - %m%n"/> </Console> <Syslog name="Syslog" host="logsene-syslog-receiver.sematext.com" port="514" protocol="TCP" format="RFC5424" appName="11111111-2222-3333-4444-555555555555" facility="LOCAL0" mdcId="mdc" newLine="true"/></Appenders>

Non registrare troppo o troppo poco

Come sviluppatori tendiamo a pensare che tutto possa essere importante – tendiamo a marcare ogni passo del nostro algoritmo o codice aziendale come importante. D’altra parte, a volte facciamo il contrario – non aggiungiamo il logging dove dovremmo o registriamo solo i livelli di log FATAL ed ERROR. Entrambi gli approcci non vanno molto bene. Quando scrivete il vostro codice e aggiungete i log, pensate a cosa sarà importante per vedere se l’applicazione funziona correttamente e cosa sarà importante per essere in grado di diagnosticare uno stato sbagliato dell’applicazione e correggerlo. Usate questo come luce guida per decidere cosa e dove registrare. Tenete a mente che aggiungere troppi log finirà con l’affaticare le informazioni e non avere abbastanza informazioni porterà all’incapacità di risolvere i problemi.

Tenete a mente il pubblico

Nella maggior parte dei casi, non sarete l’unica persona a guardare i log. Ricordatelo sempre. Ci sono più attori che possono guardare i log.

Lo sviluppatore può guardare i log per la risoluzione dei problemi o durante le sessioni di debug. Per queste persone, i log possono essere dettagliati, tecnici e includere informazioni molto profonde relative al funzionamento del sistema. Una tale persona avrà anche accesso al codice o addirittura conoscerà il codice e si può supporre che.

Poi ci sono i DevOps. Per loro, gli eventi di log saranno necessari per la risoluzione dei problemi e dovrebbero includere informazioni utili nella diagnostica. Si può assumere la conoscenza del sistema, la sua architettura, i suoi componenti e la configurazione dei componenti, ma non si dovrebbe assumere la conoscenza del codice della piattaforma.

Infine, i log dell’applicazione possono essere letti dagli utenti stessi. In tal caso, i log dovrebbero essere abbastanza descrittivi per aiutare a risolvere il problema, se è possibile, o dare abbastanza informazioni al team di supporto che aiuta l’utente. Per esempio, usare Sematext per il monitoraggio comporta l’installazione e l’esecuzione di un agente di monitoraggio. Se siete dietro un firewall molto restrittivo e l’agente non può spedire metriche a Sematext, registra gli errori mirati che gli stessi utenti di Sematext possono guardare.

Potremmo andare oltre e identificare ancora più attori che potrebbero guardare nei log, ma questa breve lista dovrebbe darti un’idea di ciò a cui dovresti pensare quando scrivi i tuoi messaggi di log.

Evitare di registrare informazioni sensibili

Le informazioni sensibili non dovrebbero essere presenti nei log o dovrebbero essere mascherate. Password, numeri di carte di credito, numeri di previdenza sociale, token di accesso, e così via – tutto ciò può essere pericoloso se trapelato o accessibile da coloro che non dovrebbero vederlo. Ci sono due cose da considerare.

Pensa se le informazioni sensibili sono veramente essenziali per la risoluzione dei problemi. Forse invece di un numero di carta di credito, è sufficiente conservare le informazioni sull’identificatore della transazione e la data della transazione? Forse non è necessario tenere il numero di previdenza sociale nei registri quando si può facilmente memorizzare l’identificatore dell’utente. Pensate a queste situazioni, pensate ai dati che memorizzate, e scrivete dati sensibili solo quando è veramente necessario.

La seconda cosa è spedire i log con informazioni sensibili a un servizio di log ospitato. Ci sono pochissime eccezioni in cui il seguente consiglio non dovrebbe essere seguito. Se i vostri log hanno e devono avere informazioni sensibili memorizzate, mascherateli o rimuoveteli prima di inviarli al vostro negozio di log centralizzato. La maggior parte degli shipper di log più diffusi, come il nostro Logagent, includono funzionalità che consentono la rimozione o il mascheramento dei dati sensibili.

Infine, il mascheramento delle informazioni sensibili può essere fatto nel framework di log stesso. Vediamo come può essere fatto estendendo Log4j 2. Il nostro codice che produce eventi di log appare come segue (l’esempio completo può essere trovato su Sematext Github):

public class Log4J2Masking { private static Logger LOGGER = LoggerFactory.getLogger(Log4J2Masking.class); private static final Marker SENSITIVE_DATA_MARKER = MarkerFactory.getMarker("SENSITIVE_DATA_MARKER"); public static void main(String args) { LOGGER.info("This is a log message without sensitive data"); LOGGER.info(SENSITIVE_DATA_MARKER, "This is a a log message with credit card number 1234-4444-3333-1111 in it"); }}

Se si dovesse eseguire l’intero esempio da Github l’output sarebbe il seguente:

21:20:42.099 - This is a log message without sensitive data21:20:42.101 - This is a a log message with credit card number ****-****-****-**** in it

Si può vedere che il numero della carta di credito è stato mascherato. Questo è stato fatto perché abbiamo aggiunto un convertitore personalizzato che controlla se il dato marcatore è passato lungo l’evento di log e cerca di sostituire un modello definito. L’implementazione di tale convertitore appare come segue:

@Plugin(name = "sample_logging_mask", category = "Converter")@ConverterKeys("sc")public class LoggingConverter extends LogEventPatternConverter { private static Pattern PATTERN = Pattern.compile("\b({4})-({4})-({4})-({4})\b"); public LoggingConverter(String options) { super("sc", "sc"); } public static LoggingConverter newInstance(final String options) { return new LoggingConverter(options); } @Override public void format(LogEvent event, StringBuilder toAppendTo) { String message = event.getMessage().getFormattedMessage(); String maskedMessage = message; if (event.getMarker() != null && "SENSITIVE_DATA_MARKER".compareToIgnoreCase(event.getMarker().getName()) == 0) { Matcher matcher = PATTERN.matcher(message); if (matcher.find()) { maskedMessage = matcher.replaceAll("****-****-****-****"); } } toAppendTo.append(maskedMessage); }}

È molto semplice e potrebbe essere scritto in modo più ottimizzato e dovrebbe anche gestire tutti i possibili formati di numero di carta di credito, ma è sufficiente per questo scopo.

Prima di saltare nella spiegazione del codice vorrei anche mostrarvi il file di configurazione log4j2.xml per questo esempio:

<?xml version="1.0" encoding="UTF-8"?><Configuration status="WARN" packages="com.sematext.blog.logging"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout pattern="%d{HH:mm:ss.SSS} - %sc %n"/> </Console> </Appenders> <Loggers> <Root level="info"> <AppenderRef ref="Console"/> </Root> </Loggers></Configuration>

Come potete vedere, abbiamo aggiunto l’attributo packages nella nostra configurazione per dire al framework dove cercare il nostro convertitore. Poi abbiamo usato il pattern %sc per fornire il messaggio di log. Lo facciamo perché non possiamo sovrascrivere il pattern predefinito %m. Una volta che Log4j2 trova il nostro pattern %sc userà il nostro convertitore che prende il messaggio formattato dell’evento di log e usa una semplice regex e sostituisce i dati se è stato trovato. Semplice come quello.

Una cosa da notare qui è che stiamo usando la funzionalità Marker. L’abbinamento delle righe è costoso e non vogliamo farlo per ogni messaggio di log. Ecco perché contrassegniamo gli eventi di log che dovrebbero essere elaborati con il marcatore creato, così solo quelli contrassegnati vengono controllati.

Utilizzare una soluzione di gestione dei log per centralizzare &monitorare i log di Java

Con la complessità delle applicazioni, anche il volume dei vostri log crescerà. Potreste cavarvela con la registrazione in un file e usare i log solo quando è necessario risolvere i problemi, ma quando la quantità di dati cresce diventa rapidamente difficile e lento risolvere i problemi in questo modo Quando questo accade, considerate l’uso di una soluzione di gestione dei log per centralizzare e monitorare i vostri log. Potete optare per una soluzione in-house basata su software open-source, come Elastic Stack o utilizzare uno degli strumenti di gestione dei log disponibili sul mercato come Sematext Logs.

Una soluzione di centralizzazione dei log completamente gestita vi darà la libertà di non dover gestire un’altra parte, solitamente piuttosto complessa, della vostra infrastruttura. Invece, sarete in grado di concentrarvi sulla vostra applicazione e dovrete impostare solo la spedizione dei log. Potreste voler includere i log come i log della JVM garbage collection nella vostra soluzione di log gestita. Dopo averli attivati per le vostre applicazioni e sistemi che lavorano sulla JVM, vorrete aggregare i log in un unico posto per la correlazione dei log, l’analisi dei log e per aiutarvi a regolare la garbage collection nelle istanze della JVM. Tali log correlati con le metriche sono una fonte inestimabile di informazioni per la risoluzione dei problemi relativi alla garbage collection.

Se siete interessati a vedere come Sematext Logs si confronta con soluzioni simili, andate al nostro articolo sui migliori software di gestione dei log o al post del blog dove esaminiamo alcuni dei migliori strumenti di analisi dei log, ma vi consigliamo di utilizzare la prova gratuita di 14 giorni per esplorare completamente le sue caratteristiche. Provatelo e vedrete voi stessi!

Conclusione

Integrare ogni buona pratica può non essere facile da implementare subito, specialmente per le applicazioni che sono già in produzione. Ma se ci si prende il tempo necessario e si distribuiscono i suggerimenti uno dopo l’altro, si inizierà a vedere un aumento dell’utilità dei propri log. Per ulteriori suggerimenti su come ottenere il massimo dai vostri log, vi consigliamo di leggere anche il nostro altro articolo sulle best practice di logging dove spieghiamo i pro e i contro che dovreste seguire indipendentemente dal tipo di app con cui state lavorando. E ricordate che noi di Sematext aiutiamo le organizzazioni con le loro configurazioni di log offrendo consulenza in materia, quindi contattateci se avete problemi e saremo felici di aiutarvi.

Condividi