Suggerimenti e buone pratiche di registrazione delle applicazioni

Assumendo con il tempo in quanto aspetti come la sicurezza e i test devono essere presi in considerazione nel complesso Ciclo di vita del progetto, dalle sue origini al suo completamento. Che non sono requisiti non funzionali o non funzionali secondari, in caso contrario, se non sono prioritarie come parte della struttura fondamentale dell’applicatore (non sono così tanti funzionalità o meccanismi progettati e implementati il completamento del progetto come aggiunta , se fossero finiti). Tuttavia, la traccia di applicazione, ancora avendo reso il merito, non ha ricevuto in molti casi la stessa considerazione; – P.

In questo post non penso di scoprire nulla di nuovo a coloro che hanno esperienza nello sviluppo . L’idea è di esercitare sintesi e revisione per riassumere cosa, a mio avviso, sono le migliori o buone pratiche del registro dell’applicazione. Naturalmente, contributi, osservazioni, sfumature e critiche sono i benvenuti; Ti invito a unirti a questo esercizio.

Il registro o la traccia di applicazione è l’elaborazione e la memorizzazione delle informazioni relative all’esecuzione di un’applicazione. Contiene dati da entità, modifiche allo stato e componenti software coinvolti in tale esecuzione. La sua funzionalità principale è facilitare il monitoraggio o l’analisi dell’esecuzione dell’applicazione:

• analizzare il comportamento dell’applicazione durante lo sviluppo e la fase di debug (test box bianchi)
• Analizzare gli errori di bug o esecuzione rilevati, le loro cause e le conseguenze
• servono come record di audit quando le informazioni contenute e la modalità in cui è stata elaborata soddisfa i criteri richiesti
• Le prestazioni o il caricamento di sistemi o applicazioni
• Invertire lo stato dell’applicazione che segue in ordine inverso il registro

dipende dalle circostanze in cui ci troviamo, il Il secondo degli usi è solitamente il più rilevante. Un buon registro sviluppato correttamente nel codice e gestito o configurato in funzione è una rapida garanzia di risposta per l’analisi degli errori; che potrebbe anche essere fatto senza la necessità di fermare l’applicazione, riconfigurarlo o applicare qualsiasi modifica.

La traccia dell’applicazione è solitamente formata da una serie di eventi memorizzati in sequenza, solitamente nell’ordine in cui essi capita, persistente o recuperabile. Possono essere memorizzati in file, in BBDD, in componenti distribuiti per questo scopo … I meccanismi di rotazione o di stornificazione possono essere abilitati, possono essere utilizzati dai monitor per lanciare avvisi, possono essere integrati e fusi per creare analisi più esaustive .. . Il relativo è che le informazioni registrate e come è riuscita ad essere utile.

Ci sono numerose soluzioni e proposte software, sia gratuite che complete, più o meno standardizzate, più semplici o più complete, di migliaia tipi e forme. La cosa importante è cercare che si adatta ai nostri bisogni e ambienti, per dimenticare completamente l’implementazione del meccanismo; e attenersi ai due aspetti più importanti:

• il contenuto di ciascun record o evento, la preoccupazione principale dello sviluppatore
• il modo in cui viene elaborato, persiste e Gestisce, preoccupazione principale del funzionamento del sistema o dell’applicatore

Il costo dell’attuazione della registrazione è nell’IR, durante lo sviluppo, lasciando traccia in diversi punti del codice. Questa attività dovrebbe essere fatta durante lo sviluppo, seguendo schemi, criteri e procedure prestabilita. In questo modo gli sviluppatori avranno criteri comuni e la traccia sarà coerente tra le diverse parti del codice.

La traccia e la documentazione del codice possono avere punti in comune in termini di filosofia, obiettivi e Modalità di applicazione, ma c’è una differenza importante tra i due: mentre la documentazione del codice entra nel perché qualcosa è fatto in questo modo, la traccia deve coprire ciò che è fatto. Impostando un esempio, in un ciclo, la documentazione del codice dovrebbe indicare perché i limiti o le condizioni di uscita sono tali e il registro di traccia durante l’esecuzione a quale punto detta condizione di uscita è stata soddisfatta.

Informazioni registrate nel La traccia deve essere pertinente e completa. Puoi considerare i seguenti aspetti al momento del decidere quali informazioni includono:

• cosa:
  • quale evento o azione è accaduto.
  • quali entità hanno lo stato coinvolto.
  • Se c’è un cambiamento di stato, qual è stato il precedente? Qual è il nuovo stato?
• dove:
  • A quale punto del codice si è verificato: componente, classe, file di codice, metodo o blocco di esecuzione, linea di codice … Molto più dettagliato è questa informazione migliore per individuare il luogo di possibile errore o dove è passata l’esecuzione, da un lato; Ma più può influenzare la registrazione delle prestazioni (potrebbe essere richiesta le informazioni di debug) e la conclusione delle informazioni di traccia, dall’altro.
• quando:
  • Registrazione del temporaneo momento, assolutamente o correlato all’inizio dell’esecuzione o qualsiasi altro evento.
  • Generazione di una traccia sequenziale o causale, in cui gli eventi che si verificano prima nel tempo o causano altri.
• in quale contesto:
  • Registrazione di stati o variabili: eseguendo se stesso (parametri), personalizzazione o specifica dell’utente, referente alla sessione o alla transazione in esecuzione …
  • indicando fili, transazioni o richieste correlate quando siamo in ambienti simultanei.

Per le informazioni sulla traccia sono più dettagliate al momento dell’analisi e Più gestibile durante lo sfruttamento, sono stabiliti i livelli di filtraggio. In tal modo che solo tali eventi sono mostrati o conservati con un livello maggiore o uguale al livello di traccia stabilito. Le librerie di registrazione consentono agli eventi di filtrare gli eventi con altri criteri come la classe o il contesto dell’evento.

I livelli più comuni sono il debug, informazioni, avviso ed errori. La classificazione di diversi eventi ad ogni livello fa parte dell’esercizio dell’analisi e dovrebbe essere rivolto al fatto che la traccia è leggibile e utile nei diversi contesti dell’applicazione, dallo sviluppo allo sfruttamento.

Questo Può essere un esempio di semantica dei livelli di registrazione:

• debug, per informazioni di livello molto basso utile solo per il debug della domanda, sia nello sviluppo che nell’analisi degli incidenti
  • chiama alle funzioni e alle procedure e ad altri componenti, con parametri e risposte
  • flussi in esecuzione
  • sviluppo di algoritmi e procedure che consentono di identificare e seguire la sua esecuzione di sviluppo
• informazioni, informazioni di livello superiore che consentono di monitorare la normale esecuzione
  • si arresta e interrompe i servizi e i sistemi
  • parametri critici o configurazione pertinente
  • Inizio e fine delle transazioni e operazioni complete
  • Modifiche di Stato delle operazioni
• Warn, informazioni sulle situazioni, che ancora senza essere errori, se anormali o non previste, sebbene l’applicazione abbia alternative per risolverli
  • non I parametri definiti e il cui valore è preso per impostazione predefinita
  • situazioni anomali, ma che vengono risolte dalla domanda, lasciando l’operazione in uno stato corretto
  • funzionalità non primordiali o essenziali, che Non possono essere risolti, ma lasciano l’operazione in uno stato corretto
• errore, informazioni sulle situazioni che sono errori e che impediscono la corretta esecuzione di un’operazione o di una transazione, ma senza influire su altre operazioni o transazioni (errore isolato o contenuto)
  • nessuna operazione o transazione non può essere eseguita, ma non influisce su altre richieste
  • o query errata (memorizzando i parametri di Ingresso)
  • funzionalità generali dell’applicazione, che influisce ancora nel funzionamento generale dell’applicazione Ivo, non sono considerati primordiali o essenziali
• Le informazioni di situazioni di errore, di errore che influenzano il funzionamento generale dell’applicazione (errori non isolati o contenuti nell’ambito)
  • Parametri non definiti o impostazioni errate
  • Mancanza di connessione o comunicazione con altri componenti
  • Errori di esecuzione in grado di influenzare le operazioni o le transazioni indipendenti o che influenzano il funzionamento generale dell’applicazione

Sia il contenuto che la forma di ciascun evento del registro, come la semantica dei livelli fanno parte del progetto dell’applicazione. Questi criteri devono essere definiti e comunicati al team di sviluppo per applicare omogeneamente e coerentemente in tutto lo sviluppo. Se questi criteri sono concordati con l’attrezzatura è possibile ottenere molto vantaggio dall’esperienza dello sviluppatore.

Altre raccomandazioni da tenere in considerazione sono:

• Registra gli eventi in un modo Atomic, che tutte le informazioni relative a un evento vengano memorizzate in un record o riga.
• Guida il formato delle informazioni dimostrate da utilizzare in modo computerizzato o automatico con strumenti specifici.
• Per quanto riguarda le eccezioni:
  • mostra sempre la traccia completa dell’eccezione con il tuo messaggio e tutto lo stacktrace.
  • Se l’eccezione viene catturata, trattata e quindi gettata di nuovo (bene lo stesso o l’altra) non lasciare la traccia dell’eccezione finché non viene catturata e in definitiva. In questo modo ogni eccezione verrà visualizzata solo una volta. Se non lo facciamo in quel modo e registrare ogni cattura e rilancio apparirà nella traccia più volte e non sapremo se è lo stesso o sono diversi. (Antipatron Catch-Log-Throw).
  • Utilizzare la prova di eccezione causata o interna quando catturiamo e accolgono l’eccezione. In Java è il metodo GetCouse (), in .NET la proprietà Innerexception.

• Utilizza i meccanismi MDC / NDC (informazioni sul contesto) Per ambienti di thread multipli o aree di transazione. Queste informazioni possono consentirci di filtrare o specificare le informazioni del registro in specifico contesto aziendale come clienti, utenti, prodotti …
• Implementare il metodo Tostring () di tutte le classi aziendali o picchi per facilitare il tuo Traceado.
• Devi prendere le differenze e le zone del tempo in considerazione quando si lavora con i registri da varie macchine o componenti.
• La registrazione non può avere effetti collaterali, non è possibile modificare lo stato di nessuno parametro, variabile o procedura. Mostra solo informazioni. Deve essere leggero, la registrazione stessa potrebbe non richiedere un’elaborazione lunga o costosa.
• chiamate a metodi distribuiti esterni, componenti e componenti, devono essere registrati dopo la chiamata, compresi i parametri di input e risposta, nonché la classe / Componente e metodo, a livello di debug. E all’errore e al livello fatale quando si verifica un errore nella chiamata (se un’eccezione deve essere tracciata, ingresso e parametri di eccezione)

un saluto,

Juan Francisco Adame Lorite