Log eventi lato server attraverso DB o scrittura su file?

Se si accede al DB, dove registreresti gli errori db, come il DB che non è disponibile?

Sì, se accedi al file system, il file system potrebbe diventare non disponibile, ma suppongo che tu abbia altre cose di cui preoccuparti ...

In un'applicazione server (non un server Web, ma comunque con un carico pesante), si accede ai file (diversi), utilizzando un componente di registrazione specializzato. E mentre le prestazioni sono un fattore cruciale in molte parti del codice, dobbiamo ancora sentire la necessità di ridurre la nostra registrazione a causa di considerazioni sulle prestazioni.

Probabilmente perché la maggior parte della registrazione viene eseguita al di fuori del codice critico. Il che è solo "naturale" perché il codice critico del tempo spesso produce troppi messaggi di log per essere di qualsiasi utilità pratica.

Alcuni database come Oracle e MySQL ti consentono di trattare un normale file txt come una tabella, quindi puoi eseguire istruzioni SELECT su di esso.

Se intendi utilizzare un file, devi prendere in considerazione:

0-Problemi di concorrenza (cosa succede se 2 record devono andare al file nello stesso momento)?

1-Come cercarlo?

2: Quanto grandi permetteranno che cresca? Potrebbe essere necessario uno script speciale per questo

3-Dove memorizzarlo?

4-Come eseguire il backup (se necessario) - Potrebbe essere necessario uno script speciale per questo.

Vedo che usare una tabella di database regolare è l'approccio più pratico. Riduce la complessità della gestione dei dati. Ecco a cosa servono i database. Per migliorare le prestazioni della tua tabella di log, posizionala lontano dallo spazio del tuo database e non crea alcun indice su di essa.

Solo se la maggior parte dei membri del tuo team non sa come gestire il file di testo nella riga di comando puoi giustificare l'uso di un registro basato su db. Per le preoccupazioni che hai elencato:

1. Rendimento: per accodare le informazioni riga per riga, penso che nessun db faccia più veloce di un file di testo.
2. Query facile: come sei sicuro che db sia migliore in questo caso se molto probabilmente farà lo scan delle tabelle comunque? Eviterei di scrivere sql se l'espressione regolare lo fa meglio per filtrare i log, che, dalla mia esperienza, è quasi certo.
3. Scalabilità: non è sicuro quale sia la tua preoccupazione qui, ma per la registrazione, qualsiasi cosa db possa fare, il file di testo può farlo più velocemente, il che dovrebbe risolvere qualsiasi problema di scalabilità.

UPDATE: Basta mostrare un esempio che potresti voler fare con il tuo registro ma db fa schifo in quel caso: elenca le ultime 20 voci del registro per l'ID utente 28465283 prima della voce del registro delle eccezioni di riferimento null:

grep -B 20 "28465283. * NullReferenceException" log.txt > to-the-grasso-monkey.txt

Suppongo che mi ci vorrà un po 'per capire come scrivere un SQL per la stessa query.

Vorrei prendere l'approccio di registrazione del database. Se si verificano così tanti errori che influiscono sulle prestazioni del database, è assolutamente necessario rivisitare l'origine di questi errori.

L'archiviazione dei dati di registrazione (e auditing) nel database consente un facile accesso, query ad hoc (nonché processi e / o funzioni memorizzati) per estrarre report di errori spesso interrogati.

La tua applicazione dovrebbe essere in grado di fare entrambe le cose. Quindi modificare di conseguenza. Se stai colpendo troppo il database (davvero non riesci a vedere come ciò accadrà se non stai pianificando su un sacco di traffico) puoi passare al file .log. Oltre a questo, puoi anche accedere a un formato come JSON e caricare il carico di dati in un altro database in background / successivo.

Con le applicazioni che scrivo di solito mantengo le ultime N chiamate di debug in una matrice di qualcosa e le scarico quando riscontro un errore.

Per gli eventi all'interno della tua applicazione, vorrei andare alla rotta del DB. Ciò ti consentirà di cercare, ordinare e segnalarli più facilmente.

Non so di Postgres, ma MySQL ha un 'INSERIRE RITARDATO' command, che dice al db di confermare la riga inserita quando il server è inattivo. Questo è ottimo per la registrazione in quanto non stai mantenendo la tua pagina web / applicazione aspettando che l'inserimento sia completato. Quindi controllerei se Postgres supporta qualcosa del genere.

Accedo a un file di registro centrale utilizzando syslog, nonché a un file locale per server (nel caso in cui syslog non riesca). Quindi offline importare i file registrati centralmente in un database per l'analisi (di solito applicando qualche tipo di trasformazione - ad esempio eventi di conteggio, ecc.), A seconda dei requisiti.