Cosa registrare/tracciare in un ambiente di produzione

Question

Mi chiedo quale tipo di informazioni devono essere registrate su un file una volta che un'applicazione è stata spostata in un ambiente di produzione? Oltre alla registrazione di eccezioni ed errori ...

L'inizio e la fine di ciascun metodo devono essere registrati? L'inizio e la fine di un servizio in esecuzione? Ogni volta che l'applicazione salva i dati in un database o chiama un servizio esterno? Sto cercando di trovare l'equilibrio tra la registrazione/tracciamento di tutto e solo gli errori di registrazione.

Answer 1

E 'davvero dipende da voi, non ci sono duri & regole veloci.

paio di mesi fa ci stavamo lavorando su questa applicazione Java e utilizzato log4j per la registrazione, in log4j siamo stati in grado di definire nel codice nostri log sia come eseguire il debug, avviso, errore, ecc informazioni

nostra registrazione di debug era quasi su tutte le funzioni start & fine, ogni transazione di successo non riuscita è stata registrata come "info", "errore" in eccezioni sono stati registrati & allo stesso modo.

Dopo aver spostato l'applicazione nell'ambiente di produzione dopo circa un mese, abbiamo disattivato la registrazione di debug tramite i file .properties senza riavviare l'applicazione &, eravamo pronti.

Answer 2

Mi piace utilizzare diversi livelli. Il meno dettagliato mostra avvio e arresto di servizio, nonché errori ed eccezioni. Il più dettagliato potrebbe arrivare fino a mostrando il valore di ogni variabile locale, funzione entrata/uscita e così via.

Più dettagli si possono ottenere facilmente, meno scavo e meno probabilità si è di dover saltare su un aereo per andare dove il problema è. . . .

K

Answer 3

In un ambiente di produzione, la registrazione è impostata su "INFO" per impostazione predefinita (utilizzando log4net) ea questo livello registro informazioni sufficienti per avere una buona possibilità di diagnosticare eventuali errori. Quindi quali sono le informazioni "sufficienti"? Bene, tutto dipende dal tuo sistema. Nel nostro sistema registro i punti di ingresso e di uscita dai metodi più importanti, inclusi i loro parametri di input e valori di ritorno (a meno che non si tratti di molti dati). Sono disposto ad accettare un overhead del 5-10% per la registrazione (ma dovresti misurarlo).

mio formato di perferred è come questo: ingresso

Metodo:

-> MyMethod (1, "arg1")

Metodo di uscita:

< -MyMethod (1, " arg1 ") = true

Le frecce indicano che posso facilmente vedere se questa è entrata o uscita. Includendo gli argomenti e il valore restituito ottengo i dati più critici per la diagnosi degli errori. Ho sempre e solo un punto di ritorno dai miei metodi, quindi non devo preoccuparmi di più punti di uscita per la mia registrazione.

Con il metodo di registrazione entrata/uscita, trovo che non devo registrare molto altro, se il codice viene scomposto correttamente in metodi, questo documenterà il flusso di esecuzione attraverso l'applicazione.

Non commettete l'errore di non registrare abbastanza informazioni perché siete preoccupati per l'impatto sulle prestazioni - misurate questo in modo da essere soddisfatti del sovraccarico, ma siete sicuri che state registrando abbastanza per diagnosticare gli errori puramente basati sulle informazioni questo è nel registro. Quello che non si vuole fare è passare l'accesso a ulteriori dettagli dopo il il cliente ha segnalato un errore, quindi sperare che l'errore si ripresenti.

Uso anche un livello di registrazione DEBUG che registra praticamente tutto. Questo è usato solo in dev/test, o forse in produzione ma solo dopo aver consultato il cliente.