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

A pergunta deve ficar clara em seu título. Por exemplo, o Apache salva seus logs de acesso e de erro nos arquivos, em vez do RDBMS, independentemente de quão grande ou pequena escala está sendo utilizada.

Para o RDMS, apenas precisamos escrever consultas SQL e ele fará o trabalho, enquanto que para os arquivos, devemos decidir um formato específico e, em seguida, escrever regex ou podem ser analisadores para manipulá-las. E esses podem até falhar em circunstâncias particulares, se um grande cuidado não for pago.

No entanto, todo mundo parece preferir o sistema de arquivos para manter os logs. Não sou tendencioso contra nenhum desses métodos, mas gostaria de saber por que é praticado dessa maneira. É velocidade ou manutenção ou algo mais?

1. Muitas coisas podem falhar com o banco de dados e o registro dessas 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 pena registrar acontecem durante a inicialização, ou seja, possivelmente antes que a conexão com o banco de dados seja estabelecida.

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

Eu já vi logs gravados no banco de dados antes (e às vezes você obtém opções configuráveis ​​para o log, onde o rastreamento vai para o arquivo, erros no banco de dados, fatais no log de eventos do Windows).

As principais razões são velocidade e tamanho, permitindo que alguns rastreamentos possam produzir vastas e vastas qualidades de registro - eu vasculhei arquivos de log em gigabytes de tamanho. A outra razão principal é que a leitura dos logs precisa ser seqüencial, não há necessidade real de consultar o log, exceto para encontrar um determinado erro ou entrada - e o find-in-file funciona perfeitamente bem para isso.

A velocidade é uma razão; outros são:

• Eliminando pontos de falha. Um sistema de arquivos raramente falha sob condições onde um DBMS não falharia, mas existem muitas e muitas condições de erro nos bancos de dados que simplesmente não existem nos sistemas de arquivos.
• Acessibilidade de baixa tecnologia. Se tudo der errado, você poderá inicializar em um shell de resgate ou montar o disco em um sistema diferente e ainda ter as ferramentas adequadas disponíveis para inspecionar os arquivos de log. Se for um banco de dados, você não estará em nenhum lugar sem um servidor de banco de dados em execução.

Primeiramente.

E esses podem até falhar em circunstâncias particulares, se um grande cuidado não for pago.

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

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

• O texto é legível por humanos. Qualquer pessoa 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 está organizado.
• Rapidez. Gravar texto em disco é muito mais rápido que um serviço de banco de dados descobrindo para onde o texto vai em um banco de dados, gravando-o e garantindo a conclusão da transação.

Você criou o Apache especificamente, então discutirei isso em detalhes.

O Apache pode ser configurado para efetuar logon em um banco de dados, embora exija um plug - in externo para fazer isso. O uso desse plug-in pode facilitar a análise de logs, mas apenas se você deseja escrever seu próprio software de análise de logs. Os analisadores de log padrão prontos para uso 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 estiver 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 é executado), ele começará a enfileirar as consultas até conseguir para prosseguir, quando o Apache começa a aguardar a conclusão, resultando em solicitações interrompidas para o seu site.

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

Um sistema de arquivos é um banco de dados. É realmente um banco de dados hierárquico mais simples, em vez de um DBMS relacional, mas é um banco de dados.

A razão pela qual o logon 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 se desenvolveu 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 com muito tempo sem suporte, o sysadmin pode usar ferramentas padrão do Unix, como grep, sed, awk, sort, uniq, cut, tail , etc, para percorrer os logs da mesma forma.

Se cada aplicativo fizer logon em seu próprio banco de dados, um no MySQL, outro no Postgres, outro no Elasticsearch, outro quiser efetuar logon no ELK, outro só puder efetuar logon no MongoDB, você precisará aprender vinte ferramentas diferentes para rastrear os logs de cada inscrição. O texto é um meio universal no qual todos podem fazer logon.

Mesmo quando você consegue fazer com que todos os logs cheguem a um único banco de dados, por exemplo, MySQL, você pode achar que cada aplicativo deseja registrar com esquemas de tabela diferentes, portanto, você ainda precisará escrever uma ferramenta personalizada para consultar os logs para cada inscrição. E se você de alguma forma amontoou todos os aplicativos para efetuar logon em um único esquema, provavelmente descobrirá que esse esquema genérico não pode realmente contar a história completa de cada aplicativo, portanto, você ainda precisará 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ê tiver uma análise específica em mente ou para um requisito específico de retenção de auditoria, para o qual é possível projetar um esquema de banco de dados específico para coletar apenas os dados para esses fins específicos. Mas para análise forense e depuração e quando você coleta logs sem objetivo específico em mente, os logs de texto geralmente são bons o suficiente para que o custo de aprender ou criar ferramentas especializadas não valha a pena.

Vejamos isso em algumas camadas:

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

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 sistema operacional, você pode fazer o registro, mas realmente só tem o sistema de arquivos disponível.
• Os serviços podem efetuar logon no sistema de arquivos, mas não podem confiar na execução de outros serviços, portanto, não podem fazer logon nesse local.
• Os aplicativos podem efetuar logon nos serviços e no sistema de arquivos.

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

Deseja registrar erros específicos do nó em um RDBMS dimensionado horizontalmente, onde você precisa realizar um trabalho extra para encontrar o erro de um nó específico, quando você pode simplesmente abrir o capô do nó e vê-lo lá? Por outro lado, é possível que seu aplicativo faça logon em um RDBMS para coletar avisos e erros no nível do aplicativo.

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

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

É velocidade ou manutenção ou algo mais?

Rapidez.