Perché il filesystem è preferito per i log anziché per RDBMS?

La domanda dovrebbe essere chiara dal suo titolo. Ad esempio Apache salva i suoi accessi e registra i log degli errori nei file anziché in RDBMS, indipendentemente da quanto grande o piccola scala venga utilizzata.

Per RDMS non ci resta che scrivere query SQL e farà il lavoro mentre per i file dobbiamo decidere un particolare formato e quindi scrivere regex o potrebbero essere parser per manipolarli. E quelli potrebbero anche fallire in circostanze particolari se non si prestasse grande cura.

Eppure tutti sembrano preferire il filesystem per mantenere i log. Non sono di parte nei confronti di nessuno di questi metodi, ma vorrei sapere perché è praticato in questo modo. È velocità o manutenibilità o qualcos'altro?

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

2. A meno che non si disponga di un sistema di database che consenta transazioni autonome (o nessuna transazione), la registrazione richiederebbe una connessione separata in modo che un rollback o un commit nella registrazione non interferiscano con il rollback o il commit nell'applicazione.

3. Molte cose degne di nota accadono durante l'avvio, cioè probabilmente prima che sia stata stabilita la connessione al database.

4. In quella che potrebbe essere un'impostazione tipica, ogni giorno viene creato un nuovo file di registro, i vecchi file di registro vengono compressi e conservati per 2 settimane, prima di essere infine eliminati. Non è facile fare lo stesso in un RDBMS.

Ho già visto registri scritti nel DB in precedenza (e talvolta si ottengono opzioni configurabili per la registrazione, dove traccia va al file, errori al DB, fatali al registro degli eventi di Windows).

Le ragioni principali sono la velocità e le dimensioni, abilitare alcune tracce può produrre enormi e vaste qualità di registrazione: ho esplorato file di registro di dimensioni gigabyte. L'altro motivo principale è che la lettura dei registri deve essere sequenziale, non è realmente necessario interrogare il registro, tranne per trovare un determinato errore o voce - e find-in-file funziona perfettamente per quello.

La velocità è una ragione; altri sono:

• Eliminare i 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à a bassa tecnologia. Se le cose vanno davvero male, è possibile avviare una shell di ripristino o montare il disco su un sistema diverso e avere ancora strumenti adeguati disponibili per ispezionare i file di registro. Se si tratta di un database, non ci si trova da nessuna parte senza un server database in esecuzione.

Prima di tutto

E quelli potrebbero anche fallire in circostanze particolari se non si prestasse grande cura.

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

Scrivere in un file di testo ha una serie di vantaggi, l'essere 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 testo su disco è molto più veloce di un servizio di database per capire dove va il testo in un database, scriverlo lì e garantire che la transazione sia completata.

Sollevi Apache in modo specifico, quindi ne discuterò in dettaglio.

Apache può essere configurato per accedere a un database, anche se per farlo è necessario un plugin esterno . L'utilizzo di tale plug-in può semplificare l'analisi dei log, ma solo se si intende scrivere il proprio software di analisi dei log. Gli analizzatori di log standard disponibili presuppongono che i log siano in file, quindi non sarà possibile utilizzarli.

Quando lo facevo, ho riscontrato anche problemi di affidabilità: se il buffer di scrittura del server di database si riempiva (cosa che può accadere con mysql se si utilizza la quota del file system per l'utente con cui viene eseguito) inizia a mettere in coda le query fino a quando non sono in grado per continuare, a quel punto Apache inizia ad aspettare che finisca, dando luogo a richieste bloccate sul tuo sito web.

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

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

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

Unix aveva sviluppato molti strumenti generici che possono funzionare bene con i log di testo. Non importa se i log di testo sono prodotti da mysql, apache, la tua applicazione personalizzata, software di terze parti che non è più supportato, l'amministratore di sistema può utilizzare strumenti Unix standard come grep, sed, awk, sort, uniq, cut, tail , ecc., per navigare tra i registri lo stesso.

Se ogni app accede al proprio database, uno su MySQL, un altro su Postgres, un altro su Elasticsearch, un altro vuole accedere a ELK, un altro può accedere solo a MongoDB, quindi dovresti imparare venti diversi strumenti per esplorare i registri di ciascuno applicazione. Il testo è un supporto universale a cui tutti possono accedere.

Anche quando riesci a farlo in modo che tutti i registri vadano su un singolo database, ad esempio MySQL, potresti scoprire che ogni applicazione vorrebbe accedere con schemi di tabella diversi, quindi dovresti comunque scrivere uno strumento personalizzato per interrogare i registri per ogni applicazione. E se in qualche modo hai riempito tutte le applicazioni per accedere a un singolo schema, probabilmente scoprirai che quello schema generico non potrebbe davvero raccontarti la storia completa di ogni applicazione, quindi devi comunque analizzare i testi del registro.

La registrazione in un database spesso non semplifica notevolmente le cose nella pratica.

La registrazione in un database può essere utile quando si ha in mente un'analisi specifica o per requisiti di conservazione del controllo specifici, per i quali è possibile progettare uno schema di database specifico per raccogliere solo i dati per quegli scopi specifici. Ma per scopi forensi e di debug e quando si raccolgono registri senza obiettivi specifici in mente, i registri di testo sono in genere abbastanza buoni da non valerne la pena i costi di apprendimento o creazione di strumenti specializzati.

Diamo un'occhiata a questo su alcuni livelli:

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

In breve:

• A livello di macchina, non è possibile effettuare registrazioni diverse da una sorta di dump.
• A livello di 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 di altri servizi in esecuzione, quindi non possono 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 su un RDBMS in scala orizzontale dove devi fare il lavoro extra per trovare l'errore di un nodo specifico quando puoi semplicemente aprire il cofano per un nodo e vederlo lì? D'altra parte, l'applicazione potrebbe probabilmente accedere a un RDBMS per raccogliere errori e notifiche a livello di applicazione.

Cosa succede quando RDBMS deve eseguire la registrazione autonomamente perché non è possibile scrivere il database?

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

È velocità o manutenibilità o qualcos'altro?

Velocità.