Pourquoi y a-t-il autant de fichiers journaux dans un système Linux typique? Pourquoi n'utilisent-ils pas un seul fichier journal / fichier consolidé et une API?

Je me demande simplement pourquoi y a-t-il autant de fichiers journaux dans un système Linux typique? Ne serait-il pas préférable d'avoir une fonction API système pour la journalisation et une table consolidée pour enregistrer toutes les entrées de journal de toutes les applications?

Cela fait partie de la philosophie Unix . L'idée est que les fichiers texte sont libres de verrouillage du programme et que chacun peut utiliser la technique qu'il préfère. Pour aller plus loin, les fichiers plats sont souvent utilisés, contrairement aux langages de balisage comme XML (bien que j'ai vu des programmes stocker des choses au format XML également).

Dans googler, j'ai trouvé cette belle écriture sur le texte brut, avec des commentaires sur la philosophie Unix.

L'utilisation de fichiers texte simples présente l'avantage de ne nécessiter aucun outil spécifique à la base de données pour obtenir vos entrées de journal.

Vous pouvez les analyser avec grep si vous le souhaitez, vous pouvez les ouvrir avec votre pager préféré et vous pouvez les traiter dans votre langage de script préféré comme Perl, Python, etc. sans avoir besoin de bibliothèques supplémentaires.

Sur un système Unix, vous avez déjà une sorte d '"API de journal système". Il s'appelle syslog. Syslog n'est pas vraiment une API mais c'est un standard pour la journalisation des messages. Le nom représente le protocole de mise en réseau et la bibliothèque et le démon derrière lui.

La configuration par défaut de la plupart des systèmes est un démon syslog écoutant les messages locaux.

Le démon accepte les messages et effectue la journalisation. Il existe plusieurs implémentations différentes des démons syslog pour tous les types de plates-formes et il est également possible de consigner vos messages dans une base de données.

C'est comme tu veux.

Je me demande simplement pourquoi y a-t-il autant de fichiers journaux dans un système Linux typique?

Les différents fichiers journaux contiennent des informations différentes (bien qu'il y ait généralement une certaine duplication). Ils ont souvent des caractéristiques différentes: différentes politiques de rotation et de rétention, différentes autorisations, etc. Le démon syslog se charge de les écrire; vous pouvez voir ses paramètres dans /etc/syslog.confou /etc/syslog-ng.conf.

Ne serait-il pas préférable d'avoir une fonction API système pour la journalisation

Celui-ci est une bonne idée. Appelons-le syslog . Son travail consiste à envoyer les entrées de journal au démon syslog.

et un tableau consolidé pour enregistrer toutes les entrées de journal de toutes les applications?

Maintenant, c'est toute une boîte de vers. Vous semblez supposer la présence d'un moteur de base de données, probablement une base de données relationnelle, probablement celle que vous pouvez interroger en SQL. Mais Unix est plus ancien que SQL, et il y a de très bonnes raisons pour lesquelles il n'a pas adopté SQL comme composant standard. Sous Unix, la base de données est le système de fichiers. Ce n'est pas une base de données relationnelle, c'est simple . Ses entrées ne sont pas des lignes, mais de simples fichiers, de préférence du texte, de préférence avec un format simple. Par exemple, les fichiers journaux sont des fichiers texte, avec une entrée par ligne, contenant la date, le nom de la machine, le programme d'origine et le texte d'entrée. L'utilisation d'une base de données relationnelle aurait un certain nombre d'inconvénients:

• Que faites-vous si la base de données ne fonctionne pas? (Le système de fichiers est un composant fondamental (et ai-je mentionné qu'il est beaucoup plus simple qu'une base de données relationnelle?); Le démon syslog est un composant simple qui fait un travail (une caractéristique commune dans la conception Unix) et devrait donc bien le faire et de manière fiable.)
• Comment enregistrez-vous les opérations de base de données? (Ok, à travers la base de données elle-même - après que tous les journaux contiennent des entrées du noyau et du démon syslog - mais encore une base de données beaucoup plus complexe rend cela plus difficile et moins fiable).
• Comment accédez-vous aux entrées du journal? Comparez la simplicité cat, grep, dans lessdes requêtes SQL. Et les autorisations de fichiers contre, eh bien, je ne sais pas comment vous géreriez cela dans une base de données relationnelle typique.
• Les installations multi-serveurs ne stockent pas leurs journaux localement, elles utilisent la fonction de journalisation à distance qui a été intégrée au démon syslog depuis pratiquement l'aube d'Unix. C'est facile à implémenter avec l'architecture de journalisation Unix; vous ne pouvez pas exécuter une base de données répliquée sur ce budget de complexité.

Si vous souhaitez vraiment stocker vos journaux système dans une base de données relationnelle (ce qui peut avoir de nombreux avantages), consultez rsyslog ( le remplacement à venir de syslog ), qui peut écrire des journaux système dans une base de données MySQL , Postgres ou Oracle .

Cela rendrait impossible des choses comme «tail -f /var/log/apache/access.log».

Pourquoi pensez-vous qu'il serait préférable de tout mettre dans un seul fichier?