Por que o sistema de arquivos é preferido para logs em vez de RDBMS?

1. Muitas coisas podem falhar com o banco de dados e registrar essas falhas também é importante.

2. A menos que você tenha um sistema de banco de dados que permita transações autônomas (ou nenhuma transação), o registro exigiria uma conexão separada para que uma reversão ou confirmação no registro não interfira na reversão ou confirmação no aplicativo.

3. Muitas coisas que valem a criação de logs acontecem durante a inicialização, ou seja, possivelmente antes que a conexão com o banco de dados tenha sido estabelecida.

4. No que pode ser uma configuração típica, um novo arquivo de log é criado todos os dias, arquivos de log antigos são compactados e mantidos por duas semanas, antes de serem excluídos. Não é fácil fazer o mesmo em um RDBMS.

Já vi logs gravados no banco de dados antes (e às vezes você tem opções configuráveis para registro, onde o rastreio vai para o arquivo, erros para o banco de dados, fatais para o log de eventos do Windows).

Os principais motivos são velocidade e tamanho, permitindo que alguns rastreamentos possam produzir vastas e vastas qualidades de registro - pesquisei por tamanho de gigabytes de arquivos de log. A outra razão principal é que a leitura dos logs precisa ser sequencial, não há necessidade real de consultar o log, exceto para encontrar um certo erro ou entrada - e o find-in-file funciona perfeitamente bem para isso.

A velocidade é um dos motivos; outros são:

• Eliminando pontos de falha. Um sistema de arquivos raramente falha em condições em que um DBMS não funcionaria, mas há muitas e muitas condições de erro em bancos de dados que não existem em sistemas de arquivos.
• Acessibilidade de baixa tecnologia. Se as coisas ficarem realmente muito ruins, você pode inicializar em um shell de recuperação ou montar o disco em um sistema diferente e ainda ter as ferramentas adequadas disponíveis para inspecionar os arquivos de log. Se é um banco de dados, você não está em nenhum lugar sem um servidor de banco de dados em execução.

Primeiramente fora.

And those might even fail in particular circumstances if great care was not paid.

As transações do banco de dados não podem falhar quando você não é cuidadoso?

Escrever em um arquivo de texto tem vários benefícios, sendo o mais importante

• O texto é legível por humanos. Qualquer um pode abrir um arquivo de log com um editor de texto básico e ver quais são as mensagens. Você não precisa entender como o banco de dados é organizado.
• Velocidade. Escrever texto em disco é muito mais rápido do que um serviço de banco de dados descobrir onde o texto está em um banco de dados, gravá-lo lá e garantir que a transação seja concluída.

Você cria o Apache especificamente, então vou discutir isso em detalhes.

O Apache pode ser configurado para se conectar a um banco de dados, embora exija um plugin externo para fazer isso. Usar esse plugin pode facilitar a análise de logs, mas somente se você pretende escrever seu próprio software de análise de logs. Os analisadores de log padronizados assumem que seus logs estão em arquivos, portanto você não poderá usá-los.

Quando estava fazendo isso, também tive problemas de confiabilidade: se o buffer de gravação do servidor de banco de dados estivesse cheio (o que pode acontecer com o mysql se você usar a cota do sistema de arquivos para o usuário sob o qual ele executa), ele iniciará as consultas até eles podem prosseguir, e nesse ponto o Apache começa a esperar que ele seja concluído, resultando em solicitações interrompidas no seu site.

(Esse problema pode agora ser corrigido, é claro - foi há muitos anos que eu fiz isso)

Vamos ver isso em algumas camadas:

1. Camada da máquina
2. Camada do sistema operacional
3. Camada de serviço
4. Camada de aplicativo

Em resumo:

• Na camada da máquina, você realmente não pode fazer o registro além de algum tipo de despejo.
• Na camada do SO, você pode fazer o registro, mas realmente só tem o sistema de arquivos disponível.
• Os serviços podem ser registrados no sistema de arquivos, mas não podem confiar na execução de outros serviços para que não possam ser registrados lá.
• Aplicativos podem se registrar em serviços e no sistema de arquivos.

Em seguida, temos a abordagem baseada em casos de uso:

Você deseja registrar erros específicos do nó em um RDBMS dimensionado horizontalmente, em que é necessário executar o trabalho extra para localizar o erro de um nó específico quando é possível abrir apenas o capô do nó único e vê-lo lá? Por outro lado, seu aplicativo possivelmente deve efetuar login em um RDBMS para reunir erros e avisos em nível de aplicativo.

O que acontece quando o RDBMS precisa fazer logging para si mesmo porque o banco de dados não pode ser gravado em?

Um sistema de arquivos é um banco de dados. Na verdade, é um banco de dados hierárquico mais simples, em vez de um DBMS relacional, mas é um banco de dados mesmo assim.

A razão pela qual o registro em um sistema de arquivos é popular é porque os logs de texto se encaixam bem com a filosofia do Unix: "O texto é a interface universal."

O Unix foi desenvolvido com muitas ferramentas de uso geral que podem funcionar bem com logs de texto. Não importa se os logs de texto são produzidos pelo mysql, apache, seu aplicativo personalizado, software de terceiros que está fora de suporte, o sysadmin pode usar ferramentas padrão do Unix como grep, sed, awk, tipo, uniq, cut, tail , etc, para percorrer os logs todos o mesmo.

Se cada aplicativo registra em seu próprio banco de dados, um para o MySQL, outro para o Postgres, outro para o Elasticsearch, outro deseja se logar ao ELK, outro pode apenas logar no MongoDB, então você teria que aprender vinte ferramentas diferentes para vasculhar o registros de cada aplicativo. O texto é um meio universal que todos podem logar.

Mesmo quando você consegue fazer com que todos os logs cheguem a um único banco de dados, digamos MySQL, você pode achar que cada aplicativo desejaria logar com diferentes esquemas de tabela, então você ainda teria que escrever uma ferramenta customizada para consultar o registros para cada aplicativo. E se você de alguma forma enfiou todas as aplicações para logar em um único esquema, você provavelmente descobrirá que aquele esquema genérico não poderia realmente contar a história completa de cada aplicação, então você ainda tem que analisar os textos de log de qualquer maneira.

O registro em um banco de dados geralmente não facilita muito as coisas na prática.

O registro em um banco de dados pode ser útil quando você tem uma análise específica em mente ou para um requisito de retificação de auditoria específico, para o qual é possível criar um esquema de banco de dados específico para coletar apenas os dados para essas finalidades específicas. Mas para análise forense e depuração e quando você coleta o log sem objetivo específico em mente, os logs de texto geralmente são bons o suficiente para que o custo de aprender ou criar as ferramentas especializadas não valha a pena.

Complexidade. Adicionar RDBMS aumentará a complexidade de todo o sistema astronomicamente. E a capacidade de gerenciar a complexidade é a principal coisa que distingue os programadores dos produtores de código-fonte.

Is it speed or maintainability or something else?

Velocidade.