it-swarm.it

Registrazione: perché e cosa?

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?

40
Winston Ewert

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 di aiuto nella diagnosi di 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.

24
Jeff

Non penso che dipenda dal tipo di applicazione: la registrazione è utile in tutte (non banali) applicazioni. Certamente, immagino, può essere più utile in alcune applicazioni rispetto ad altre, ma non credo che sia mai inutile.

In particolare, in caso di errore, una traccia dello stack ti dirà lo stato del programma nel punto esatto di errore, ma hai ben poco indizio sullo stato appena prima all'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.

19
Dean Harding

Esistono due motivi per cui viene eseguita la registrazione:

  1. Diagnostico
  2. Revisione

Diagnostic logging è già stato discusso da altri e non parlerò più del 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.

Audit logging è un requisito aziendale. La registrazione di controllo cattura eventi significativi nel sistema e sono ciò a cui la gestione e le aquile legali sono interessate. Si tratta di 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. In genere, tuttavia, un singolo framework di registrazione può gestirli entrambi.

9
MIA

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.

8
Javier

Vengo da un'applicazione Win-form di livello N 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.

4
George Stocker

Catturare 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):

  • comprendere il comportamento dell'utente
  • valutazione dell'accettazione di nuove funzionalità
  • distinguere tra i primi utenti, i truffatori o i potenziali clienti

Penso che il logging possa diventare più significativo se amiamo scavare informazioni statistiche in esso.

4
Anwar Chandra

Sono uno sviluppatore in un'azienda i cui prodotti sono distribuiti all'estero. Quando un team di supporto chiede 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 relative azioni. Se riesco a riprodurre l'errore con l'aiuto dei dati raccolti, posso ripararlo 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 registro 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 errate. 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.

2
aslisabanci

La registrazione è utile per le informazioni che non è possibile ottenere da altri programmi:

  • Cattura le tracce dello stack (ce l'hai quella)
  • Acquisisci i dati che venivano elaborati in caso di arresto anomalo dell'applicazione. Ricorda, i debugger aiutano solo se sono presenti quando si verifica l'incidente.
  • Informazioni sulla profilazione. Se non è possibile eseguire un profiler nell'ambiente di produzione, la registrazione estesa compresi i timestamp può aiutarti a capire dove è andato il tempo. Anche non essere in grado di dirlo potrebbe aiutarti a identificare che è al di fuori del tuo programma (es. Avvio della garbage collection).
  • Statistiche non attese durante la scrittura del programma. Mi è stato chiesto di fornire grafici di comportamento nel tempo per intervalli interessanti per altri motivi. I dati necessari potrebbero essere estratti dai file di registro con un po 'di trucchi ninp grep + awk + Perl.

Nota: si desidera almeno DUE file di registro.

  • Uno a livello di DEBUG - fornendo tutte le informazioni che puoi immaginare di cui avrai mai bisogno (incluse INFO e superiori). Se è troppo, allora considera di avere un livello TRACE aggiuntivo.
  • Uno a livello INFO: fornisce una panoramica del sistema di 10000 metri. Le pietre miliari importanti vanno qui.

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.

2
user1249

La registrazione è sempre utile. Ma quando si implementa sii consapevole 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.

1
Christian

Vorrei anche raccomandare che tutte le app non banali utilizzino la registrazione multi-livello.

Per i motivi 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.

1
ocodo

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 eseguire 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, è necessario 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.

1
Dima