Registrazione, lo fai? [chiuso]

Per qualsiasi programma / sistema di complessità sufficiente, la registrazione è assolutamente vitale. Ciò diventa particolarmente vero quando il dispositivo, l'applicazione, ecc. Possono essere installati e utilizzati in ambienti dispari o in combinazione con fornitori di servizi sui quali si ha un controllo scarso o assente (ad es. Telecom, provider "cloud", ...).

In un sistema complesso, potrebbe essere impossibile testare o qualificare ogni possibile scenario per ogni versione del tuo codice. In un sistema su cui stava lavorando il nostro team, abbiamo elencato oltre 15.000 casi d'uso separati. Per quanto intelligenti pensino di essere ("Preferisco non scrivere bug"), non coprirai mai tutti i casi possibili con la certezza perfetta che nient'altro è stato influenzato da cambiamenti apparentemente minori.

La registrazione fornisce i mezzi per rilevare le condizioni di errore e, cosa ancora più importante, che cosa ha portato all'esercitazione della condizione di errore.

Al momento del rilascio, i livelli di registro dovrebbero essere impostati in modo tale che solo i messaggi più importanti vengano registrati, ma tale soglia dovrebbe essere facilmente configurabile in modo che un cliente che presenta problemi possa abbassare tale valore e fornire maggiori dettagli a coloro che supportano il prodotto. Allo stesso modo, è importante che il tuo sistema sia responsabile della pulizia del suo pasticcio - assicurati di utilizzare il sistema di log del sistema sottostante ( syslog o SNMP ) o scrivi il tuo in modo che i tuoi file di log non travolgano l'host riempiendo i dischi e così via.

Preferirei non scrivere bug, ma siamo tutti umani, e più persone aggiungi a un progetto più diventa complesso. Se stai costruendo qualcosa che potrebbe alla fine diventare grande e / o complesso, ottenere presto un sistema di registrazione decente. Sarai grato per questo più tardi.

Lavoro in un ambiente in cui non possiamo aspettarci che gli errori siano riproducibili o in grado di collegare un debugger al programma.

Questo ha portato a uno stile di programmazione molto difensivo, in cui fondamentalmente registriamo un sacco di cose al livello più basso, che viene poi abilitato quando ci si aspetta problemi o siamo in una fase di test. Il successivo livello di registro superiore è molto meno dettagliato ed è sufficiente per vedere che l'elaborazione è in corso e che cosa viene elaborato. Questo è il livello per una produzione stabile.

Per Java è anche necessario rendere le tracce dello stack il più eloquenti possibile poiché si tratta di una singola unità che può contenere un lotto di informazioni. Mediante l'acquisizione e il wrapping appropriati in una nuova eccezione con le informazioni sull'ambiente di esecuzione, è possibile visualizzare parametri, nomi di file completi, valori di iteratore, ecc. Ma vederli solo quando qualcosa va storto. Questo è forse il più potente meccanismo post-mortem disponibile oggi.

Quindi prima di tutto lavoro su sistemi embedded su larga scala non piccoli che non hanno memoria né strumenti, anche se ho lavorato anche su quelli. Fondamentalmente lavoro su qualcosa che assomiglia a un server ma non lo è. Ecco gli usi e i motivi per l'utilizzo dei registri:

• Con molti molti sistemi sul campo raramente, se mai, puoi collegare un debugger in modo che una storia di come sei arrivato dove sei sia inestimabile.
• Spesso non puoi avere un debugger su tutti i tuoi sistemi in prova, quindi la storia è importante.
• Alcune cose che un debugger non può veramente catturare come il sistema funziona nel tempo. Ci sono cose che accadono che non sono bug ma devi essere consapevole e potenzialmente fare qualcosa per.
• Se oggi portassi via il tuo debugger, come risolverebbe un problema? Penso che i debugger siano grandi ma non sempre lo strumento migliore per il problema. È utile avere più di 1 strumento nella casella degli strumenti.
• Raccolta dei modelli di utilizzo.
• Lavorare su più sistemi che interagiscono costantemente tra loro. Un debugger rende molto difficile il logging, purché tu abbia una sorgente di tempo comune, rendendo molto facile legare insieme queste cose.
• Lavorare su qualcosa che è in tempo reale e non è possibile fermare la CPU perché ciò provocherebbe che tutto il resto intorno a modificare il loro comportamento.

Uso la registrazione abbastanza spesso, soprattutto per le applicazioni che dipendono strongmente dalle risorse non gestite di cui ho un controllo minore (ad esempio l'I / O di rete) e per le applicazioni che è difficile eseguire correttamente il debug da Visual Studio. Ci sono anche cose che potresti voler accedere all'ambiente di produzione che non puoi registrare solo attraverso il debug, come attività dell'utente, occorrenze / eccezioni impreviste, ecc.

Ad esempio, sul lavoro di recente ho scritto un'applicazione per il trasferimento dei dati. Ho dovuto trovare un modo per trasferire i dati da un server esterno che controllo a un server all'interno di una rete governativa che controllo. Grandi quantità di dati devono essere trasferiti ogni giorno. Ho esposto i dati esterni sviluppando alcuni servizi Web per il server esterno. Quindi ho scritto un'applicazione che è pianificata per essere eseguita periodicamente sul server interno. Il server interno passa le informazioni di autenticazione e le richieste di dati specifici al server esterno tramite le intestazioni SOAP. Il server esterno restituisce quindi i dati serializzati su HTTPS tramite XML. Perché c'è una grande quantità di dati coinvolti qui, il fatto che abbiamo un obbligo contrattuale di mantenere i dati aggiornati e disponibili sulla rete governativa, e per il fatto che sto facendo affidamento su reti ISP che ho poco da nessun controllo, ho bisogno di essere in grado di registrare ciò che accade con i trasferimenti di dati in modo che io possa risolvere i problemi. Il software di trasferimento dati conserva i propri registri e registra anche gli eventi sul visualizzatore eventi per il server. Quindi espongo questi dati tramite un sito Web intranet in modo da poter controllare rapidamente lo stato e la salute del sistema di trasferimento dati e del database interno.

Uso anche la registrazione per scopi di sicurezza nelle mie applicazioni di produzione. Alcune delle mie app Web registrano l'attività degli utenti, ad esempio, e la maggior parte delle mie app web registrerà eventuali eccezioni incontrate in un database SQL Server in modo da poter rilevare e correggere rapidamente i bug.

Un altro scenario in cui ho utilizzato di recente la registrazione era quando avevo bisogno di installare rapidamente alcune routine di gestione degli eventi sul nostro server SharePoint. Non ho avuto il tempo di creare un ambiente virtualizzato adatto per sharepoint o un server di test. Ho aggiunto SharePoint.dll a un progetto e ho scritto il codice, l'ho letto meticolosamente e verificato che fosse compilato, ma non avevo l'ambiente adatto per eseguire effettivamente il codice e collegarlo a un debugger. Quindi, mentre stavo sviluppando l'applicazione, installavo periodicamente gli assembly in GAC sul server e li registravo con sharepoint utilizzando un'utilità interna che ho scritto. Ho avuto i gestori di eventi scrivere un sacco di informazioni sul visualizzatore di eventi sul server in modo che potessi vedere che si sono registrati con SharePoint e funzionavano correttamente.

Penso di aver lavorato su alcuni progetti di InfoPath prima di dove un paio di loro non potevano essere collegati a un debuger per qualsiasi motivo. Penso che in quel caso ho semplicemente avvolto le direttive del pre-processore di DEBUG attorno a certe parti del codice mentre eseguivo il debug e la risoluzione dei problemi, in modo che si aprissero le messagebox per farmi sapere cosa stava succedendo. Sono sicuro che l'abbiamo già fatto prima. Questo è fondamentalmente il modo in cui eseguo il debug di javascript (con le caselle di avviso che commenterò più tardi, lol).

Per quanto riguarda le pratiche comuni ... una cosa che faccio sempre in tutte le mie classi .NET è l'override di ToString (). La sostituzione di My ToString () in genere restituisce tutti i dati importanti dello stato per il mio tipo (proprietà e campi membro, ecc.). Questo è utile per molte ragioni, e la registrazione è certamente una di queste. Se stai cercando di rintracciare un problema o di tenere traccia delle cose nell'ambiente di produzione, puoi sfruttare molto ToString () per registrare una stampa di uno stato di tipi in un dato momento.

Puoi utilizzare la classe EventLog in System.Diagnostics se sei uno sviluppatore .NET per scrivere direttamente nel registro eventi del sistema se il tuo codice ha le autorizzazioni appropriate. È inoltre possibile utilizzare System.Diagnostics.Debug e System.Diagnostics.Trace per scopi di registrazione. Trace è utile perché puoi scrivere direttamente nella finestra di output in Visual Studio che va di pari passo con il debugging. È inoltre possibile creare contatori delle prestazioni personalizzati per la propria applicazione da utilizzare con lo snap-in MMC Performance Monitor in Windows. In riferimento alla tua domanda, puoi vedere che Microsoft considera la registrazione come un requisito comune per un determinato peice di software, infatti molte, se non la maggior parte delle loro applicazioni, impiegano qualche tipo di registrazione.

Quindi per rispondere alla tua domanda, sì, la registrazione può essere molto utile ed è in effetti molto comune.

Ho usato la registrazione come metodo di tracciamento di controllo di basso livello per un webservice. Ogni richiesta ricevuta è stata registrata in un file con una piccola registrazione delle azioni intraprese, ecc. I file di registro sono stati periodicamente eliminati dai processi pianificati. Ho trovato questo utile per identificare i problemi con i dati di altre persone che sono stati inviati e inizialmente ha contribuito a risolvere eventuali problemi / casi che non avevo scritto.

Se dovessi suggerire degli standard intorno alla registrazione probabilmente suggerirei di essere coerente con le colonne di output e le informazioni standard in quanto ciò potrebbe essere di aiuto per l'analisi di massa o per la ricerca, se necessario più avanti nella traccia.

Mi piace la registrazione, le regole di log4net, qui ci sono varie cose per cui l'ho usato.

• Tracciare il codice multi-thread e identificare gli errori di temporizzazione
• Dimostrare ai clienti che la funzionalità è completa alla fine di uno sprint anche quando non esiste un'interfaccia utente
• Per verificare in modo selettivo la funzionalità dei diversi componenti
• Reindirizzare l'output del registro a qualcosa come Growl in modo che possa vedere i messaggi interni in tempo reale.
• Per costringermi a pensare in termini di ciò che un imprenditore potrebbe voler vedere in un log (non molto nel logging "inserisci metodo, esci messaggi di metodo", uno strumento di tracciamento e un rewriter di IL possono farlo.
• Generare un log di controllo (anche se preferirei qualcosa di simile al sourcing di eventi per questo)

Come strumento di debug - mai. Preferisco non scrivere bugs in primo luogo. Ma se stai scrivendo un server di borsa transazionale multi-threaded (o qualcosa di simile), dove le attività di ALTRE PERSONE possono causare problemi, allora un log è utile nel gioco della colpa.

Quindi registra gli input esterni, le transazioni e le uscite, ma nulla sotto quel livello, altrimenti i log diventano incomprensibili e rallentano troppo.

Ho usato la registrazione alcune volte. Ho avuto un bug una volta che poteva essere riprodotto solo sulla macchina di un utente con i suoi dati. Non c'è modo di collegare un debugger e vedere cosa sta succedendo, quindi ho inserito alcune dichiarazioni di registrazione su dove pensavo si stesse verificando il problema, ho inviato la build a loro, ho ottenuto i risultati, inserito più logging dove il log indicava l'errore stava succedendo per restringerlo ulteriormente, e così via. Dopo 4 o 5 iterazioni di questo la natura del bug è diventata ovvia e sono stato in grado di risolverlo.

Scrivo codice per i miei requisiti funzionali. Se i requisiti includono la registrazione, scrivo la registrazione. Se non lo fanno, non includo funzionalità non documentate. Se sto facendo qualcosa che non richiede la registrazione e sento davvero che dovrebbe quindi parlare con il PM. Potrebbero esserci motivi commerciali per accedere o meno.

Sì, lo trovo molto utile per diversi tipi di cose:

• Lavorare con file di dati molto grandi. Quando stai cercando di vedere cosa viene interpretato erroneamente in un input da 30 GB per far sì che alcuni stati cambino e il programma per andare a sud, colpire lo stesso breakpoint un milione di volte non è un'opzione.
• Lavorare con il codice di rete. Se ti siedi per un paio di minuti fissando un debugger e rimuginando su cosa sta succedendo, la connessione si interromperà.
• Trattare con codice complesso scritto da qualcun altro. Molte volte, un cliente vorrà una correzione di bug ieri, e non c'è davvero tempo per diventare un esperto o fare qualcosa di più di un cerotto. Nel codice skanky, qualsiasi numero di cose stupide potrebbe portare a un dato bug; registrando il diavolo dalle cose spesso ti dirò che cosa stupida sta portando al tuo particolare bug.
• Trasformando i dati binari intermedi in qualcosa di più leggibile da un debugger.
• Lavorando su sistemi embedded, dove si compila su un desktop e si trasferiscono i binari sull'hardware di destinazione, e l'hardware di destinazione non ha un debugger.

Sono abbastanza sorpreso di sapere che tutti non usano la registrazione per il debug. Se non utilizzi la registrazione per il debug, rispondi alla domanda: "Come fai a capire cosa è andato storto quando l'utente ti dice che stavo eseguendo attività X e poi il sistema si è bloccato, ma non sanno veramente cosa hanno fatto e di Ovviamente non è possibile duplicare il problema "O" Quando i bug sono intermittenti e possono accadere o meno per settimane o mesi ".

Suppongo che se non sei debitore della qualità del tuo cliente, allora sarebbe giusto soffiare il problema, ma quando il tuo contratto richiede di risolvere i problemi, allora non vedo nessun altro modo per dare correzioni tempestive a oscuri problemi diversi dall'utilizzo dei file di registro.

Il motivo principale per cui ho utilizzato la registrazione è il punto in cui semplicemente non posso fidarmi degli utenti di fornire dettagli accurati su cosa stavano facendo quando si è verificato l'errore.

Se ho i log, praticamente ho solo bisogno di chi erano e quando è stato e posso andare a vedere quello che stavano effettivamente facendo, non quello che pensano di fare.

Dato che il nostro prodotto è utilizzato da utenti in gran parte non tecnici, questo è praticamente tutto il tempo.

Definire cosa registrare è tuttavia difficile ed è in gran parte un processo evolutivo. Si effettua una prima pugnalata ragionevole e poi si migliora man mano che particolari codice / aree risultano problematiche. Assumere il tuo vantaggio dai risultati dei test del sistema può essere d'aiuto in quanto sono chiaramente indicativi di problemi reali che sono stati osservati - sì, potrebbero essere stati risolti nei miei problemi di esperienza attorno a determinate funzioni e codice (di solito a causa della complessità) quindi se hai riscontrato un problema in un'area suggerisco che è più probabile che ci siano ulteriori problemi lì che in qualche luogo casuale.

Una cosa che registrerei sempre: tutto input e output per qualsiasi integrazione con sistemi di terze parti. La prima cosa che l'altro fornitore chiede quando sollevi un problema.