Perché il filesystem è preferito per i log invece di RDBMS?

1. Troppe cose possono fallire con il database e anche la registrazione di questi errori è importante.

2. Se non si dispone di un sistema di database che consente transazioni autonome (o nessuna transazione), la registrazione richiederebbe una connessione separata, quindi un rollback o un commit nella registrazione non interferisce con il rollback o il commit nell'applicazione.

3. Molte cose che valgono la registrazione avvengono durante l'avvio, probabilmente prima che la connessione al database sia stata stabilita.

4. In quello che potrebbe essere un tipico setup, ogni giorno viene creato un nuovo file di log, i vecchi file di log vengono compressi e conservati per 2 settimane, prima di essere eventualmente cancellati. Non è facile fare lo stesso in un RDBMS.

Ho visto i registri scritti sul DB prima (ea volte si ottengono opzioni configurabili per la registrazione, dove la traccia va al file, errori nel DB, fatali al registro eventi di Windows).

I motivi principali sono la velocità e le dimensioni, in quanto alcune tracce possono produrre vaste e vaste qualità di registrazione: ho trascinato i file di log in gigabyte di dimensioni. L'altro motivo principale è che la lettura dei log deve essere sequenziale, non è necessario interrogare il log, tranne per trovare un determinato errore o voce - e find-in-file funziona perfettamente per questo.

La velocità è una delle ragioni; altri sono:

• Eliminazione dei punti di errore. Un filesystem raramente fallisce in condizioni in cui un DBMS non lo farebbe, ma ci sono molte e molte condizioni di errore nei database che non esistono nei filesystem.
• Accessibilità low-tech. Se le cose si mettono davvero male, puoi avviare una shell di salvataggio o montare il disco su un sistema diverso e avere ancora strumenti adeguati per ispezionare i file di registro. Se si tratta di un database, non sei da nessuna parte senza un server di database in esecuzione.

Prima di tutto.

And those might even fail in particular circumstances if great care was not paid.

Le transazioni del database non possono fallire quando non stai attento?

Scrivere su un file di testo ha una serie di vantaggi, il più importante è

• Il testo è leggibile dall'uomo. Chiunque può aprire un file di registro con un editor di testo di base e vedere quali sono i messaggi. Non è necessario capire come è organizzato il database.
• Velocità. Scrivere un testo su disco è molto più veloce che un servizio di database capisca dove il testo va in un database, lo scrive lì e garantisce che la transazione sia completata.

Esponi specificamente Apache, quindi ne discuterò in dettaglio.

Apache può essere configurato per accedere a un database, sebbene richieda un plug-in esterno per farlo. L'utilizzo di tale plug-in può semplificare l'analisi dei registri, ma solo se si intende scrivere il proprio software di analisi dei registri. Analizzatori di log standard pronti all'uso presuppongono che i registri siano nei file, quindi non sarà possibile utilizzarli.

Quando lo facevo, avevo anche problemi di affidabilità: se il buffer di scrittura del server del database si riempiva (cosa che può succedere con mysql se si utilizza la quota del file system per l'utente in cui viene eseguito) inizia ad accodare le query fino a quando sono in grado di procedere, a quel punto Apache inizia ad aspettare che finisca, causando richieste appese al tuo sito web.

(Questo problema potrebbe ora essere risolto, ovviamente - è stato molti anni fa che l'ho fatto)

Diamo un'occhiata a questo su alcuni livelli:

1. Livello macchina
2. Livello del sistema operativo
3. Livello di servizio
4. Livello applicazione

In breve:

• Sul livello macchina, non è possibile eseguire la registrazione oltre a una sorta di dump.
• Sul livello del sistema operativo è possibile eseguire la registrazione, ma in realtà è disponibile solo il file system.
• I servizi possono accedere al file system, ma non possono fidarsi che altri servizi siano in esecuzione in modo che non possano accedere lì.
• Le applicazioni possono accedere ai servizi e al file system.

Quindi abbiamo l'approccio basato sul caso d'uso:

Vuoi registrare gli errori specifici del nodo in un RDBMS con ridimensionamento orizzontale, in cui devi eseguire il lavoro extra per trovare l'errore di un nodo specifico quando potresti semplicemente aprire il cofano per un nodo e vederlo lì? D'altra parte, l'applicazione dovrebbe eventualmente accedere a un RDBMS per raccogliere errori e notifiche a livello di applicazione.

Che cosa succede quando RDBMS deve eseguire la registrazione da solo perché non è possibile scrivere il database?

Un filesystem è un database. È infatti un database gerarchico più semplice invece di un DBMS relazionale, ma è comunque un database.

Il motivo per cui il logging su un filesystem è popolare è perché i log di testo si adattano bene alla filosofia Unix: "Il testo è l'interfaccia universale."

Unix si era sviluppato con molti strumenti per scopi generali che possono funzionare bene con i registri di testo. Non importa se i log di testo sono prodotti da mysql, apache, la tua applicazione personalizzata, software di terze parti che non ha più supporto, il sysadmin può utilizzare strumenti Unix standard come grep, sed, awk, sort, uniq, cut, tail ecc. per navigare tra i registri ugualmente.

Se ogni app accede al proprio database, uno a MySQL, un altro a Postgres, un altro a Elasticsearch, un altro vuole accedere a ELK, un altro può accedere a MongoDB, quindi si dovrebbero imparare venti diversi strumenti per log di ogni applicazione. Il testo è un supporto universale a cui tutti possono accedere.

Anche quando riesci a fare in modo che tutti i registri vadano a un singolo database, ad esempio MySQL, potresti scoprire che ogni applicazione vorrebbe effettuare il log con schemi di tabelle diversi, quindi devi comunque scrivere uno strumento personalizzato per interrogare il registri per ogni applicazione. E se in qualche modo stipati tutte le applicazioni per accedere a un singolo schema, è probabile che lo schema generico non sia in grado di raccontarti la storia completa di ogni applicazione, quindi devi comunque analizzare i testi dei registri.

Spesso la registrazione su un database non semplifica le cose in modo significativo.

La registrazione su un database può essere utile quando si dispone di un'analisi specifica che si è in mente o per specifici requisiti di conservazione del controllo, per i quali è possibile progettare uno schema di database specifico per raccogliere solo i dati per tali scopi specifici. Ma per il forensic e il debugging e quando raccogli il log senza considerare obiettivi specifici, i log di testo sono in genere abbastanza buoni da non valerne il costo di apprendimento o la creazione di strumenti specializzati.

Complessità. L'aggiunta di RDBMS aumenterà la complessità dell'intero sistema astronomicamente. E la capacità di gestire la complessità è la cosa principale che distingue i programmatori dai produttori di codice sorgente.

Is it speed or maintainability or something else?

Velocità.