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?
Em suma, as ferramentas de leitura de texto são multi-plataforma e onipresentes, e os logs são geralmente de longa duração e às vezes precisam ser lidos rapidamente. Se você inventar um formato binário, então você está cortado de um mundo inteiro de ferramentas bem entendidas e fáceis de usar. Perda grave de funcionalidade apenas quando você precisar.
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.