Connectez-vous à la base de données à la place des fichiers journaux

Question

Je souhaite envoyer la journalisation de l'application Rails à une base de données (MySQL ou MongoDB) en plus ou à la place d'un fichier journal. Il y a quelques raisons, dont la plupart sont préoccupées par l'analyse des fichiers journaux. Nous utilisons déjà Google Analytics, mais il y a une variété de choses que nous voulons faire qui ne sont pas aussi pratiques dans Google Analytics.

En outre, je voudrais faire "en temps réel" enquête sur les problèmes en regardant les journaux. Passer au crible un fichier journal est une manière fastidieuse de le faire, et j'aimerais faire une meilleure recherche et un meilleur filtrage qu'un fichier journal (facilement). Finalement, je veux souvent examiner quelque chose de plus proche du comportement des visiteurs du site: traçage du chemin à travers le site par exemple, afin que je puisse voir quelle était la dernière page qu'un utilisateur regardait avant qu'une erreur se produise. Étant donné que nous avons plusieurs serveurs d'applications, les fichiers journaux distincts en font vraiment souffrir. Si toutes les données étaient dans une base de données, je pourrais alors facilement voir la bonne séquence de pages pour un visiteur donné. Je sais que Syslog serait un moyen de résoudre ce problème particulier (fichier journal/référentiel unique), mais je veux combiner cela avec de meilleures capacités de recherche que j'associe aux recherches dans les bases de données.

Je me demande ce que les gens recommandent pour résoudre ce problème. Est-ce que vous vous connectez directement à une base de données, ou est-ce que vous sauvegardez des fichiers journaux dans une base de données (mais quelle est votre approche pour que ce soit essentiellement en temps réel/aussi à jour que le fichier journal lui-même)?

Je suis actuellement en train de déterminer à quel niveau j'aimerais cette journalisation, car une autre chose que j'ai regardée est l'écriture d'un petit filtre Rack qui consignerait toutes les requêtes. Cela manquerait toute la sortie supplémentaire que la journalisation normale de Rails vide (tout le SQL et la sortie sur le cache frappe et manque, etc.), mais cela permettrait d'atteindre une grande partie de mon objectif, et semble avoir l'avantage de ne pas déranger autre chose dans le système.

De toute façon, je ne cherche pas une bonne réponse, plus d'une discussion et d'informations sur ce que quelqu'un d'autre pourrait faire dans cette même lumière.

Answer 1

Si vous voulez modifier le comportement de journalisation par défaut, créez simplement un objet enregistreur personnalisé qui répond à tous la méthode enregistreur Rails:

• ajouter
• debug, warn, error, info, fatale, inconnu

http://github.com/rails/rails/blob/9d7aae710384fb5f04129c35b86c5ea5fb9d83a9/activesupport/lib/active_support/buffered_logger.rb

Parce qu'il est votre enregistreur, vous pouvez décider de implémentez votre logique personnelle. Vous pouvez écrire dans la base de données, à la sortie standard de quand vous le souhaitez.

Ensuite, remplacez le consignateur par défaut pour chaque classe de base que vous souhaitez personnaliser.

ActiveRecord::Base.logger = YouLogger.new 

Vous pouvez facilement créer un fichier d'initialisation appelé logger.rb et y écrire toutes vos configurations personnalisées. De cette façon, l'enregistreur sera immédiatement remplacé au démarrage de Rails.

Answer 2

J'utilise les rails "exception logger", pour enregistrer tous les problèmes dans ma base de données lorsque mon site est en mode production. Il vous donnera une belle interface où vous pouvez vérifier les problèmes.Si vous voulez voir ce que vos visiteurs font en temps réel alors jetez un oeil à

Answer 3

Chris,

Je pense que le commentaire de Dima est important. Êtes-vous satisfait de (1) avoir un journal d'accès dans une base de données (en temps réel), ou (2) êtes-vous plus intéressé par la journalisation spécifique à Rails/application?

Pour (1), avec Apache (au moins), vous pouvez vous connecter à une base de données en utilisant la journalisation canalisée.

http://httpd.apache.org/docs/1.3/logs.html#piped

j'ai écrit un programme qui fonctionne en arrière-plan d'attente pour l'entrée, qu'il analyse et les journaux à une base de données Postgres. Mon fichier httpd.conf redirige vers ce programme avec une directive CustomLog.

Ceci est relativement simple à configurer et vous offre tous les avantages évidents de pouvoir analyser vos journaux dans une base de données. Cela fonctionne très bien pour moi, surtout pour retracer ce qu'un utilisateur faisait juste avant une erreur. Cependant, vous devez vous protéger contre l'injection SQL, les débordements de mémoire tampon et d'autres problèmes de sécurité dans le programme de journalisation. Pour (2), je ne suis pas un développeur Rails, donc je ne peux parler que d'approches générales. Si vous souhaitez enregistrer des variables d'environnement, des données d'application ou des informations très sélectives, vous pouvez envisager d'écrire un module de serveur Web. En fonction de vos besoins exacts, vous pouvez également vous débrouiller avec une combinaison de directives de journalisation conditionnelle et de filtrage dans le programme de journalisation.

Il s'agit vraiment de savoir si vous avez besoin d'une solution spécifique à Rails ou d'une solution plus générale à l'échelle du serveur Web.

Answer 4

Mon entreprise enregistre des informations de trafic structurées directement dans une base de données de journaux MySQL. Cette base de données est répliquée en aval vers une autre base de données. Toutes les analyses s'exécutent sur la réplication de base de données finale. Notre site supporte un peu de trafic. Jusqu'à présent, cela ne semble pas avoir de problèmes majeurs. Cependant, notre service informatique a des préoccupations croissantes concernant l'évolutivité de la configuration actuelle et suggère que nous déchargions les informations du journal sur des fichiers journaux "corrects". Les fichiers journaux seront ensuite réinsérés dans les mêmes tables de base de données en aval. Ce qui m'amène à cette question. :)

Voici quelques-uns des avantages et des inconvénients que je vois en ce qui concerne le sujet des fichiers log vs log-db (relationnelle):

• fichiers journaux sont rapides, fiables et évolutives (à J'ai entendu dire que Yahoo utilise beaucoup les fichiers journaux pour ses analyses de suivi des clics).
• Les fichiers journaux sont faciles à gérer pour l'administrateur système. Les fichiers journaux peuvent être très flexibles car vous pouvez y écrire presque n'importe quoi.
• Les fichiers journaux nécessitent une analyse intensive et, potentiellement, un type de configuration réduit en carte pour l'extraction de données. Les structures log-db sont beaucoup plus proches de votre application, ce qui raccourcit considérablement le temps d'exécution de certaines fonctions. Cela peut être une bénédiction ou une malédiction. Probablement une malédiction à long terme puisque vous finirez très probablement avec une application hautement couplée et une base de code analytique. Log-db peut réduire les bruits de journalisation et les redondances puisque les fichiers journaux ne sont insérés que lorsque log-db vous donne la possibilité de faire update et insert-insert (normalisation si vous osez).
• log-db peut être rapide et évolutive trop si vous allez avec le partitionnement de base de données et/ou des bases de données multi-log (rejoigne données via réplications en aval)

Je pense que certains tests de stress sur la base de données de journal sont nécessaires ma situation. De cette façon, au moins, je sais combien de marge je possède.

Récemment, je cherchais dans certains clé-valeur/bases de données basées sur des documents comme Redis, Tokyo Cabinet et MongoDB. Ces bases de données à insertion rapide peuvent potentiellement être le point de convergence, car elles fournissent de la persistance, des débits (d'écriture) élevés et des capacités d'interrogation à des degrés variables. Ils peuvent rendre le processus d'extraction de données beaucoup plus simple que l'analyse et la réduction de la carte grâce à des concerts de fichiers journaux.

À long terme, je crois qu'il est crucial d'avoir un entrepôt de données d'analyse robuste. Libérer des données d'application à partir de données analytiques et vice versa peut être un gros gain.

---

Enfin, je voudrais souligner qu'il ya beaucoup semblables/de près les questions liées ici sur StackOverflow au cas où vous voulez élargir votre discussion.

• Storage of many log files
• Is writing server log files to a database a good idea?
• Using a SQL Server for application logging. Pros/Cons?
• Fast Search in Logs
• Separate production database for logging
• You Log to Your DB, Where Do You Log When Your DB is Down?

---

Modifier:

rsyslog semble très intéressant. Cela vous donne la possibilité d'écrire directement sur MySQL. Si vous utilisez Ruby, vous devriez jeter un coup d'œil à la gemme de journalisation. Il fournit des capacités de journalisation multi-cibles. C'est vraiment sympa.

Answer 5

comme aucune réponse n'a été acceptée jusqu'à présent, je donnerai ma contribution

je l'ai fait développer un plugin pour rsylog pour enregistrer les journaux pas dans les fichiers mais mongodb

l'ensemble du code source, de rsyslog + plugin est ici https://github.com/vpereira/rsyslogd-mongo

pour le compiler, vous devez simplement exécuter ./configure --help et voir les options disponibles.

Answer 6

Après avoir fait l'erreur de se connecter à une base de données moi-même récemment, je sens que je peux offrir une très bonne raison pour laquelle vous ne devriez pas le faire: Transactions. Imaginons que vous commenciez une transaction, que vous enregistriez un tas de choses au cours de la transaction et que vous finissiez par une condition d'erreur. Vous vous connectez la condition d'erreur, et oh hey. ROLLBACK. Soudainement, tout ce que vous avez enregistré est parti et vous n'avez aucune idée de ce qui s'est passé ou pourquoi. Et en particulier dans le contexte de Rails, où des bibliothèques vraiment utiles comme AASM vont emballer tout un tas de choses dans une transaction, vous pouvez vous retrouver avec des transactions dans des endroits où vous ne pensiez pas que vous le feriez, ce qui rend également le problème très difficile à déboguer.Dans mon cas, la raison pour laquelle j'ai enregistré des choses dans la base de données était que j'avais besoin de journaux sensibles au contexte. Essentiellement, je devais être capable de rechercher toutes les entrées de journal liées à un modèle de base de données spécifique. Toutefois, la bonne réponse consiste à placer ces journaux dans un emplacement distinct qui convient mieux aux données de journal (et qui, dans mon cas, peut être interrogé).