Accesso a file di testo o database?

Quando devo utilizzare il database per la registrazione e quando i file di testo?
Vedo che i server Web e i framework Web (che la tua app utilizza internamente) di solito (sempre?) Registrano le richieste e gli errori nei file di testo per impostazione predefinita. Ma vedo che le persone che sviluppano la loro app attorno a quei server e framework a volte accedono al database (anche al DB principale dell'app, non a quello esterno).
Inoltre, forse c'è una differenza tra i log di debug e i log di controllo - ho letto questa classificazione da qualche parte su questo sito.

In termini molto generali, la registrazione in un file di testo è molto più rapida della registrazione in un database. Questo è l'aspetto principale della registrazione che devi considerare.

Il motivo per cui si accede a un DB è più probabile perché si desidera interrogare i risultati: la ricerca di particolari informazioni di registro è più semplice in un DB, in particolare se si registrano informazioni contestuali che possono essere utilizzate per raggruppare le voci di registro. Di solito è anche più facile accedere a un DB centrale rispetto a un file di registro su un server che può essere protetto e non accessibile.

L'ideale sarebbe accedere localmente a un file, quindi migrare questi dati su un DB per l'ispezione, se necessario in seguito.

Ora l'auditing è una bestia completamente diversa. Sebbene abbia un concetto simile alla registrazione, di solito è necessario che l'audit sia conservato a lungo (diversamente dai file di registro utilizzati per il debug o la traccia che possono essere eliminati per un capriccio). Gli audit sono lì per mostrare informazioni importanti. Registri molte meno informazioni di controllo e meno spesso della normale registrazione, quindi le prestazioni non sono un problema. È per questo motivo che si vedono i vantaggi di scrivere queste informazioni di controllo in un DB centrale.

Non esiste una dimensione adatta a tutti gli approcci e per resilienza, a volte si desidera utilizzare più approcci. Prendendo il tuo esempio, potresti voler archiviare i log di debug in un file e archiviare i log di controllo in un DB.

Pangrattato per applicazione

Pro: facile da implementare e immediatamente visibile all'utente

Contro: le informazioni persistono solo quando l'applicazione è attiva

File di testo

Pro: facile da implementare

Contro: è necessario assicurarsi che non si verifichi il blocco dei file. Cosa fare quando lo spazio su disco si esaurisce nell'unità di registro?

Registro eventi

Pro: facile da implementare

Contro: il registro eventi potrebbe diventare pieno se non impostato correttamente o i vecchi registri potrebbero andare persi a causa di criteri di conservazione / cancellazione.

Banca dati

Pro: facile da implementare

Contro: più traffico DB. Come registrare una perdita di DB o altro problema DB?

Messaggi (MQ)

Pro: sparare e dimenticare

Contro: un altro livello per andare storto. Richiede installazione

I registri di controllo devono garantire la completa tracciabilità delle operazioni nel tempo più lungo a fini di controllo, con l'obiettivo di giustificare pienamente il contenuto del database.

In alcuni casi (ad es. Applicazioni finanziarie), questi registri potrebbero dover garantire la conformità a requisiti legali come la conservazione (in alcuni paesi per 10 anni) o l'inalterabilità. Poiché questi registri devono giustificare il contenuto del db a livello di applicazione, è prassi comune archiviarli nel db, dove è possibile controllare l'accesso per evitare alterazioni non autorizzate.

Altri registri , come i registri di monitoraggio o i registri di sicurezza, devono spesso far fronte a vincoli di prestazioni e volume. Questi sono generalmente scritti in un file perché è più veloce da scrivere (nessun sovraccarico di gestione delle transazioni) più facile da archiviare offline e più facile da integrare con gli strumenti SIEM di monitoraggio esterno .

Va notato che, sebbene questo tipo di registri possa essere utilizzato per dimostrare l'affidabilità dei registri di controllo (ad es. Nessun accesso non autorizzato), generalmente hanno vincoli di conservazione più brevi (ad esempio tra 6 mesi e 2 anni ai fini dell'applicazione della legge per i registri delle telecomunicazioni) se nessun vincolo a tutti.

Uno dei molti motivi per utilizzare db per la registrazione di debug è quando non si ha accesso all'applicazione o al server Web per visualizzare il visualizzatore di eventi o i file di testo

I registri di controllo sono diversi dai registri di debug nel contesto dell'applicazione Web, poiché in alcune applicazioni potrebbe essere necessario mostrarli all'utente finale, quindi dovrebbero andare nel database per un facile recupero.

È possibile utilizzare DB Tools anche per filtrare e visualizzare facilmente.