Perché la maggior parte dei file di registro utilizza solo testo normale piuttosto che un formato binario?

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

1. se il log viene danneggiato è difficile da ripristinare in quanto necessita di strumenti specializzati
2. non sono leggibili dall'uomo, quindi non puoi usare strumenti standard come vi , grep , tail ecc per analizzarli

Il motivo principale per l'utilizzo di un formato binario (a mia conoscenza) è che è stato ritenuto più facile per la creazione di indici, ecc. per trattarlo più come un file di database.

Direi che il vantaggio dello spazio su disco è relativamente piccolo (e in diminuzione) nella pratica. Se si desidera archiviare grandi quantità di registrazione, la compressione dei registri compressi è davvero molto efficiente.

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

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

Cerca la parola "testo" nella filosofia Unix di Wikipedia, ad esempio troverai affermazioni come:

McIlroy, then head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe,[9] summarized the Unix philosophy as follows:[10]

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

O ad esempio, da Nozioni di base sulla filosofia Unix ,

Rule of Composition: Design programs to be connected with other programs.

It's hard to avoid programming overcomplicated monoliths if none of your programs can talk to each other.

Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. Under classic Unix, as many programs as possible are written as simple filters, which take a simple text stream on input and process it into another simple text stream on output.

Despite popular mythology, this practice is favored not because Unix programmers hate graphical user interfaces. It's because if you don't write programs that accept and emit simple text streams, it's much more difficult to hook the programs together.

Text streams are to Unix tools as messages are to objects in an object-oriented setting. The simplicity of the text-stream interface enforces the encapsulation of the tools. More elaborate forms of inter-process communication, such as remote procedure calls, show a tendency to involve programs with each others' internals too much.

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

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 log, senza leggerne l'inizio ( tail -f )
• Cerca elementi nel file ( grep )
• Filtra per visualizzare solo materiale selezionato / interessante (usando un'espressione di filtro arbitrariamente complicata)
• Invia il registro via email a qualcun altro che non ha il tuo software di decodifica file di registro
• Copia e incolla un frammento del file di registro
• Leggi 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 da vecchie versioni del software (che vengono distribuite sui siti dei clienti e in esecuzione).

Ovviamente il software può e utilizza anche i formati di file binari (ad esempio per i database relazionali) ma non ne vale la pena (in un YAGNI senso), di solito non vale la pena fare, per i file di registro.

Qui ci sono molte supposizioni discutibili.

La registrazione è stata parte integrante di (quasi) ogni lavoro che ho svolto. È essenziale se si desidera una visibilità sulla salute delle applicazioni. Dubito che sia un uso "marginale"; la maggior parte delle organizzazioni con cui sono stato coinvolto considerano i registri molto importanti.

Memorizzare i log come binari significa che devi decodificarli prima di poterli leggere. I registri di testo hanno il pregio della semplicità e della facilità d'uso. Se stai pensando al percorso binario, puoi anche memorizzare i registri 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, salva i tuoi registri su un normale HDD.

I file di log sono una parte critica di qualsiasi applicazione seria: se l'accesso all'app è buono, ti permettono di vedere quali eventi chiave sono accaduti e quando; quali errori si sono verificati; e salute generale dell'applicazione che va oltre il monitoraggio in cui è stato progettato. È comune sentire un problema, controllare la diagnostica integrata dell'applicazione (aprire la relativa console Web o utilizzare uno strumento diagnostico come JMX), quindi ricorrere al controllo file di registro.

Se utilizzi un formato non di testo, ti trovi immediatamente di fronte a un ostacolo: come leggi i log binari? Con lo strumento di lettura dei registri, che non è sui server di produzione! O lo è, ma cara, abbiamo aggiunto un nuovo campo e questo è il vecchio lettore. Non abbiamo provato questo? Sì, ma nessuno l'ha installato qui. Nel frattempo, lo schermo si sta accendendo con gli utenti che eseguono il ping.

O forse questa non è la tua app, ma stai facendo supporto 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 fatto qualche tipo di trasferimento non binario? O lo strumento di lettura dei log è incasinato?

In breve, gli strumenti di lettura del testo sono multipiattaforma e ubiquitaria, ei log sono spesso longevi e talvolta devono essere letti in fretta . Se inventi un formato binario, 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 logging raggiunge un compromesso: mantenere i log correnti leggibili e presenti e comprimere quelli più vecchi. Ciò significa che si ottiene il vantaggio della compressione, tanto più che un formato binario non riduce i messaggi di registro. Allo stesso tempo, puoi usare meno e grep e così via.

Quindi, quali possibili benefici potrebbero derivare dall'uso di binari? Una piccola quantità di efficienza nello spazio - sempre meno importante. Meno scritture (o più piccole)? Beh, forse - in realtà, il numero di scritture si riferirà al numero di commit del disco, quindi se le linee di log sono significativamente più piccole del blocco del disco, allora un SSD assegnerebbe sempre nuovi blocchi. Quindi, il binario è una scelta appropriata se:

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

ma sembra meno simile alla registrazione dell'applicazione; questi sono file di output o record di attività. Inserirli in un file è probabilmente solo ad un passo dal loro inserimento in un database.

Modifica

Penso che qui ci sia una confusione generale tra "registri di programma" (come per i quadri di registrazione) rispetto a "record" (come nei registri di accesso, nei record di accesso ecc.). Sospetto che la domanda si riferisca più da vicino a quest'ultima, e in tal caso il problema è molto meno definito. È perfettamente accettabile che un registro di messaggi o di attività sia in un formato compatto, soprattutto perché è probabile che sia ben definito e utilizzato per l'analisi anziché per la risoluzione dei problemi. Gli strumenti che fanno questo includono tcpdump e il sistema Unix monitora sar . I registri del programma, d'altro canto, 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 del pro, questo permette ai messaggi di log di essere abbastanza verbosi (e quindi si spera che siano utili) virtualmente senza alcun costo, possibilmente qualcosa di simile

Warning: The queue of foobars to do has grown by 517 items over the last 90 seconds. If this happens about once per day, there is nothing to worry about. If it happens more often or in rapid succession, you may want to check the amount of RAM available to the foobar application. If it occurs together with event 12345, however, you seem to be using an obsolete database and you better call support at +1-555-12345 in order to prevent data loss.

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, poiché 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 un testo di fantasia per

Dunno, something with "517" and "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?
• Quali contenuti devo trasmettere?

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

Per quanto riguarda il contenuto, considera che un log binario deve avere un formato ben definito. Il formato deve essere sufficientemente definito per consentire ad altre persone di scrivere software che opera su tali registri. Alcuni registri sono abbastanza ben strutturati (la tua domanda ne elenca parecchi). Altri log hanno bisogno della capacità di trasmettere contenuti in una forma di linguaggio naturale meno ben definita. Tali casi di linguaggio naturale sono una combinazione inadeguata per i formati binari.

Per i log 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 generino testo semplicemente perché tutti sanno come si comportano.

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

Prima di tutto, mentre confrontare i rispettivi vantaggi dei formati di testo e binari per la memorizzazione dei registri a breve termine è una questione importante, le dimensioni non contano davvero. I due motivi per questo 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 è pari o inferiore al 5% delle dimensioni del file originale. Di conseguenza, l'utilizzo di un testo o di un formato binario non dovrebbe avere alcun impatto misurabile sulla memorizzazione a lungo termine dei log.

2. Indipendentemente dal formato scelto, i registri riempiono rapidamente un disco del server se non implementiamo un "sink dei 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 sarebbe poi così importante.

Formati del registro di testo rispetto a quelli binari

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 , unisciti a , sed e awk - saremo in grado di usarli per assemblare rapidamente prototipi eseguendo qualsiasi lavoro che vogliamo, anche se lentamente e in modo grossolano. Una volta che il prototipo ha dimostrato la sua utilità, possiamo scegliere di trasformarlo in un software veramente ingegnerizzato per ottenere prestazioni o aggiungere altre funzionalità utili. Questo è, almeno a mio avviso, l'essenza della filosofia Unix.

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

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

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

Tuttavia, alcuni file di registro sono nel formato binario se vi sono molti dati. Ad esempio, il prodotto su cui sto lavorando memorizza un massimo di 15000 record. Per archiviare i record nella minor quantità di spazio, vengono memorizzati in binario. Tuttavia, è necessario scrivere un'applicazione speciale per visualizzare i record o convertirli in un formato che può essere utilizzato (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 può essere nel 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. Se utilizzare il formato testuale o il formato 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 uscita disponibile durante il run-time, l'applicazione non può permettersi il colpo di velocità imposto dal logging, o la registrazione altererebbe o maschererebbe l'effetto che sto provando a registrare, I Spesso ho fatto ricorso a riempire dati binari in un array o un buffer ad anello, e sia a printf () che alla fine dell'esecuzione di test oa scaricarlo in modo raw e a scrivere un interprete per stamparlo come leggibile. Ad ogni modo, voglio finire con dati leggibili.

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

I file di registro hanno lo scopo di aiutare il debug dei problemi. In genere, lo spazio su 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 l'HTTP utilizza il solo testo (vedi anche perché non inviamo binari in giro invece del testo su http ).

Inoltre, è più economico sviluppare un sistema di registrazione in testo normale e verificare che funzioni, sia più facile eseguire il debug in caso di errore e sia più facile recuperare tutte le informazioni utili nel caso in cui il sistema fallisca e corrompe parte del log.

Un file di testo danneggiato è ancora leggibile attorno alla parte danneggiata. Un file binario corrotto 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 alla creazione di una "correzione temporanea" (ovvero "la più permanente di tutte le correzioni") la soluzione di registrazione venga utilizzata al posto di qualcosa che può essere creato più rapidamente.

Contiamo sui test unitari per raggiungere e mantenere la robustezza del nostro software. (La maggior parte del nostro codice gira su un server, senza testa, l'analisi post-operazione dei file di registro è una strategia chiave.). Quasi ogni classe nella nostra implementazione esegue alcuni logging. Una parte importante del nostro test unitario è l'uso di logger "simulati" che vengono utilizzati durante il test dell'unità. Un test unitario crea un logger fittizio e lo fornisce all'elemento da testare. Quindi (quando utile / appropriato) analizza ciò che viene registrato (in particolare errori e avvisi). L'utilizzo di un formato di registro basato su testo rende questo molto più semplice per gli stessi motivi per cui le analisi sono state eseguite sui log "reali": ci sono più strumenti a disposizione che sono rapidi da usare e adattare.

Storicamente, i registri erano documenti ufficiali, scritti 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 teletype, che ha prodotto un record sequenziale permanente ma che poteva elaborare solo il testo e occasionalmente suonare un BELL ...

Nei giorni del mio mainframe, abbiamo usato un formato di log binario progettato su misura. Il motivo principale non era quello di risparmiare spazio, era perché volevamo che il log occupasse uno spazio finito sovrascrivendo le vecchie voci con quelle nuove; l'ultima cosa che volevamo era non essere in grado di diagnosticare i problemi causati dai dischi pieni (nel 1980 lo spazio su disco utilizzato costava $ 1000 / Mb, quindi la gente non comprava più del necessario).

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