9
votes

Utilisation d'une base de données pour la journalisation

Y a-t-il une raison pour laquelle la plupart des journaux semblent être en texte brut, contrairement à être mis dans un type de base de données MySQL / autre?

Il me semble que les mettre dans une base de données rendrait une analyse beaucoup, beaucoup plus facile ... mais cela viendrait-il au sacrifice de la vitesse ou autre chose?

(Je ne suis pas cela préoccupé par la portabilité, et évidemment, vous auriez des journaux de texte pour votre connexion de base de données.)


0 commentaires

6 Réponses :


15
votes

Je peux penser à deux grandes raisons:

Premièrement, les bases de données sont plus lentes que les fichiers texte lorsqu'il s'agit de simplement ajouter des informations sur un fichier. Avec une base de données, vous devez établir une connexion, transmettre des données sur le réseau, stockez-la dans une structure indexée, et cetera. Avec un fichier, vous n'avez besoin que d'écrire l'erreur sur le disque local.

Deuxièmement, parfois, les choses que vous souhaitez enregistrer concernent la base de données étant cassée. Si le disque local est cassé, vous avez de plus gros problèmes que d'essayer de générer des fichiers journaux. Mais vous pouvez enregistrer des pannes de base de données même lorsque tout le reste fonctionne.

Cela dit, il existe de nombreuses situations dans lesquelles les informations que je veux connecter ne sont pertinentes que lorsque l'application fonctionne correctement et lorsque j'ai déjà une connexion de base de données. Dans ces cas, je me connecte directement à MySQL.


0 commentaires

4
votes

Bien que vous n'ayez pas préoccupé par la portabilité, je crois que c'est une grande partie de la raison. Le fichier E / S est presque universel et avec une API extrêmement cohérente. Les autres avantages incluent:

  • Moins de pièces mobiles
  • rien à installer
  • Barrière de compétences basse
  • vitesse
  • Ensemble mature d'outils pour la journalisation, l'analyse, la gestion
  • ne dépend pas du réseau (en supposant que le disque local et non NFS ou autre stockage à distance)
  • Fiabilité
  • peut toujours les mettre dans une DB pour la déclaration / analyse
  • grep est votre ami
  • aucun fichier équivalent d'injection SQL à vous inquiéter (eh bien pour stocker les données, pas nécessairement pour le signaler ou le téléchargement de DB ultérieur).

    Cela dit, il n'y a rien de mal à se connecter à une DB si la nature de l'application se prête à cela et j'ai vu de nombreuses applications qui le font.


0 commentaires

1
votes

Les bases de données contiennent une surcharge importante en termes de mémoire, d'espace de stockage et d'efficacité. L'ajout de nouveaux enregistrements à une base de données ou à modifier les enregistrements existants est beaucoup plus lent. (En outre, beaucoup sont inconnus avec SQL et / ou les spécificités de la configuration d'une base de données.)

Si, toutefois, vous avez besoin d'une analyse ou d'une mesure d'évaluation métrique difficile à obtenir via un fichier texte simple, il n'y a certainement rien de mal à cela. C'est une situation de cas par cas.


0 commentaires

1
votes

(D'autres ont déjà signalé un certain nombre d'avantages concernant la journalisation basée sur des fichiers.)

Je pense que la journalisation DB devient plus utile lorsque les journaux sont collectés sur une machine distante (par exemple, via Syslog / RSYSLOG sous Linux), pour la sauvegarde: Ceci peut être utile si la machine d'origine est compromise et ses journaux altérés. Collecte des journaux dans une base de données (peut-être particulièrement sur la machine distante) est utile dans ce cas, car cela peut aider à régler ces journaux. Vous pouvez également parcourir les journaux plus facilement via des outils tels que phplogcon ou les parcourir à l'aide de web- Pages (il est souvent plus facile que de vous connecter à la machine si vous faites simplement une surveillance occasionnelle).

Ceci étant dit, la journalisation à distance, la journalisation à une base de données et la saisie d'un bel outil pour parcourir les journaux sont plutôt indépendantes (je pense que phplogcon peut également fonctionner avec des journaux de fichiers). Si je stocke des journaux dans une base de données, je stocke également les journaux dans un fichier en même temps, si seulement pour pouvoir lire lorsque la connexion à la DB est en panne.


0 commentaires

1
votes

Il est important de noter qu'il n'y a aucune raison pour ne pas écrire des journaux dans un fichier (ce que d'autres l'ont souligné, est très rapide, efficace et robuste), puis déchargez les données dans une base de données (probablement sur certains autre machine) afin d'effectuer une analyse qui sera accélérée en ayant des fonctionnalités de base de données typiques. Ceci est possible, bien sûr, car les données du journal n'ont généralement pas besoin d'être crunchées immédiatement - il est donc logique de différer toute la surcharge et de la fragilité d'une base de données jusqu'à ce qu'elle soit nécessaire.


0 commentaires

4
votes

Historiquement, des bases de données étaient chères et vous ne voudrez certainement pas perdre de vos précieuses licences de base de données sur les journaux. Toutefois, les bases de données aujourd'hui sont relativement peu coûteuses et le traitement de la sorte. L'utilisation d'une base de données pour les journaux ne vous tuerait probablement pas financièrement.

L'avantage d'un fichier journal est que vous continuez à écrire à la fin de celui-ci. C'est une opération relativement efficace par rapport à l'utilisation d'un serveur de base de données.

L'avantage d'une base de données est que vous pouvez structurer vos données de journal dans les relations de données, qui peuvent ensuite être analysées à l'aide de SQL. Cela peut vous fournir un excellent aperçu du fonctionnement de votre logiciel.

Vous pouvez avoir le meilleur des deux mondes en utilisant SQLite comme base de données de journaux. SQLite est une bibliothèque avec un moteur SQL que vous associez dans votre programme. Au lieu de fopen / fwrite / F Close, vous utilisez l'API SQLite pour ouvrir la base de données, exécuter SQL et fermer la base de données. Il n'y a pas de serveur de base de données car les opérations de moteur SQLite sont exécutées dans le processus de votre application ... Tout comme Fopen / fwrite / FLOSE. Une fois que vous avez capturé vos données dans une base de données SQLite (toutes stockées dans un fichier simple), vous pouvez utiliser SQL pour analyser vos données de journal. Découvrez http://www.squidoo.com/sqlitehammer#module5800826 pour un exemple.

-------- Modifier août 2010 --------------

Les développeurs de SQLite ont mis en œuvre une journalisation Writeahead à partir de SQLite version 3.7.0 . Cela permet de nombreuses écrivies plus rapides. Découvrez Cette vidéo pour plus de détails. Avec une écriture plus rapide, SQLite est encore plus utile en tant que base de données de journalisation.


2 commentaires

Il existe un "petit" problème avec cette suggestion: SQLite ne prend pas en charge l'accès simultané de lecture / écriture, ce qui signifie que vous ne pourrez pas afficher le fichier journal en temps réel. C'est un énorme inconvénient. Liron


@Liron Levi - avec la version 3.7.0 et Writeahead Logging activé, vous pourrez afficher le fichier journal en temps réel, car un écrivain ne bloque pas les lecteurs.