Registrazione eventi: registra un intero messaggio o un elenco di proprietà e genera?

Question

Registrazione eventi: registra un intero messaggio o un elenco di proprietà e genera?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Ho scritto un semplice sistema di registrazione degli eventi, su cui scrivo con una funzione simile a:

void IIncidentLogic.ReportIncident(
  string code,
  string noun,
  string hostname,
  DateTimeOffset occurredAt)

Dove code deriva da un insieme di costanti come VOL_SIZE_INCREASE , noun sarebbe il percorso del volume, hostname il computer dove si è verificato e occurredAt quando è stato rilevato.

Poiché code è un valore noto, posso impostare automaticamente altre proprietà, come la gravità dell'evento, ad es. si tratta di un avviso o di un errore ? Uso anche code per interrogare un dizionario risorse per un messaggio di errore amichevole da mostrare agli utenti. In questo momento per questo esempio il messaggio di errore sarebbe A volume has increased in size , con noun aggiunto in modo impacciato al messaggio di errore.

Sto cercando di migliorare la leggibilità dei messaggi di errore, ad es. in questo scenario è qualcosa come The volume system (c:) on computer-name has increased in size from 100GB to 200GB .

Posso pensare a un paio di modi per farlo e mi sto chiedendo quale sia la pratica migliore.

Potrei pre-compilare il messaggio di errore e passare alla funzione di registrazione, memorizzandola nel proprio campo. Tuttavia, voglio forzare programmaticamente il messaggio affinché sia lo stesso, indipendentemente da dove viene generato. Un parametro string message è troppo aperto.

Quindi potrei registrare un dizionario di proprietà contro il rapporto, ad es. %codice%. Potrei ancora utilizzare le stringhe di risorse per generare i messaggi, ma formattarli, ad es. %codice% Ciò consente i8ln, che è un probabile requisito futuro. Ma ha la possibilità di rompere i dati legacy se qualche parte cambia, ad es. è richiesta una proprietà aggiuntiva.

E potrei fare entrambe le cose: usare le proprietà e la formattazione delle stringhe e memorizzare la stringa generata allo stesso tempo.

Potrei anche arrivare ad avere una classe per tipo di evento, o codice, con diversi parametri del costruttore, ma questo sicuramente sembra eccessivo.

O esiste un diverso schema stabilito per questo tipo di registrazione?

design architecture logging

posta mattdwen 09.07.2015 - 05:37

fonte

3 risposte

Leggi altre domande sui tag design architecture logging

Quali sono le differenze in termini di velocità e funzionalità tra l'utilizzo di Azioni vs Delegati? è un attacco DoS una buona analogia con Dining Philosophers?

score 2 · Answer 1

Sento di poter contribuire a questa data risposta .

Il concetto che Phill sta descrivendo si avvicina molto al Pattern EventSourcing . Se i tuoi sistemi contengono diversi tipi di eventi, prendi in considerazione una tale implementazione. La flessibilità eccessiva, come menzionato da Phill, aumenterà drasticamente dal momento che non devi sapere ancora cosa farai con i dati.

score 1 · Answer 2

Se vuoi uniformità, allora usare una classe per ogni condizione di errore ti dà proprio questo: ovunque tu voglia menzionare che un volume è cresciuto di dimensioni, tu crei un'istanza di una classe VolumeSizeIncreased, trasmettendo tutti i valori necessari costruttore.

Per me, è il passo successivo dopo aver codificato rigidamente i tuoi errori (il tuo valore VOL_SIZE_INCREASE).

VolumeSizeIncreasedMessage vsim 
   = new VolumeSizeIncreasedMessage( "PC123456", "system (C:)", 100, 200, DateTime.Now ) 
Console.WriteLine( vsim.toString() );

Hai intenzione di fare qualcosa con questi errori in seguito (oltre a leggerli fisicamente)? Se è così, gli oggetti sono un'opzione di gran lunga migliore, perché puoi interrogare le loro proprietà e intraprendere azioni basate su quelle (ma sto virando in Exception Handling qui).

score 1 · Answer 3

La migliore registrazione è solo per formattarla come stringa leggibile e persistere. Forse includendo i dati come un blocco di dati accessibile anche ai programmi.

La ragione per cui dico questo è che guardo continuamente ai registri degli eventi di Windows, che utilizza un modello "scriviamo i dati e un link a una dll di risorsa contenente stringhe di formato", e invariabilmente la dll è presente solo sull'host computer - non sul mio dove analizzo i log. Quindi, non posso mai vedere il testo completo di ciò che è stato scritto, solo i dati grezzi.

È anche molto facile e semplice scrivere testo, ed è quello che vorresti scritto quando verrai a guardare i log più tardi, rendendolo il modello ideale.

Si noti inoltre che esiste un'enorme controversia nel mondo Linux al momento che systemd scrive i suoi registri utilizzando un formato binario, il che significa che è necessario un visualizzatore speciale per leggerli. Le persone erano abituate a usare qualsiasi vecchio editor di testo per leggere e / o analizzare i log scritti in formati di testo. C'è una buona ragione per cui i log di testo con stringhe in chiaro sono stati utilizzati per la registrazione.

Quindi pensa all'utente finale dei tuoi registri e in che modo interagiranno con loro e adatta la tua soluzione per offrire loro la migliore esperienza.