Por que existem tantos arquivos de log em um sistema Linux típico? Por que eles não usam um log consolidado db / arquivo e uma API?

Eu só me pergunto por que existem tantos arquivos de log em um sistema Linux típico? Não seria uma idéia melhor ter uma função de API do sistema para log e uma tabela consolidada para salvar todas as entradas de log de todos os aplicativos?

Faz parte da filosofia Unix . A idéia é que os arquivos de texto estejam livres do aprisionamento do programa e todos possam usar a técnica que preferirem. Para levar isso adiante, os arquivos simples são frequentemente usados, em vez de linguagens de marcação como XML (embora eu tenha visto programas armazenando coisas no formato XML também).

Ao pesquisar no Google, encontrei essa boa redação sobre texto simples, com comentários sobre a filosofia do Unix.

O uso de arquivos de texto simples tem a vantagem de que você não precisa de nenhuma ferramenta específica do banco de dados para obter suas entradas de log.

Você pode analisá-los com grep, se quiser, pode abri-los com seu pager favorito e processá-los em sua linguagem de script favorita, como Perl, Python, etc., sem a necessidade de bibliotecas adicionais.

Em um sistema Unix, você já possui algum tipo de "API de log do sistema". É chamado syslog. O Syslog não é realmente uma API, mas é um padrão para registrar mensagens. O nome representa o protocolo de rede e a biblioteca e daemon por trás dele.

A configuração padrão da maioria dos sistemas é um daemon syslog que escuta mensagens locais.

O daemon aceita as mensagens e faz o log. Existem várias implementações diferentes de daemons syslog para todos os tipos de plataformas e também é possível registrar suas mensagens em um banco de dados.

É com você.

Eu só me pergunto por que existem tantos arquivos de log em um sistema Linux típico?

Os diferentes arquivos de log contêm informações diferentes (embora normalmente exista alguma duplicação). Eles geralmente têm características diferentes: políticas diferentes de rotação e retenção, permissões diferentes etc. O daemon syslog se encarrega de escrevê-las; você pode ver suas configurações em /etc/syslog.confou /etc/syslog-ng.conf.

Não seria uma idéia melhor ter uma função de API do sistema para log

Essa é uma boa ideia. Vamos chamá-lo de syslog . Seu trabalho é enviar as entradas de log para o daemon syslog.

e uma tabela consolidada para salvar todas as entradas de log de todos os aplicativos?

Agora isso é uma lata inteira de vermes. Você parece estar assumindo a presença de um mecanismo de banco de dados, provavelmente um banco de dados relacional, provavelmente um que você pode consultar no SQL. Mas o Unix é mais antigo que o SQL, e há boas razões para não ter adotado o SQL como um componente padrão. No Unix, o banco de dados é o sistema de arquivos. Não é um banco de dados relacional, é simples . Suas entradas não são linhas, mas arquivos simples , de preferência texto, de preferência com um formato simples. Por exemplo, arquivos de log são arquivos de texto, com uma entrada por linha, contendo a data, o nome da máquina, o programa de origem e o texto da entrada. O uso de um banco de dados relacional teria várias desvantagens:

• O que você faz se o banco de dados não estiver funcionando? (O sistema de arquivos é um componente fundamental (e eu mencionei que é muito mais simples que um banco de dados relacional?); O daemon syslog é um componente simples que executa um trabalho (um recurso comum no design do Unix) e, portanto, espera-se que o faça bem e de forma confiável.)
• Como você registra operações de banco de dados? (Ok, através do próprio banco de dados - afinal todos os logs contêm entradas do kernel e do daemon syslog - mas, novamente, um banco de dados muito mais complexo torna isso mais difícil e menos confiável).
• Como você acessa as entradas do log? Compare a simplicidade cat, grep, lesscontra consultas SQL. E permissões de arquivo contra, bem, não sei como você lidaria com isso em um banco de dados relacional típico.
• Instalações multi-servidor não armazenam seus logs localmente, eles usam o recurso de log remoto que foi incorporado ao daemon syslog desde praticamente o início do Unix. Isso é fácil de implementar com a arquitetura de registro unix; você não pode executar um banco de dados replicado nesse orçamento de complexidade.

Se você realmente deseja armazenar os logs do sistema em um banco de dados relacional (que pode ter muitas vantagens), consulte o rsyslog ( o substituto para o syslog ), que pode gravar os logs do sistema em um banco de dados MySQL , Postgres ou Oracle .

Isso tornaria coisas como 'tail -f /var/log/apache/access.log' impossíveis.

Por que você acha que seria melhor colocar tudo em um arquivo?