Por que a maioria dos arquivos de log usa texto simples em vez de um formato binário?

systemd famosamente armazena seus arquivos de log em formato binário. As principais questões que ouvi com ele são:

1. se o registro for corrompido, é difícil recuperá-lo, pois ele precisa de ferramentas especializadas
2. eles não são legíveis para humanos, então você não pode usar ferramentas padrão como vi , grep , tail etc para analisá-las

O principal motivo para usar um formato binário (que eu saiba) foi que ele foi considerado mais fácil para criar índices, etc., ou seja, tratá-lo mais como um arquivo de banco de dados.

Eu diria que a vantagem do espaço em disco é relativamente pequena (e diminuindo) na prática. Se você quiser armazenar grandes quantidades de log, a compactação de logs laminados é realmente muito eficiente.

Em suma, as vantagens do ferramental e da familiaridade provavelmente seriam erradas no lado do registro de texto na maioria dos casos.

Por que a maioria dos arquivos de log usa texto simples em vez de um formato binário?

Pesquise a palavra "texto" na filosofia Unix artigo da Wikipédia, por exemplo, você encontrará declarações como:

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.

Ou, por exemplo, no Noções básicas sobre a filosofia do 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.

Qualquer um pode fazer isso por uns dois dias no seu tempo livre, por que as pessoas não fazem isso?

Armazenar o arquivo de log em binário é apenas o começo (e trivial). Você precisaria escrever ferramentas para:

• Exibir todo o arquivo de log ( edit )
• Exibe o final do log, sem ler o início dele ( tail -f )
• Pesquise coisas no arquivo ( grep )
• Filtrar para exibir apenas itens selecionados / interessantes (usando uma expressão de filtro arbitrariamente complicada)
• Envie o log por e-mail para outra pessoa que não tenha seu software decodificador de registros de log
• Copie e cole um fragmento do arquivo de log
• Leia o arquivo de log enquanto o programa (que cria o arquivo de log) ainda está sendo desenvolvido e depurado
• Leia arquivos de registro de versões antigas do software (que são implantadas em sites de clientes e em execução).

Obviamente, o software pode e também usa formatos de arquivo binário (por exemplo, para bancos de dados relacionais), mas não vale a pena (em um YAGNI sentido), geralmente não vale a pena fazer, para arquivos de log.

Existem muitos pressupostos discutíveis aqui.

O registro de log foi parte integrante de (quase) todos os trabalhos que tive. É essencial se você quiser qualquer tipo de visibilidade sobre a integridade de seus aplicativos. Eu duvido que seja um uso "marginal"; A maioria das organizações com as quais estou envolvido considera os logs muito importantes.

Armazenando logs como um meio binário, você deve decodificá-los antes de poder lê-los. Logs de texto têm a virtude da simplicidade e facilidade de uso. Se você está contemplando a rota binária, você pode também armazenar logs em um banco de dados, onde você pode interrogá-los e analisá-los estatisticamente.

Os SSDs são mais confiáveis do que os HDDs hoje em dia, e os argumentos contra muitas gravações são muito discutíveis. Se você estiver realmente preocupado com isso, armazene seus registros em um disco rígido comum.

Os arquivos de log são uma parte essencial de qualquer aplicativo sério: se o login no aplicativo é bom, eles permitem que você veja quais eventos principais aconteceram e quando; que erros ocorreram; e saúde geral da aplicação que vai além de qualquer monitoração projetada. É comum ouvir sobre um problema, verificar o diagnóstico integrado do aplicativo (abrir seu console da web ou usar uma ferramenta de diagnóstico como o JMX) e recorrer à verificação do arquivos de log.

Se você usa um formato que não seja texto, você se depara imediatamente com um obstáculo: como você lê os registros binários? Com a ferramenta de leitura de registros, que não está nos seus servidores de produção! Ou é, mas, oh querida, adicionamos um novo campo e este é o antigo leitor. Não testamos isso? Sim, mas ninguém implantou aqui. Enquanto isso, sua tela está começando a se iluminar com os usuários fazendo ping em você.

Ou talvez este não seja seu aplicativo, mas você está fazendo suporte e acha que sabe que é esse outro sistema, e WTF? os logs estão em um formato binário? Ok, comece a ler as páginas wiki e por onde você começa? Agora eu os copiei para a minha máquina local, mas eles estão corrompidos? Eu fiz algum tipo de transferência não-binária? Ou a ferramenta de leitura de registros está bagunçada?

A maioria dos ambientes de registro cria um comprometimento: mantém os registros atuais legíveis e presentes e compacta os mais antigos. Isso significa que você obtém o benefício da compactação - mais ainda, porque um formato binário não reduziria as mensagens de log. Ao mesmo tempo, você pode usar menos e grep e assim por diante.

Então, quais possíveis benefícios podem surgir do uso de binário? Uma pequena quantidade de eficiência de espaço - cada vez menos importante. Menos (ou menor) escreve? Bem, talvez - na verdade, o número de gravações se relacionará ao número de commits de disco, portanto, se as linhas de log forem significativamente menores que o tamanho de blocos de disco, um SSD estaria atribuindo novos blocos repetidamente. Então, o binário é uma escolha apropriada se:

• você está escrevendo grandes quantidades de dados estruturados
• os logs precisam ser criados com rapidez
• é improvável que você precise analisá-los em "condições de suporte"

mas isso está soando menos como o log de aplicativos; estes são arquivos de saída ou registros de atividades. Colocá-los em um arquivo provavelmente é apenas um passo de escrevê-los em um banco de dados.

EDITAR

Eu acho que há uma confusão geral aqui entre "logs de programa" (como por estruturas de registro) vs "registros" (como em registros de acesso, registros de login, etc). Suspeito que a questão se relacione mais de perto com esta última e, nesse caso, a questão é muito menos bem definida. É perfeitamente aceitável que um registro de mensagens ou de atividades esteja em um formato compacto, especialmente porque é provável que seja bem definido e usado para análise, em vez de solução de problemas. As ferramentas que fazem isso incluem tcpdump e o monitor do sistema Unix sar . Os logs de programa, por outro lado, tendem a ser muito mais ad hoc.

Um exemplo de um log binário é amplo: o log de eventos do Windows. No lado profissional, isso permite que as mensagens de log sejam bastante verbosas (e, portanto, esperamos que sejam úteis) virtualmente sem nenhum custo, possivelmente algo como

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.

A parte principal desta mensagem existe apenas uma vez como um recurso instalado com o aplicativo. No entanto, se esse recurso não estiver instalado corretamente (por exemplo, porque enquanto uma versão mais recente foi instalada que não suporta mais essa mensagem obsoleta), tudo o que você vê no log de eventos é uma mensagem padrão que é apenas uma expressão sofisticada para

Dunno, something with "517" and "90".

e não é mais útil de alguma forma.

As duas perguntas principais que você gostaria de fazer antes de escolher entre texto e binário são:

• Quem é meu público?
• Qual conteúdo eu preciso transmitir?

Uma opinião comum é que o público de uma mensagem de log é um ser humano. Isso obviamente não é uma suposição perfeita, porque há muitos scripts de rastreamento de log por aí, mas é comum. Nesse caso, faz sentido transmitir a informação em um meio com o qual os humanos se sintam confortáveis. O texto tem uma longa tradição de ser esse meio.

Quanto ao conteúdo, considere que um log binário deve ter um formato bem definido. O formato deve estar bem definido o suficiente para que outras pessoas escrevam softwares que operam nesses registros. Alguns logs são bem estruturados (sua lista de perguntas é várias). Outros registros precisam da capacidade de transmitir conteúdo em um formato de linguagem natural menos bem definido. Esses casos de linguagem natural são uma correspondência ruim para formatos binários.

Para os logs que podem ser bem descritos em binário, você tem que fazer uma escolha. Como o texto funciona para todos, geralmente é visto como a escolha padrão. Se você registrar seus resultados em texto, as pessoas poderão trabalhar com seus registros. Está provado milhares de vezes. Arquivos binários são mais complicados. Como resultado, pode ser que os desenvolvedores produzam texto simplesmente porque todos sabem como isso vai se comportar.

TL; DR: O tamanho realmente não importa, mas a conveniência de uso é

1. Os logs são informações altamente redundantes que serão compactadas muito bem: na minha experiência, não é raro ver arquivos de log compactados cujo tamanho seja 5% ou menos do tamanho do arquivo original. Consequentemente, usar um texto ou um formato binário não deve ter qualquer impacto mensurável no armazenamento de logs de longo prazo.

2. Independentemente do formato que escolhermos, os logs preencherão rapidamente um disco do servidor se não implementarmos um “coletor de arquivos de log” que comprime e envia arquivos de log para uma plataforma de armazenamento de longo prazo. Usar um formato binário poderia retardar isso um pouco, mas mesmo uma mudança por um fator 10 não importaria muito.

Texto versus formatos de log binário

A promessa dos sistemas Unix é que, se aprendermos a usar o conjunto de ferramentas padrão trabalhando em arquivos de texto estruturados em linhas - como grep , classificar , join , sed e awk - nós poderemos usá-los para montar rapidamente protótipos executando qualquer trabalho que quisermos, ainda que de forma lenta e grosseira. Uma vez que o protótipo tenha demonstrado sua utilidade, podemos optar por transformá-lo em um software realmente projetado para ganhar desempenho ou adicionar outros recursos úteis. Isto é, pelo menos no meu entendimento, a essência da filosofia Unix.

Por outras palavras, se é provável que necessitemos de realizar tratamentos e análises que não podemos descobrir hoje, se não sabemos quem deve implementar esta análise, etc., então estamos na fase em que os protótipos devem ser usados e os formatos de texto para logs são provavelmente ótimos. Se precisamos executar repetidamente um pequeno conjunto de tratamentos bem identificados, então estamos na situação em que devemos projetar um sistema de software perene para realizar essa análise e formatos binários ou estruturados para logs, como bancos de dados relacionais, provavelmente ótimo.

(Algum tempo atrás, eu escrevi uma postagem no blog sobre isso.)

Os arquivos de log estão no formato de texto porque podem ser lidos facilmente usando qualquer tipo de editor de texto ou exibindo o conteúdo por meio do comando do console.

No entanto, alguns arquivos de log estão no formato binário se houver muitos dados. Por exemplo, o produto em que estou trabalhando armazena no máximo 15.000 registros. Para armazenar os registros na menor quantidade de espaço, eles são armazenados em binário. No entanto, um aplicativo especial deve ser gravado para exibir os registros ou convertê-los em um formato que possa ser usado (por exemplo, planilhas).

Em resumo, nem todos os arquivos de log estão em formato textual. O formato textual tem uma vantagem que as ferramentas personalizadas não são necessárias para visualizar o conteúdo. Onde há muitos dados, o arquivo pode estar no formato binário . O formato binário precisará de um aplicativo (personalizado) para ler os dados e exibi-los em um formato legível por humanos. Mais dados podem ser compactados em um formato binário. O uso de formato textual ou formato binário é uma decisão baseada na quantidade de dados e na facilidade de visualizar o conteúdo.

Em sistemas embarcados em que talvez eu não tenha um canal de saída disponível durante o tempo de execução, o aplicativo não pode arcar com o impacto de velocidade imposto pelo registro, ou o registro alteraria ou mascararia o efeito que estou tentando gravar, Muitas vezes recorreu-se ao preenchimento de dados binários em um array ou em um buffer de anel, e imprimi-lo no final do teste ou descarregá-lo em estado bruto e escrever um interpretador para imprimi-lo como legível. De qualquer maneira, quero acabar com dados legíveis.

Em sistemas com mais recursos, por que inventar esquemas para otimizar o que não precisa ser otimizado?

Os arquivos de log se destinam a ajudar na depuração de problemas. Normalmente, o espaço no disco rígido é muito mais barato que o tempo de engenharia. Os arquivos de log usam texto porque existem muitas ferramentas para trabalhar com texto (como tail -f ). Mesmo o HTTP usa texto sem formatação (veja também porque não enviamos binário ao invés de texto em http ).

Além disso, é mais barato desenvolver um sistema de log de texto simples e verificar se funciona, mais fácil de depurar se der errado e mais fácil recuperar qualquer informação útil caso o sistema falhe e corrompa parte do log.

Um arquivo de texto corrompido ainda é legível em torno da parte corrompida. Um arquivo binário corrompido pode ser restaurado, mas também pode não ser. Mesmo se for restaurável, isso exigiria um pouco mais de trabalho. A outra razão é que um formato de log binário torna menos provável que durante uma corrida para criar uma "correção temporária" (também conhecida como "a mais permanente de todas as correções") a solução de log será usada em vez de algo que pode ser criado mais rapidamente.

Contamos com testes unitários para obter e manter a robustez do nosso software. (A maior parte do nosso código é executada em um servidor, sem cabeça; a análise pós-operação dos arquivos de log é uma estratégia fundamental.). Quase todas as classes em nossa implementação fazem alguns registros. Uma parte importante do nosso teste unitário é o uso de loggers 'simulados' que são usados quando testamos a unidade. Um teste de unidade cria um logger simulado e o fornece ao item que está sendo testado. Então (quando útil / apropriado) analisa o que foi registrado (especialmente erros e avisos). Usar um formato de registro baseado em texto torna isso muito mais fácil, pelos mesmos motivos que as análises realizadas em logs 'reais': há mais ferramentas à sua disposição que são rápidas de usar e adaptar.

Historicamente, os registros eram registros oficiais, escritos à mão e seqüenciais de eventos. Quando o maquinário tornou-se capaz de registrar eventos, eles foram gravados em um dispositivo de saída de cópia impressa, como uma impressora de teletipo, que produzia um registro sequencial permanente, mas que só processava texto e ocasionalmente tocava um BELL ...

De volta aos meus dias de mainframe, usamos um formato de log binário personalizado. A principal razão não foi para economizar espaço, foi porque queríamos que o log ocupasse um espaço finito sobrescrevendo entradas antigas por novas; a última coisa que queríamos era ser incapaz de diagnosticar problemas causados pelo fato de os discos ficarem cheios (em 1980, o espaço em disco custava US $ 1.000 / Mb, então as pessoas não compravam mais do que precisavam).

Agora, ainda gosto da ideia de um arquivo de log circular e, se os sistemas operacionais oferecessem esse animal, eu o usaria sem hesitação. Mas binário foi uma má ideia. Você realmente não quer perder tempo procurando os comandos certos para decifrar um arquivo de log quando tiver um problema crítico a ser resolvido.