Domanda

Sfondo: ho ereditato un'applicazione Web che ha lo scopo di creare connessioni al volo tra apparecchiature locali e remote. Di recente c'è un numero incredibile di parti mobili: l'app stessa è cambiata in modo significativo; la toolchain di sviluppo è stata appena aggiornata; e sia le apparecchiature locali che quelle remote sono state "modificate" per supportare tali modifiche.

Il lato positivo è che ha un ragionevole sistema di registrazione che scriverà i messaggi di debug in un file e accederà sia al file che alla schermata dell'utente in tempo reale. Ho l'opportunità di rielaborare l'intero meccanismo di log / debug.

Esempi:

  • Tutti i messaggi sono timestamp e sono preceduti da un livello di gravità.
  • I registri sono per il cliente. Registrano le risposte del sistema alle sue richieste.
  • Qualsiasi registro che identifica un problema suggerisce anche una soluzione.
  • I debug sono per sviluppatori e supporto tecnico. Rivelano gli interni del sistema.
  • I debug indicano la funzione e / o la linea che li ha generati.
  • Il cliente può regolare il livello di debug al volo per impostare la verbosità.

Domanda: quali migliori pratiche hai utilizzato come sviluppatore o visto come un consumatore che genera log e debug utili?

Modifica: finora molti suggerimenti utili, grazie! Per chiarire: sono più interessato a cosa da registrare: contenuto, formato, ecc .-- e ai motivi per farlo - rispetto a strumenti specifici.

Che cosa è stato dei migliori log che hai visto che li hanno resi più utili?

Grazie per l'aiuto!

È stato utile?

Soluzione

La cosa assolutamente più preziosa fatta con qualsiasi framework di registrazione è un "1 clic". strumento che raccoglie tutti i log e me li spedisce anche quando l'applicazione è distribuita su una macchina appartenente a un cliente.

E fai delle buone scelte su cosa fare in modo da poter seguire approssimativamente i percorsi principali nella tua applicazione.

Come framework ho usato gli standard (log4net, log4java, log4c ++)

NON implementa il tuo framework di log, quando ce n'è già uno pronto all'uso. La maggior parte delle persone che reinventano la ruota.

Altri suggerimenti

Alcune persone non usano mai un debugger ma registrano tutto. Sono filosofie diverse, devi fare la tua scelta. Puoi trovare molti consigli come questi o questo . Nota che questi consigli non sono legati alla lingua ...

Coding Horror guy ottenuto un post interessante sul problema di registrazione e perché la registrazione abusiva potrebbe essere una perdita di tempo in alcuni condizioni.

Credo semplicemente che la registrazione sia per tracciare cose che potrebbero rimanere in produzione. Il debug è per lo sviluppo. Forse è un modo troppo semplice di vedere le cose, perché alcune persone usano i log per il debug perché non sopportano i debugger. Ma la modalità debugger può anche essere una perdita di tempo: non è necessario utilizzarlo come una sorta di test case, perché non è scritto e scompare dopo la sessione di debug.

Quindi penso che la mia opinione al riguardo sia:

  • registrazione delle tracce necessarie e utili attraverso ambienti di sviluppo e produzione, con livelli di sviluppo e produzione, con l'uso di un framework di log ( log4 strumenti della famiglia)
  • modalità di debug per casi strani speciali quando le cose vanno fuori controllo
  • i casi di test sono importanti e possono risparmiare tempo nelle sessioni di debug labirintiche infernali, utilizzate come metodo anti-regressione. Nota che la maggior parte delle persone non usa casi di test.

L'horror in codice ha detto che resiste alla tendenza a registrare tutto . Esatto, ma ho già visto un'app hudge che fa esattamente il contrario (e attraverso un database) ...

Non confondere la registrazione, la traccia e la segnalazione degli errori, alcune persone che conosco lo fanno e crea un inferno di un file di registro da sfogliare per ottenere le informazioni che voglio.

Se voglio che tutto sia sfornato, separo quanto segue:

  
      
  • Tracciamento - > Esegue il dump di ogni azione e passaggio, timestamp, con input e   dati di output di quello stadio (il più brutto e   file più grande)
    •   
  • Registrazione - > Registra solo le fasi del processo aziendale, il client esegue la richiesta, quindi registra   i criteri di richiesta e i dati di output   niente di più.
    •   
  • Segnalazione errori / Debug - > Eccezioni registrate in dettaglio dove si trova   si è verificato, timestamped, input / output   dati se possibile, informazioni dell'utente ecc.
    •   

In questo modo se si sono verificati errori e il registro Errori / Debug non contiene informazioni sufficienti per i miei gusti, posso sempre fare un grep -A 50 -B 50 'traccia' file 'timestamp' per ottenere di più dettagli.

Modifica Come è stato anche detto, attenersi ai pacchetti standard come il modulo di registrazione integrato per Python come esempio è sempre buono. Rotolare il tuo non è una grande idea a meno che il linguaggio non ne abbia uno nella sua libreria standard. Mi piace racchiudere la registrazione in una piccola funzione che generalmente prende il messaggio e il valore per determinare a quali registri va, ad es. 1 - traccia, 2 - registrazione, 4 - debug, quindi inviando un valore di 7 gocce a tutti e 3 ecc.

Vorrei solo impostare il tuo sistema di registrazione per avere più livelli di registrazione, sui servizi che scrivo ho una registrazione / verifica per quasi ogni azione ed è assegnato un livello di verifica 1-5 maggiore è il numero maggiore è il numero di eventi di verifica che ottieni .

  1. La registrazione di base: avvio, arresto e riavvio
  2. Registrazione di base: elaborazione x numero di file ecc.
  3. Registrazione standard: inizio all'elaborazione, elaborazione terminata, ecc.
  4. Registrazione avanzata: inizio e fine di ogni fase dell'elaborazione
  5. Tutto: ogni azione intrapresa

imposti il ??livello di controllo in un file di configurazione in modo che possa essere modificato al volo.

Alcune regole generali che ho trovato utili nelle applicazioni lato server:

  • requestID : assegna un ID richiesta a ciascuna richiesta (HTTP) in entrata, quindi esegui il log su ogni linea di registro, in modo da poter facilmente accedere a tali registri in seguito tramite tale ID e trovare tutte le linee pertinenti. Se ritieni che sia molto noioso aggiungere quell'ID a ogni istruzione di registro, almeno i framework di registrazione java lo hanno reso trasparente con l'uso di Contesto diagnostico mappato (MDC).
  • objectID : se l'applicazione / il servizio si occupa della manipolazione di alcuni oggetti business che dispongono di chiave primaria, è utile associare anche quella chiave primaria al contesto diagnostico. Più tardi, se qualcuno viene con la domanda "quando è stato manipolato questo oggetto?" puoi facilmente grep dall'oggetto objectID e vedere tutti i record di registro relativi a quell'oggetto. In questo contesto è (a volte) utile effettivamente utilizzare Contesto diagnostico nidificato invece di MDC .
  • quando accedere? - almeno dovresti effettuare l'accesso ogni volta che attraversi un importante confine di servizio / componente. In questo modo è possibile ricostruire in seguito il flusso di chiamate ed eseguire il drill-down fino alla particolare base di codice che sembra causare l'errore.

Dato che sono uno sviluppatore Java, darò anche la mia esperienza con le API e i framework Java.

API

Consiglio di usare Simple Logging Facade for Java (SLF4J) - nella mia esperienza, è la facciata migliore per la registrazione:

  • full optional: non ha seguito l'approccio minimo comune denominatore (come il log comune); invece usa l'approccio degrada con garbo .
  • ha adattatori per praticamente tutti i framework di registrazione Java più diffusi (ad esempio log4j)
  • ha soluzioni disponibili su come reindirizzare tutte le API di registrazione legacy (log4j, registrazione comune) su SLF4J

Implementazione La migliore implementazione da utilizzare con SLF4J è logback - scritta dallo stesso ragazzo che ha anche creato l'API SLF4J.

Utilizza un formato di registrazione esistente, come quello utilizzato da Apache, e puoi quindi trasferire sulle spalle i numerosi strumenti disponibili per l'analisi del formato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top