Perché la maggior parte dei file di registro utilizza il testo normale anziché un formato binario?

La registrazione è qualcosa che è necessario ma è (relativamente) usato raramente. Come tale, può essere reso molto più compatto in termini di archiviazione.

Ad esempio, i dati più comunemente registrati come ip, data, ora e altri dati che possono essere rappresentati come numeri interi vengono archiviati come testo.

Se la registrazione fosse archiviata come dati binari, si potrebbe conservare molto spazio, richiedendo quindi una rotazione inferiore e aumentando la durata del disco, in particolare con gli SSD in cui le scritture sono limitate.

Alcuni potrebbero dire che è un problema così piccolo che non ha davvero importanza, ma prendendo in considerazione lo sforzo necessario per costruire tale meccanismo non ha senso non farlo. Chiunque può farlo per circa due giorni nel suo tempo libero, perché la gente non lo fa?

systemdmemorizza i suoi file di registro in formato binario. I problemi principali che ho sentito sono:

1. se il registro viene danneggiato è difficile ripristinarlo in quanto necessita di strumenti specialistici
2. essi non sono leggibili, quindi non è possibile utilizzare gli strumenti standard come vi, grep, tailecc per analizzarli

Il motivo principale per l'utilizzo di un formato binario (per quanto ne so) è stato ritenuto più facile per la creazione di indici, ecc. Cioè per trattarlo più come un file di database.

Direi che il vantaggio dello spazio su disco è relativamente piccolo (e decrescente) in pratica. Se si desidera archiviare grandi quantità di registrazione, zippare i registri laminati è davvero abbastanza efficiente.

A conti fatti, nella maggior parte dei casi i vantaggi degli strumenti e della familiarità probabilmente errerebbero dal lato della registrazione del testo.

Perché la maggior parte dei file di registro utilizza il testo normale anziché un formato binario?

Cerca la parola "testo" nell'articolo Wikipedia della filosofia Unix , ad esempio troverai affermazioni come:

McIlroy, allora capo del CSRC (Computing Sciences Research Center) di Bell Labs, e inventore del tubo Unix, [9] ha riassunto la filosofia Unix come segue: [10]

Questa è la filosofia Unix: scrivere programmi che fanno una cosa e la fanno bene. Scrivi programmi per lavorare insieme. Scrivi programmi per gestire flussi di testo, perché questa è un'interfaccia universale.

O per esempio, da Basics of the Unix Philosophy ,

Regola di composizione: progettare programmi da collegare con altri programmi.

È difficile evitare la programmazione di monoliti complicati se nessuno dei tuoi programmi è in grado di parlare tra loro.

La tradizione Unix incoraggia fortemente la scrittura di programmi che leggono e scrivono formati semplici, testuali, orientati al flusso e indipendenti dal dispositivo. In Unix classico, quanti più programmi possibili sono scritti come semplici filtri, che accettano un semplice flusso di testo in input e lo trasformano in un altro semplice flusso di testo in output.

Nonostante la mitologia popolare, questa pratica è preferita non perché i programmatori Unix odiano le interfacce grafiche degli utenti. È perché se non scrivi programmi che accettano ed emettono semplici flussi di testo, è molto più difficile collegare i programmi insieme.

I flussi di testo sono destinati agli strumenti Unix come i messaggi sono agli oggetti in un'impostazione orientata agli oggetti. La semplicità dell'interfaccia del flusso di testo impone l'incapsulamento degli strumenti. Forme più elaborate di comunicazione tra processi, come le chiamate di procedure remote, mostrano una tendenza a coinvolgere troppo i programmi con gli interni degli altri.

Chiunque può farlo per circa due giorni nel suo tempo libero, perché la gente non lo fa?

La memorizzazione del file di registro in binario è solo l'inizio (e banale). Dovresti quindi scrivere strumenti per:

• Visualizza l'intero file di registro ( edit)
• Visualizza la fine del registro, senza leggerne l'inizio ( tail -f)
• Cerca elementi nel file ( grep)
• Filtro per visualizzare solo elementi selezionati / interessanti (usando un'espressione di filtro arbitrariamente complicata)
• Invia il log via e-mail a qualcun altro che non ha il tuo software di log-file-decoder
• Copia e incolla un frammento del file di registro
• Leggere il file di registro mentre il programma (che crea il file di registro) è ancora in fase di sviluppo e debug
• Leggi i file di registro dalle vecchie versioni del software (che sono distribuiti sui siti dei clienti e in esecuzione).

Ovviamente il software può e usa anche formati di file binari (ad es. Per database relazionali) ma non vale la pena (in senso YAGNI ), di solito non vale la pena farlo, per i file di registro.

Ci sono molte presunzioni discutibili qui.

La registrazione è stata parte integrante di (quasi) tutti i lavori che ho svolto. È essenziale se si desidera qualsiasi tipo di visibilità sullo stato delle applicazioni. Dubito che sia un uso "marginale"; la maggior parte delle organizzazioni con cui sono stato coinvolto considera i log molto importanti.

Archiviare i registri come binari significa che è necessario decodificarli prima di poterli leggere. I registri di testo hanno la virtù della semplicità e della facilità d'uso. Se stai contemplando il percorso binario, puoi anche archiviare i log in un database, dove puoi interrogarli e analizzarli statisticamente.

Gli SSD sono più affidabili degli HDD al giorno d'oggi, e gli argomenti contro molte scritture sono in gran parte discutibili. Se sei davvero preoccupato, archivia i tuoi log su un normale HDD.

I file di registro sono una parte fondamentale di qualsiasi applicazione seria: se la registrazione nell'app è valida, ti permettono di vedere quali eventi chiave sono accaduti e quando; quali errori si sono verificati; e lo stato generale dell'applicazione che va al di là di qualsiasi monitoraggio sia stato progettato. È comune ascoltare un problema, controllare la diagnostica integrata dell'applicazione (aprire la sua console Web o utilizzare uno strumento di diagnostica come JMX), quindi ricorrere al controllo del log files.

Se usi un formato non testuale, ti trovi subito di fronte a un ostacolo: come leggi i registri binari? Con lo strumento di lettura dei registri, che non si trova sui tuoi server di produzione! O lo è, ma oh caro, abbiamo aggiunto un nuovo campo e questo è il vecchio lettore. Non l'abbiamo provato? Sì, ma nessuno lo ha implementato qui. Nel frattempo, lo schermo inizia a illuminarsi con gli utenti che eseguono il ping.

O forse questa non è la tua app, ma stai supportando e pensi di sapere che è questo altro sistema e WTF? i registri sono in formato binario? Ok, inizia a leggere le pagine wiki e da dove inizi? Ora li ho copiati sul mio computer locale, ma - sono corrotti? Ho effettuato una sorta di trasferimento non binario? O lo strumento di lettura del registro è incasinato?

In breve, gli strumenti di lettura del testo sono multipiattaforma e onnipresenti e i registri sono spesso di lunga durata e talvolta devono essere letti in fretta . Se inventi un formato binario, allora sei tagliato fuori da un intero mondo di strumenti ben compresi e facili da usare. Grave perdita di funzionalità proprio quando ne hai bisogno.

La maggior parte degli ambienti di registrazione presenta un compromesso: mantiene i registri correnti leggibili e presenti e comprime quelli più vecchi. Ciò significa che si ottiene il vantaggio della compressione, soprattutto perché un formato binario non riduce i messaggi di registro. Allo stesso tempo, è possibile utilizzare meno e grep e così via.

Quindi, quali possibili benefici potrebbero derivare dall'uso del binario? Una piccola quantità di efficienza spaziale - sempre meno importante. Meno (o più piccoli) scritti? Bene, forse - in realtà, il numero di scritture sarà correlato al numero di commit del disco, quindi se le linee di registro sono significativamente più piccole della dimensione del blocco del disco, un SSD assegnerebbe comunque nuovi blocchi più e più volte. Quindi, binario è una scelta appropriata se:

• stai scrivendo enormi quantità di dati strutturati
• i registri devono essere creati in modo particolarmente rapido
• è improbabile che tu debba analizzarli in "condizioni di supporto"

ma questo suona meno come la registrazione dell'applicazione; questi sono file di output o record di attività. Inserirli in un file è probabilmente solo a un passo dalla loro scrittura in un database.

MODIFICARE

Penso che qui ci sia una confusione generale tra "registri di programma" (come per i framework di registrazione) e "record" (come nei registri di accesso, record di accesso, ecc.). Sospetto che la domanda riguardi più da vicino quest'ultima, e in tal caso la questione è molto meno ben definita. È perfettamente accettabile che un record di messaggi o un registro attività sia in un formato compatto, soprattutto perché è probabile che sia ben definito e utilizzato per l'analisi piuttosto che per la risoluzione dei problemi. Gli strumenti che fanno questo includono tcpdumpe il monitor di sistema Unix sar. I registri dei programmi invece tendono ad essere molto più ad hoc.

Un esempio di registro un po 'binario è molto diffuso: il registro eventi di Windows. Dal punto di vista professionale, ciò consente ai messaggi di log di essere piuttosto prolissi (e quindi si spera utile) praticamente a costo zero, forse qualcosa di simile

Avvertenza: la coda di foobar da fare è cresciuta di 517 elementi negli ultimi 90 secondi. Se ciò accade circa una volta al giorno, non c'è nulla di cui preoccuparsi. Se succede più spesso o in rapida successione, potresti voler controllare la quantità di RAM disponibile per l'applicazione foobar. Se si verifica insieme all'evento 12345, tuttavia, sembra che tu stia utilizzando un database obsoleto e è meglio chiamare il supporto al numero + 1-555-12345 per prevenire la perdita di dati.

La parte principale di questo messaggio esiste solo una volta come risorsa installata con l'applicazione. Tuttavia, se questa risorsa non è installata correttamente (ad esempio perché nel frattempo è stata installata una versione più recente che non supporta più questo messaggio obsoleto), tutto ciò che vedi nel registro eventi è un messaggio standard che è solo una formulazione elaborata per

Non so, qualcosa con "517" e "90".

e non è più utile in alcun modo.

Le due domande principali che vorresti porre prima di scegliere tra testo e binario sono:

• Chi è il mio pubblico?
• Di quali contenuti ho bisogno per comunicare?

Un'opinione comune è che il pubblico di un messaggio di registro sia un essere umano. Questo ovviamente non è un presupposto perfetto, perché ci sono molti script per la scansione dei log là fuori, ma è comune. In questo caso, ha senso trasmettere le informazioni in un mezzo con cui gli umani sono a proprio agio. Il testo ha una lunga tradizione di essere questo mezzo.

Per quanto riguarda il contenuto, considera che un registro binario deve avere un formato ben definito. Il formato deve essere abbastanza ben definito per consentire ad altre persone di scrivere software che opera su quei registri. Alcuni registri sono abbastanza ben strutturati (la tua lista ne elenca diversi). Altri registri richiedono la capacità di trasmettere il contenuto in una forma di linguaggio naturale meno ben definita. Tali casi di linguaggio naturale sono una scarsa corrispondenza per i formati binari.

Per i registri che potrebbero essere ben descritti in binario, devi fare una scelta. Poiché il testo funziona per tutti, è spesso visto come la scelta predefinita. Se registri i risultati in testo, le persone possono lavorare con i tuoi registri. È stato dimostrato migliaia di volte. I file binari sono più complicati. Di conseguenza, è possibile che gli sviluppatori producano testo semplicemente perché tutti sanno come si comporterà.

TL; DR: le dimensioni non contano davvero, ma la praticità d'uso lo fa

Prima di tutto, pur confrontando i rispettivi vantaggi dei formati di testo e binari per la memorizzazione dei registri a breve termine è una domanda importante, le dimensioni non contano davvero. Le due ragioni sono:

1. I registri sono informazioni altamente ridondanti che si comprimono molto bene: nella mia esperienza non è raro vedere file di registro compressi la cui dimensione è del 5% o inferiore alla dimensione del file originale. Di conseguenza, l'uso di un testo o di un formato binario non dovrebbe avere alcun impatto misurabile sull'archiviazione a lungo termine dei registri.

2. Qualunque sia il formato scelto, i registri riempiranno rapidamente un disco del server se non implementiamo un "sink di file di registro" che comprime e invia i file di registro a una piattaforma di archiviazione a lungo termine. L'uso di un formato binario potrebbe rallentare un po 'questo, ma anche un cambiamento di un fattore 10 non avrebbe molta importanza.

Formati di testo rispetto al registro binario

La promessa dei sistemi Unix è che, se impariamo a usare il set di strumenti standard che lavora su file di testo strutturati in linee - come grep , sort , join , sed e awk - saremo in grado di usarli per assemblare rapidamente prototipi eseguendo qualsiasi lavoro vogliamo, anche se lentamente e rozzamente. Una volta che il prototipo ha dimostrato la sua utilità, possiamo scegliere di trasformarlo in un software davvero ingegnerizzato per ottenere prestazioni o aggiungere altre utili funzionalità. Questa è, almeno secondo la mia comprensione, l'essenza della filosofia Unix.

Per dirla in altro modo, se probabilmente avremo bisogno di eseguire trattamenti e analisi che non possiamo capire oggi, se non sappiamo chi dovrebbe implementare questa analisi, ecc., Allora siamo nella fase in cui i prototipi dovrebbero essere usati e formati di testo per i registri sono probabilmente ottimali. Se abbiamo bisogno di eseguire ripetutamente una piccola serie di trattamenti ben identificati, allora siamo nella situazione in cui dovremmo progettare un sistema software perenne per eseguire questa analisi e probabilmente i formati binari o strutturati per i registri, come i database relazionali, saranno ottimale.

(Qualche tempo fa, ho scritto un post sul blog a riguardo.)

I file di registro sono in formato testo perché possono essere facilmente letti utilizzando qualsiasi tipo di editor di testo o visualizzando i contenuti tramite il comando della console.

Tuttavia, alcuni file di registro sono in formato binario se sono presenti molti dati. Ad esempio, il prodotto su cui sto lavorando memorizza un massimo di 15000 record. Al fine di memorizzare i record nella minima quantità di spazio, vengono archiviati in binario. Tuttavia, è necessario scrivere un'applicazione speciale per visualizzare i record o convertirli in un formato utilizzabile (ad esempio fogli di calcolo).

In sintesi, non tutti i file di registro sono in formato testuale. Il formato testuale ha il vantaggio che non sono necessari strumenti personalizzati per visualizzare il contenuto. Dove ci sono molti dati, il file potrebbe essere in formato binario . Il formato binario avrà bisogno di un'applicazione (personalizzata) per leggere i dati e visualizzarli in un formato leggibile dall'uomo. Più dati possono essere impacchettati in un formato binario. L'utilizzo del formato testuale o binario è una decisione basata sulla quantità di dati e sulla facilità di visualizzazione dei contenuti.

Nei sistemi embedded in cui potrei non avere un canale di output disponibile durante il runtime, l'applicazione non può permettersi il colpo di velocità imposto dalla registrazione, oppure la registrazione altererebbe o maschererebbe l'effetto che sto cercando di registrare, spesso ricorreva al riempimento dei dati binari in un array o ad un buffer ad anello e alla stampa o alla stampa al termine dell'esecuzione del test o al dumping di dati grezzi e alla scrittura di un interprete per stamparli come leggibili. Ad ogni modo, voglio finire con dati leggibili.

Nei sistemi con più risorse, perché inventare schemi per ottimizzare ciò che non necessita di ottimizzazione?

I file di registro hanno lo scopo di facilitare il debug di problemi. In genere, lo spazio sul disco rigido è molto più economico del tempo di progettazione. I file di registro usano il testo perché ci sono molti strumenti per lavorare con il testo (come tail -f). Anche HTTP utilizza il testo normale (vedi anche perché non inviamo file binari anziché testo su http ).

Inoltre, è più economico sviluppare un sistema di registrazione in testo normale e verificarne il funzionamento, semplificare il debug in caso di errore e recuperare più facilmente qualsiasi informazione utile nel caso in cui il sistema non funzioni e danneggi parte del registro.

Un file di testo danneggiato è ancora leggibile attorno alla parte danneggiata. Un file binario danneggiato può essere ripristinato, ma potrebbe anche non esserlo. Anche se è ripristinabile, richiederebbe un po 'più di lavoro. L'altro motivo è che un formato di registrazione binario rende meno probabile che durante una corsa per creare una "correzione temporanea" (aka "la più permanente di tutte le correzioni") la soluzione di registrazione verrà utilizzata invece di qualcosa che può essere creato più rapidamente.

Contiamo sui test unitari per ottenere e mantenere la robustezza del nostro software. (La maggior parte del nostro codice viene eseguito in un server, senza testa; l'analisi post-operazione dei file di registro è una strategia chiave.). Quasi tutte le classi della nostra implementazione eseguono alcune registrazioni. Una parte importante del nostro test di unità è l'uso di logger "finti" che vengono utilizzati durante i test di unità. Un unit test crea un finto logger e lo fornisce all'elemento da testare. Quindi (quando utile / appropriato) analizza ciò che è stato registrato (in particolare errori e avvisi). L'uso di un formato di registro basato su testo rende tutto molto più semplice per le stesse ragioni delle analisi eseguite su registri "reali": ci sono più strumenti a tua disposizione che sono rapidi da usare e adattare.

Storicamente, i registri erano registrazioni ufficiali, scritte a mano e sequenziali di eventi. Quando i macchinari sono stati in grado di registrare eventi, questi sono stati scritti su un dispositivo di output cartaceo come una stampante di teletype, che ha prodotto un record sequenziale permanente ma che poteva solo elaborare il testo e occasionalmente suonare un BELL ...

Ai miei tempi da mainframe, abbiamo usato un formato di registro binario personalizzato. Il motivo principale non era di risparmiare spazio, era perché volevamo che il registro occupasse spazio finito sovrascrivendo le voci vecchie con quelle nuove; l'ultima cosa che volevamo era non essere in grado di diagnosticare i problemi causati dall'esaurimento dei dischi (nel 1980 lo spazio su disco costava $ 1000 / Mb, quindi le persone non compravano più del necessario).

Ora mi piace ancora l'idea di un file di registro circolare, e se i sistemi operativi offrissero una tale bestia lo userei senza esitazione. Ma il binario era una cattiva idea. Non devi davvero perdere tempo a trovare i comandi giusti per decifrare un file di registro quando hai un problema critico da risolvere.