Non ho mai scritto programmi che facciano un uso significativo del logging. Il più che ho fatto è quello di acquisire tracce dello stack quando si verificano eccezioni.
Mi stavo chiedendo, quanti altri utenti registrano? Dipende dal tipo di applicazione che stai scrivendo? Trovi i log effettivamente utili?
Per il lavoro ho fatto applicazioni in gran parte incorporate, registrando uno strumento inestimabile. Gli errori devono essere registrati al minimo con informazioni sufficienti per puntare alla riga di codice. Successivamente, sarebbero i principali punti di funzione attraverso 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 lo sviluppatore. Può essere utilizzato per assistere lo sviluppatore durante il test della funzionalità o potrebbe essere utile per diagnosticare un problema con il cliente.
Ho utilizzato personalmente l'accesso a 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 mai (raramente) i loro casi d'uso a quelli contro cui si prova.
Non penso che dipenda dal tipo di applicazione: la registrazione è utile nelle applicazioni tutte (non banali). Certo, immagino, può essere più utile in alcune applicazioni rispetto ad altre, ma non penso che sia mai inutile .
In particolare, in caso di errore, una traccia dello stack ti dirà lo stato del programma nel punto esatto esatto , ma hai ben poco indizio sullo stato < em> appena precedente all'errore. Tale informazione potrebbe essere molto utile per rintracciare il problema, e la registrazione può fornire utili informazioni in merito. Penso che sia qualcosa di cui possono beneficiare tutti i più banali dei programmi.
Un altro uso della registrazione, che potrebbe non essere utile per tutti i programmi, è l'analisi delle statistiche. Ad esempio, il tuo server web registra di solito ogni richiesta che arriva, e poi ci sono molti strumenti che possono analizzare quei log e produrre grafici dei tuoi periodi più trafficati, 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 tratterò più il punto. Dirò solo che dovresti pensare strongmente a cosa succede se c'è un errore nel registro? Ti importa abbastanza di lanciare un'eccezione attraverso l'app o gestirla in un altro modo? Questo è un "dipende", ma i messaggi a livello di informazioni di log dovrebbero essere saltati.
La registrazione di controllo è un requisito aziendale. La registrazione di audit acquisisce eventi significativi nel sistema e sono interessati a ciò che sono interessati alla gestione e alle aquile legali. Sono cose come chi ha firmato qualcosa, chi ha fatto le modifiche, ecc. Come amministratore di sistema o sviluppatore che risolve il problema, probabilmente stai solo moderatamente interessati a questi. Tuttavia, in molti casi questo tipo di registrazione è 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 dei requisiti, potrei effettivamente aver bisogno di implementarli separatamente. Può essere un caso (a volte) che siano entrambi frutto, ma uno è mele e le altre arance. Di solito, un singolo framework di registrazione può gestire entrambi però.
Nella maggior parte delle attività del server, la registrazione è cruciale, dato che l'amministratore di solito non è presente quando le cose accadono, quindi deve controllare il dopo-fatto.
Tuttavia, un ragazzo di Google mi ha detto una volta che i loro processi server non eseguivano la registrazione; al contrario, sono "strumentati"; ciò significa che ogni processo ha ganci o porte (non ha specificato la meccanica) dove altri processi possono attaccarsi per chiedere parametri e statistiche. Sono i processi di monitoraggio che memorizzano molte cose nei log, il vantaggio è che l'informazione che ricevono non è "apri un file", "scrivi questo", "recupera quello"; ottengono cose come "45.453 file aperti", "653 client di servizio X", "344 ms risposta media per query Y"
Certamente è un approccio diverso, che tendo a tenere a mente mentre faccio da babysitter ai miei sistemi, anche se sono di qualche ordine di grandezza più piccoli.
Sono venuto da una winforms N-Tiered che registrava tutto.
Non è stato molto utile.
Certo, le eccezioni di registrazione sono grandi; ma perché registrarli sul computer del cliente quando puoi semplicemente inviare un'e-mail all'eccezione al team di sviluppo?
Le informazioni di registrazione si trasformano facilmente in una dipendenza il cui valore è raramente giustificato. Per ogni situazione in cui è possibile accedere gratuitamente, è meglio raccogliere informazioni mirate e inviarle dove ne avete bisogno.
Acquisire informazioni sulle eccezioni è un must perché può essere molto utile in una certa misura. Ma a volte le informazioni sulle eccezioni non sono sufficienti, specialmente se l'utente / client dell'applicazione non è in grado di segnalare un errore con informazioni corrette.
La registrazione è limitata solo alla cattura delle informazioni di errore?
Nel mio caso (applicazione web), registro sempre quale pagina viene visitata, quando, cosa fanno clic, dove l'ip & browser, ecc. Registro persino il tempo di caricamento totale per ogni visita di pagina, così posso sapere quali pagine sono lente e necessitano di ottimizzazione. quindi posso dire che registro il più possibile.
all'inizio, non avevo idea di quanto sia significativo. ma a quanto pare è molto utile in molte cose (tranne il debugging):
Penso che il logging possa diventare più significativo se amiamo scavare informazioni statistiche in esso.
Sono uno sviluppatore di un'azienda i cui prodotti sono distribuiti all'estero. Quando un gruppo di supporto arriva chiedendo una definizione del problema, i miei unici strumenti per la diagnosi sono i miei file di registro e una copia del database del cliente. Usando il database e il mio ambiente di sviluppo, ho l'opportunità di riprodurre il caso errato, perché registro i dati in arrivo nel mio modulo e le azioni correlate. Se riesco a riprodurre l'errore con l'aiuto dei dati raccolti, posso correggerlo con il debug. Se non avessi file di registro, allora dovrei dipendere dalla descrizione del cliente o del team di supporto su cosa succede in quel caso (che ha una grande possibilità di fuorviare).
In secondo luogo, il logging mi dà la possibilità di rilevare i colli di bottiglia del mio modulo sul sito distribuito, dal momento che registro la data e l'ora di determinate azioni e quindi posso dare un'occhiata a quale azione consuma quanto tempo.
In aggiunta a ciò, supponiamo che la nostra soluzione sia composta da 6 moduli e che visualizzi i log degli errori nei miei file di registro sui timeout del database. Se questi errori vengono registrati anche in 5 degli altri moduli, la probabilità che si tratti di un problema relativo al server SQL aumenta. Se questo è registrato solo nel mio modulo, allora la probabilità che le mie query siano bacate aumenta. Penso che questo tipo di cose siano indicatori utili.
Informazioni sul 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 del livello di informazione, ecc ...
La registrazione è utile per le informazioni che non è possibile ottenere da altri programmi:
Nota: desideri 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 quello che hai è il file di registro, e farlo correttamente potrebbe essere la differenza tra essere licenziati e ottenere la promozione.
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 migliora in modo sostanziale lo stack delle chiamate con i valori dei parametri e potrebbe consentire di analizzare la situazione solo con la traccia dello stack e senza dover vedere i file di registro.
Raccomando anche a tutte le app non banali di utilizzare la registrazione multi-livello.
Per i motivi che altri hanno affermato, è uno strumento inestimabile per risolvere i problemi con l'applicazione.
In alcuni casi, la registrazione è essenziale, ad esempio in applicazioni finanziarie e altri domini che richiedono log delle attività, per sicurezza, metriche di utilizzo e controllo.
Dipende sicuramente dal tipo di sistema che stai costruendo.
Se stai scrivendo un'applicazione desktop autonoma, ad esempio un elaboratore di testi, probabilmente non hai bisogno di alcuna registrazione.
Se stai scrivendo un sistema embedded, non puoi vivere senza logging. Altrimenti, quando il dispositivo incorporato si blocca, non hai idea del perché. È inoltre necessario eseguire la registrazione ogni volta che il sistema coinvolge più processi o più macchine fisiche che comunicano tra loro. Ancora una volta, quando il sistema si blocca, è necessario sapere quale parte di essa è morta quando e perché. È necessario essere in grado di confrontare i registri per determinare se i dati lo hanno fatto o meno da un processo all'altro. Per lo stesso motivo, è necessario eseguire la registrazione ogni volta che si intende eseguire il sistema per periodi di tempo estesi senza molta interazione diretta dell'utente.
La registrazione è sempre utile. Ma quando si implementa sii consapevole che non è necessariamente te, chi leggerà i log. Forse è una sorta di amministratore, un utente finale, un cliente, un team di supporto, ...
Quindi non solo registra gli stacktraces, ma anche alcune informazioni aggiuntive che possono essere interpretate dai non sviluppatori. Quando la tua applicazione viene gestita da altri gruppi, è anche utile scrivere alcuni codici di errore univoci nei tuoi registri. Questo potrebbe facilitare il supporto, l'automazione, ...
Un altro punto dal punto di vista amministrativo: pensa alla rotazione del registro.
Leggi altre domande sui tag programming-practices logging