Non ho mai scritto programmi che fanno un uso significativo della registrazione. Il massimo che ho fatto è acquisire tracce dello stack quando si verificano eccezioni.
Mi chiedevo, quanto registrano gli altri? Dipende dal tipo di applicazione che stai scrivendo? Trovi i registri davvero utili?
Risposte:
Per il lavoro ho realizzato applicazioni per lo più integrate, registrando uno strumento prezioso. È necessario registrare almeno errori con informazioni sufficienti per puntare alla riga di codice. Successivamente, sarebbero i principali punti di funzione in tutta l'applicazione. Cose come l'amministratore hanno avuto accesso alla macchina. Utilizziamo un sistema che ci consente di abilitare una registrazione più dettagliata. Questo di solito è specifico per gli sviluppatori. Può essere utilizzato per assistere lo sviluppatore durante il test della funzione o può essere utile per diagnosticare un problema del cliente.
Ho usato personalmente la registrazione in tutte le applicazioni che ho sviluppato. Ha sempre portato a una migliore comprensione del flusso di un'applicazione. Soprattutto quando nelle mani di un cliente. Non limitano (raramente) i loro casi d'uso a quelli contro cui si esegue il test.
Non penso che dipenda dal tipo di applicazione: la registrazione è utile in tutte le applicazioni (non banali). Certamente, immagino, può essere più utile in alcune applicazioni rispetto ad altre, ma non penso che sia mai inutile .
In particolare, nel caso di un errore, una traccia dello stack ti dirà lo stato del programma nel punto esatto dell'errore, ma hai ben poco indizio sullo stato appena prima dell'errore. Tali informazioni potrebbero essere molto utili per rintracciare il problema e la registrazione può fornire un'utile comprensione di ciò. Penso che sia qualcosa di cui tutti, tranne il più banale, possono beneficiare.
Un altro uso della registrazione, che potrebbe non essere utile per tutti i programmi, è nell'analisi delle statistiche. Ad esempio, il tuo server Web in genere registra ogni richiesta che arriva, e quindi ci sono molti strumenti che possono analizzare quei registri e produrre grafici dei tempi più occupati, delle pagine più popolari e così via. È possibile utilizzare tali dati per pianificare la capacità ("ho bisogno di un server più grande?") E così via.
Esistono due motivi per cui viene eseguita la registrazione:
La registrazione diagnostica è già stata discussa da altri e non voglio approfondire ulteriormente il punto. Dirò solo che dovresti pensare fortemente a cosa succede se si verifica un errore nel registro? Ti interessa abbastanza per sollevare un'eccezione attraverso l'app o gestirla in un altro modo? Questo è un "dipende", ma probabilmente i messaggi di registrazione delle informazioni dovrebbero essere saltati.
La registrazione dei controlli è un requisito aziendale. La registrazione di controllo cattura eventi significativi nel sistema e sono ciò che interessa la gestione e le aquile legali. Queste sono cose come chi ha firmato qualcosa, chi ha fatto le modifiche, ecc. Come amministratore di sistema o sviluppatore che risolve il problema del sistema, probabilmente sei solo leggermente interessato a questi. Tuttavia, in molti casi questo tipo di registrazione fa assolutamente parte della transazione e dovrebbe fallire l'intera transazione se non può essere completata.
Pensare ai due separatamente è utile per me non solo perché uno è "facoltativo" e l'altro obbligatorio, ma perché, a seconda delle esigenze, potrebbe essere necessario implementarli separatamente. Può essere un caso (a volte) che siano entrambi frutti, ma uno sono le mele e le altre arance. Di solito, un singolo framework di registrazione può gestire entrambi.
Nella maggior parte delle attività del server la registrazione è cruciale, poiché l'amministratore di solito non è presente quando accadono le cose, quindi deve controllare dopo tutto.
Ma un ragazzo di Google mi ha detto una volta che i loro processi del server non eseguono il log; invece, sono "strumentati"; ciò significa che ogni processo ha hook o porte (non ha specificato la meccanica) in cui altri processi possono essere bloccati per richiedere parametri e statistiche. Sono quei processi di monitoraggio che memorizzano molte cose nei log, il vantaggio è che le informazioni che ottengono non sono "aprire un file", "scrivere questo", "recuperarlo"; ottengono cose come "45.453 file aperti", "653 client del servizio X", "344ms risposta media per query Y"
Certamente è un approccio diverso, e che tendo a tenere a mente mentre faccio da babysitter ai miei sistemi, anche se alcuni ordini di grandezza sono più piccoli.
Vengo da un'applicazione Win-form N-Tier che registra tutto.
Non è stato molto utile
Certo, la registrazione delle eccezioni è ottima; ma perché registrarli sul computer del cliente quando puoi semplicemente inviare l'eccezione al team di sviluppo?
La registrazione delle informazioni si trasforma facilmente in una dipendenza il cui valore è raramente giustificato. Per ogni situazione in cui è possibile accedere gratuitamente, è meglio raccogliere informazioni mirate e inviarle dove necessario per andare.
Catturare le informazioni sulle eccezioni è un must perché può essere molto utile in una certa misura. Ma a volte le informazioni sulle eccezioni non sono sufficienti, soprattutto se l'utente / client dell'applicazione non è in grado di segnalare un errore con le informazioni corrette.
La registrazione è limitata alla sola acquisizione di informazioni sull'errore?
Nel mio caso (applicazione web), registro sempre quale pagina viene visitata, quando, cosa fanno clic, dove ip e browser, ecc. Registro anche il tempo di caricamento totale per ogni visita di pagina, in modo da poter sapere quali pagine sono lente e necessita di ottimizzazione. quindi posso dire che accedo il più possibile.
all'inizio, non avevo idea di quanto sarà significativo. ma apparentemente è molto utile in molte cose (oltre al debug):
Penso che il logging possa diventare più significativo se amiamo scavare informazioni statistiche in esso.
Sono uno sviluppatore in un'azienda i cui prodotti sono distribuiti all'estero. Quando un team di supporto viene a chiedere una definizione del problema, i miei unici strumenti per la diagnosi sono i miei file di registro e una copia del database del cliente. Utilizzando il database e il mio ambiente di sviluppo, ho l'opportunità di riprodurre il caso errato, perché registro i dati in arrivo sul mio modulo e le azioni correlate. Se riesco a riprodurre l'errore con l'aiuto dei dati raccolti, posso risolverlo con il debug. Se non avessi i file di registro, dovrei dipendere dalla descrizione del cliente o del team di supporto su ciò che accade in questo caso (che ha una grande probabilità di fuorviare).
In secondo luogo, la registrazione mi dà la possibilità di rilevare i colli di bottiglia del mio modulo nel sito distribuito, poiché registro la data e l'ora di determinate azioni e quindi posso vedere quale azione consuma quanto tempo.
Inoltre, supponiamo che la nostra soluzione sia composta da 6 moduli e visualizzi i log degli errori nei miei file di log relativi ai timeout del database. Se questi errori vengono registrati anche in 5 degli altri moduli, aumenta la probabilità che si tratti di un problema relativo al server SQL. Se questo è registrato solo nel mio modulo, allora aumenta la probabilità che le mie domande siano buggy. Penso che questo tipo di cose siano indicatori utili.
Il tipo di dati che vedo nei miei file di registro dipende dalla configurazione del livello di registro. Se si tratta di un nuovo prodotto, impostiamo il livello di registro su "Tutti" per raccogliere quanti più dati possibile. Ma quando miglioriamo il prodotto, potremmo preferire mantenere il livello di registro su "Errore" per registrare solo l'errore, ma non i registri a livello di informazioni, ecc.
La registrazione è utile per le informazioni che non è possibile ottenere da altri programmi:
Nota: si desidera almeno DUE file di registro.
Quello INFO è sempre attivo. Il DEBUG è attivo quando necessario.
Scrivi il codice di registrazione anticipando che un giorno potresti dover eseguire il debug di una situazione in cui TUTTO ciò che hai è il file di registro e farlo correttamente potrebbe fare la differenza tra essere licenziato e promosso.
Per il miglio supplementare, tutte le chiamate di funzione aggiungono i loro parametri a qualsiasi traccia dello stack, in Java con
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
Questo approccio essenzialmente migliora lo stack di chiamate con i valori dei parametri e può consentire di analizzare la situazione solo con la traccia dello stack e di non dover vedere i file di registro.
Vorrei anche raccomandare che tutte le app non banali utilizzino la registrazione multi-livello.
Per le ragioni che altri hanno affermato, è uno strumento prezioso per risolvere i problemi con l'applicazione.
In alcuni casi, la registrazione è essenziale, ad esempio nelle applicazioni finanziarie e in altri domini che richiedono registri di attività, per la sicurezza, le metriche di utilizzo e il controllo.
Dipende sicuramente dal tipo di sistema che stai costruendo.
Se stai scrivendo un'applicazione desktop autonoma, come un elaboratore di testi, probabilmente non avrai bisogno di alcuna registrazione.
Se stai scrivendo un sistema incorporato, non puoi vivere senza registrarti. Altrimenti, quando il dispositivo incorporato si blocca, non hai idea del perché. È inoltre necessario effettuare la registrazione ogni volta che il sistema coinvolge più processi o più macchine fisiche in comunicazione tra loro. Ancora una volta, quando il sistema si blocca, devi sapere quale parte è morta quando e perché. È necessario essere in grado di confrontare i registri per determinare se i dati sono passati o meno da un processo all'altro. Allo stesso modo, è necessario effettuare la registrazione ogni volta che il sistema deve funzionare per lunghi periodi di tempo senza molta interazione diretta da parte dell'utente.
La registrazione è sempre utile. Durante l'implementazione, tieni presente che non sei necessariamente tu che leggerai i registri. Forse è una sorta di amministratore, un utente finale, un cliente, un team di supporto, ...
Quindi non solo registra stacktraces, ma anche alcune informazioni aggiuntive che possono essere interpretate da non sviluppatori. Quando l'applicazione è gestita da altri gruppi, è anche utile scrivere alcuni codici di errore univoci nei registri. Ciò potrebbe facilitare il supporto, l'automazione, ...
Un altro punto dal punto di vista dell'amministratore: pensa alla rotazione del registro.