Por que a maioria dos arquivos de log usa texto sem formatação em vez de um formato binário?

O log é algo que é necessário, mas é (relativamente) raramente usado. Como tal, pode ser muito mais compacto em termos de armazenamento.

Por exemplo, os dados mais comumente registrados como ip, data, hora e outros dados que podem ser representados como um número inteiro estão sendo armazenados como texto.

Se o registro fosse armazenado como dados binários, muito espaço poderia ser preservado, exigindo menos rotação e aumentando a vida útil do disco, especialmente com SSDs onde as gravações são limitadas.

Alguns podem dizer que é uma questão tão pequena que realmente não importa, mas, considerando o esforço necessário para construir esse mecanismo, não faz sentido não fazê-lo. Qualquer um pode fazer isso por dois dias no seu tempo livre, por que as pessoas não fazem isso?

systemdfamosa armazena seus arquivos de log em formato binário. Os principais problemas que ouvi foram:

1. se o log for corrompido, é difícil recuperar, pois precisa de ferramentas especializadas
2. eles não são legível, para que você não pode usar ferramentas padrão, como vi, grep, tailetc para analisá-los

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

Eu argumentaria que a vantagem do espaço em disco é relativamente pequena (e diminuindo) na prática. Se você deseja armazenar grandes quantidades de logs, compactar os logs compactados é realmente bastante eficiente.

No geral, as vantagens de ferramentas e familiaridade provavelmente errariam no lado do log de texto na maioria dos casos.

Por que a maioria dos arquivos de log usa texto sem formatação em vez de um formato binário?

Pesquise a palavra "texto" no artigo da Wikipedia sobre filosofia Unix , por exemplo, você encontrará declarações como:

McIlroy, então chefe do Bell Labs CSRC (Centro de Pesquisa em Ciências da Computação) e inventor do tubo Unix, [9] resumiu a filosofia do Unix da seguinte forma: [10]

Esta é a filosofia do Unix: escreva programas que fazem uma coisa e fazem bem. Escreva programas para trabalhar juntos. Escreva programas para lidar com fluxos de texto, porque essa é uma interface universal.

Ou, por exemplo, em Fundamentos da filosofia Unix ,

Regra de composição: crie programas para serem conectados com outros programas.

É difícil evitar a programação de monólitos complicados, se nenhum dos seus programas puder se comunicar.

A tradição Unix incentiva fortemente a escrita de programas que leem e escrevem formatos simples, textuais, orientados a fluxo e independentes de dispositivo. No Unix clássico, o maior número possível de programas é gravado como filtros simples, que recebem um fluxo de texto simples na entrada e o processam em outro fluxo de texto simples na saída.

Apesar da mitologia popular, essa prática é preferida não porque os programadores Unix odeiam interfaces gráficas de usuário. É porque se você não escreve programas que aceitam e emitem fluxos de texto simples, é muito mais difícil conectar os programas.

Os fluxos de texto são para ferramentas Unix, assim como as mensagens são para objetos em uma configuração orientada a objetos. A simplicidade da interface de fluxo de texto impõe o encapsulamento das ferramentas. Formas mais elaboradas de comunicação entre processos, como chamadas de procedimentos remotos, mostram uma tendência a envolver demais os programas com os internos.

Qualquer um pode fazer isso por 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 o arquivo de log inteiro ( edit)
• Exibir o final do log, sem ler o início ( tail -f)
• Procure coisas no arquivo ( grep)
• Filtre para exibir apenas itens selecionados / interessantes (usando uma expressão de filtro arbitrariamente complicada)
• Envie o log por email para outra pessoa que não possua seu software de decodificador de arquivos 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 os arquivos de log das versões antigas do software (implantadas nos sites dos clientes e em execução).

Obviamente, o software também pode usar formatos de arquivos binários (por exemplo, para bancos de dados relacionais), mas não vale a pena (no sentido YAGNI ), geralmente não vale a pena, para arquivos de log.

Existem muitas presunções discutíveis aqui.

O log tem sido parte integrante de (quase) todos os trabalhos que tive. É essencial se você deseja algum tipo de visibilidade sobre a saúde de seus aplicativos. Duvido que seja um uso "marginal"; a maioria das organizações com as quais me envolvi considera os logs muito importantes.

Armazenar logs como binários significa que você deve decodificá-los antes de poder lê-los. Os logs de texto têm a virtude da simplicidade e facilidade de uso. Se você estiver contemplando a rota binária, também poderá armazenar logs em um banco de dados, onde poderá interrogá-los e analisá-los estatisticamente.

Atualmente, os SSDs são mais confiáveis ​​do que os HDDs, e os argumentos contra muitas gravações são amplamente discutidos. Se você estiver realmente preocupado com isso, armazene seus logs em um disco rígido comum.

Os arquivos de log são uma parte crítica de qualquer aplicativo sério: se o login no aplicativo for bom, eles permitem que você veja quais eventos importantes aconteceram e quando; que erros ocorreram; e integridade geral do aplicativo que vai além do monitoramento projetado. É comum ouvir sobre um problema, verificar os diagnósticos internos do aplicativo (abrir o console da Web ou usar uma ferramenta de diagnóstico como JMX) e, em seguida, recorrer à verificação do arquivos de log.

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

Ou talvez esse não seja o seu aplicativo, mas você está dando suporte e acha que sabe que é esse outro sistema e o WTF? os logs estão em um formato binário? Ok, comece a ler as páginas da wiki e por onde começar? Agora eu os copiei na 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 log está desarrumada?

Em resumo, as ferramentas de leitura de texto são multiplataforma e onipresentes, e os logs geralmente têm vida longa e às vezes precisam ser lidos às pressas . Se você inventa um formato binário, fica isolado de um mundo inteiro de ferramentas bem compreendidas e fáceis de usar. Grave perda de funcionalidade exatamente quando você precisar.

A maioria dos ambientes de log é comprometida: mantenha os logs atuais legíveis e presentes e comprima os mais antigos. Isso significa que você obtém o benefício da compactação - mais ainda, porque um formato binário não diminui 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 mais sem importância. Menos gravações (ou menores)? Bem, talvez - na verdade, o número de gravações esteja relacionado ao número de confirmações de disco; portanto, se as linhas de log forem significativamente menores que o tamanho do bloco de disco, um SSD estaria atribuindo novos blocos repetidamente. Portanto, binário é uma escolha apropriada se:

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

mas isso parece menos com o log de aplicativos; esses são arquivos de saída ou registros de atividades. Colocá-los em um arquivo provavelmente está apenas a um passo de gravá-los em um banco de dados.

EDITAR

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

Um exemplo de um log um tanto binário é amplo: o log de eventos do Windows. Do lado profissional, isso permite que as mensagens de log sejam bastante prolixo (e, portanto, esperançosamente úteis) a praticamente nenhum custo, possivelmente algo como

Aviso: a fila de foobars a fazer cresceu 517 itens nos últimos 90 segundos. Se isso acontecer uma vez por dia, não há com o que se preocupar. Se isso acontecer com mais frequência ou em rápida sucessão, convém verificar a quantidade de RAM disponível para o aplicativo foobar. Se ocorrer junto com o evento 12345, no entanto, você parece estar usando um banco de dados obsoleto e é melhor chamar o suporte em + 1-555-12345 para impedir a perda de dados.

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 um texto sofisticado para

Não sei, algo com "517" e "90".

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

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

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

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

Quanto ao conteúdo, considere que um log binário deve ter um formato bem definido. O formato deve ser bem definido o suficiente para que outras pessoas escrevam software que opera nesses logs. Alguns logs são muito bem estruturados (sua pergunta lista vários). Outros logs precisam da capacidade de transmitir conteúdo em um formato de linguagem natural menos bem definido. Esses casos de linguagem natural são pouco compatíveis com os formatos binários.

Para os logs que poderiam ser bem descritos em binário, você deve fazer uma escolha. Como o texto funciona para todos, geralmente é visto como a opção padrão. Se você registrar seus resultados em texto, as pessoas poderão trabalhar com seus registros. Foi 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 será o comportamento.

TL; DR: o tamanho não importa, mas a conveniência do uso

Antes de tudo, embora seja uma questão importante comparar as respectivas vantagens dos formatos de texto e binários para armazenamento de log de curto prazo, o tamanho não importa. As duas razões para isso são:

1. Logs são informações altamente redundantes que compactam muito bem: na minha experiência, não é raro ver arquivos de log compactados cujo tamanho é 5% ou menos do tamanho do arquivo original. Conseqüentemente, o uso de um formato de texto ou binário não deve ter nenhum impacto mensurável no armazenamento de logs de longa data.

2. Qualquer que seja o formato escolhido, os logs preencherão rapidamente um disco do servidor se não implementarmos um “coletor de arquivos de log” que comprima e envie os arquivos de log para uma plataforma de armazenamento de longo prazo. O uso de um formato binário pode retardar um pouco isso, mas mesmo uma alteração de um fator 10 não importa muito.

Formatos de log de texto versus binários

A promessa dos sistemas Unix é que, se aprendermos a usar o conjunto de ferramentas padrão que trabalha em arquivos de texto estruturados em linhas - como grep , classificar , ingressar , sed e awk - seremos capazes de usá-los para montar rapidamente protótipos executando qualquer trabalho queremos, ainda que lenta e grosseiramente. Uma vez que o protótipo demonstre sua utilidade, podemos optar por transformá-lo em um software realmente projetado para obter desempenho ou adicionar outros recursos úteis. Esta é, pelo menos no meu entendimento, a essência da filosofia Unix.

Dito de outra forma, se provavelmente precisamos realizar tratamentos e análises, não podemos descobrir até hoje, se não sabemos quem deve implementar essa análise etc. etc., estamos no estágio em que protótipos devem ser usados ​​e formatos de texto para os logs provavelmente são ótimos. Se precisarmos executar repetidamente um pequeno conjunto de tratamentos bem identificados, estaremos na situação em que devemos projetar um sistema de software perene para executar essa análise e os formatos binários ou estruturados de logs, como bancos de dados relacionais, provavelmente serão ótimo.

(Há algum tempo, escrevi um post sobre isso.)

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

No entanto, alguns arquivos de log estão em formato binário se houver muitos dados. Por exemplo, o produto em que estou trabalhando armazena no máximo 15000 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 no formato textual. O formato textual tem uma vantagem de que não são necessárias ferramentas personalizadas 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 exibir em um formato legível por humanos. Mais dados podem ser compactados em um formato binário. A utilização do formato textual ou binário é uma decisão baseada na quantidade de dados e na facilidade de visualização do conteúdo.

Em sistemas incorporados nos quais eu posso não ter um canal de saída disponível durante o tempo de execução, o aplicativo não pode permitir a velocidade atingida imposta pelo registro, ou o registro alteraria ou ocultaria o efeito que estou tentando gravar, geralmente recorreu ao empacotamento de dados binários em uma matriz ou em um buffer de anel, e imprimiu-os no final do teste ou despejou-os em bruto e gravou um intérprete para imprimi-los como legíveis. De qualquer forma, quero terminar 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 destinam-se 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). Até o HTTP usa texto sem formatação (veja também por que não enviamos binário ao invés de texto em http ).

Além disso, é mais barato desenvolver um sistema de log de texto sem formatação e verificar se ele 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 pode ser lido na parte corrompida. Um arquivo binário corrompido pode ser restaurado, mas também pode não ser. Mesmo se for restaurável, 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" (aka "a mais permanente de todas as correções"), a solução de log seja usada em vez de algo que pode ser criado mais rapidamente.

Contamos com testes de unidade para obter e manter a robustez do nosso software. (A maioria do nosso código é executado em um servidor, sem cabeçalho; a análise pós-operação dos arquivos de log é uma estratégia importante.). Quase todas as classes em nossa implementação fazem algum log. Uma parte importante de nossos testes de unidade é o uso de registradores 'simulados' usados ​​nos testes de unidade. Um teste de unidade cria um logger simulado e o fornece ao item que está sendo testado. Em seguida (quando útil / apropriado) analisa o que foi registrado (especialmente erros e avisos). O uso de um formato de log baseado em texto facilita muito isso pelas mesmas razões que as análises realizadas em logs 'reais': existem mais ferramentas à sua disposição que são rápidas de usar e adaptar.

Historicamente, os Logs eram registros oficiais, manuscritos e seqüenciais de eventos. Quando o maquinário se tornou capaz de registrar eventos, estes foram gravados em um dispositivo de saída impressa, como uma impressora de teletipo, que produzia um registro seqüencial permanente, mas que só podia processar texto e, ocasionalmente, tocar uma campainha ...

Nos meus dias de mainframe, usamos um formato de log binário personalizado. O principal motivo não foi para economizar espaço, porque queríamos que o log ocupasse espaço finito substituindo entradas antigas por novas; a última coisa que queríamos era ser incapaz de diagnosticar problemas causados ​​por discos cheios (em 1980, o espaço em disco custava US $ 1000 / Mb, para que as pessoas não comprassem mais do que precisavam).

Agora, ainda gosto da idéia de um arquivo de log circular e, se os sistemas operacionais oferecerem uma fera, eu o usaria sem hesitação. Mas binário era uma má ideia. Você realmente não quer perder tempo encontrando os comandos certos para decifrar um arquivo de log quando tiver um problema crítico a resolver.