Journal de base de données au lieu des fichiers journaux

Question

Je suis intéressé par l'envoi de tous les Rails de journalisation de l'application à une base de données (MySQL ou MongoDB) soit en plus ou au lieu d'un fichier journal. Il ya quelques raisons, dont la plupart sont préoccupés d'analyse de fichier journal. Nous utilisons Google Analytics, mais il existe une variété de choses que nous voulons faire qui ne sont pas réalisables dans google Analytics.

En outre, j'aimerais le faire en "temps réel" l'examen de questions en regardant les journaux. Le tamisage à travers un fichier journal est une tâche fastidieuse façon de le faire, et j'aimerais mieux faire de la recherche et de filtrage qu'un fichier journal (facilement) permet de.

Enfin, j'ai souvent envie d'examiner la chose de plus près le comportement des visiteurs du site: tracer le chemin à travers le site pour l'exemple, afin que je puisse voir ce que la dernière page a été qu'un utilisateur a été à la recherche à avant de une erreur s'est produite. Sachant que nous avons plusieurs serveurs d'application, les différents fichiers journaux en font une vraie douleur. Si toutes les données sont dans une base de données, j'ai pu alors voir facilement la bonne séquence de pages pour un visiteur. Je sais que Syslog serait un moyen de résoudre cette chose en particulier (un seul fichier de log/référentiel), mais je tiens à les combiner avec de meilleures capacités de recherche que j'associe avec des recherches de base de données.

Je me demandais ce que les gens vous recommandons de résoudre ce problème. Avez-vous vous connecter directement à une base de données, ou avez-vous dump des fichiers journaux dans une DB (mais quelle est votre approche pour que, de sorte que c'est essentiellement en temps réel/à jour le fichier lui-même)?

Je suis actuellement en train de déterminer à quel niveau j'aimerais que ce journalisation, car une autre chose que j'ai regardé est écrit un petit Rack filtre qui se connectent à toutes les demandes. Ce serait manquer toute la puissance supplémentaire que la normale Rails de journalisation vide (le SQL et de sortie sur les réussites et les échecs, etc.), mais elle permettrait d'atteindre une grande partie de mon objectif, et semble avoir l'avantage de ne pas déranger tout le reste du système.

De toute façon, je ne suis pas à la recherche d'un droit de réponse, plus d'une discussion et d'information sur ce que quelqu'un d'autre pourrait être en train de faire dans cette même lumière.

Answer 1

Mon entreprise ont été la journalisation de certains structuré info trafic directement dans une base de données MySQL base de données du journal. Cette base de données est répliquée en aval à une autre base de données. Toutes les analyses de run-off de la finale de la réplication de base de données. Notre site de soutenir tout à fait un peu de trafic. Jusqu'à présent, il ne semble pas avoir de problèmes majeurs. Cependant, notre département ont certaines préoccupations croissantes quant à l'évolutivité de la configuration actuelle et suggère que nous nous remettons le journal d'info sur le "bon" fichiers log. Le journal-les fichiers seront ensuite réinséré dans le même en aval tables de base de données. Ce qui m'amène à cette question. :)

Voici quelques-uns des avantages et des inconvénients que je vois concernant le sujet de la log-files vs log-db (relationnel):

• des fichiers log sont rapides, fiables et évolutifs (Au moins, j'ai entendu Yahoo! fait beaucoup usage de fichiers de log pour leur click tracking analytics).
• des fichiers log sont faciles pour les sys-admin à maintenir.
• des fichiers log peut être très flexible car vous pouvez écrire presque n'importe quoi pour elle.
• des fichiers log nécessite de lourds d'analyse et potentiellement une carte-type de réduction de l'installation pour l'extraction des données.
• journal-db structures sont beaucoup plus proches de votre demande, ce qui rend la fonction de temps beaucoup plus courte. Cela peut être une bénédiction ou une malédiction. Probablement une malédiction dans le long terme, puisque vous aurez plus de chances de finir avec un très couplé d'application et d'analyse de la base de code.
• journal-db peut réduire la journalisation des bruits et des licenciements depuis des fichiers log sont insérez seulement où que journal db vous donne la possibilité de faire la mise à jour et associés-insert (normalisation, si vous l'osez).
• journal-db peut être rapide et évolutive trop si vous allez avec la base de données de partitionnement et/ou multi-journal des bases de données (rejoindre données via l'aval des réplications)

Je pense que certains des tests de stress sur la base de données du journal sont nécessaires dans ma situation. De cette façon, au moins je sais à quel point la marge que j'ai.

Récemment, j'ai été regarder dans certaines clé-valeur / document de bases de données comme le Redis, Tokyo Cabinet, et MongoDB. Ces rapide insertion de bases de données peuvent potentiellement être le sweet spot, car ils fournissent la persistance, de la haute (écrire) des débits et des capacités d'interrogation, à des degrés divers. Ils peuvent rendre le processus d'extraction des données beaucoup plus simple que l'analyse et la carte de réduction par le biais de concerts de fichiers de log.

Dans le long terme, je crois qu'il est crucial de disposer d'un solide analytics, entrepôt de données. Libérer les données de l'application à partir des données analytiques et vice versa peut être une grande VICTOIRE.

---

Enfin, je voudrais juste préciser qu'il y a beaucoup de semblables / questions étroitement liées ici sur StackOverflow dans le cas où vous souhaitez élargir votre discussion.

• http://stackoverflow.com/questions/1037024/storage-of-many-log-files
• http://stackoverflow.com/questions/290304/is-writing-server-log-files-to-a-database-a-good-idea
• http://stackoverflow.com/questions/209497/using-a-sql-server-for-application-logging-proscons
• http://stackoverflow.com/questions/755063/fast-search-in-logs
• http://stackoverflow.com/questions/922999/separate-production-database-for-logging
• http://stackoverflow.com/questions/206112/you-log-to-your-db-where-do-you-log-when-your-db-is-down

---

Edit:

rsyslog a l'air très intéressant. Il vous donne la possibilité d'écrire directement sur MySQL. Si vous êtes à l'aide de Ruby, vous devriez jeter un oeil à la journalisation des gem. Il offre multi-cibles des fonctions de journalisation. C'est vraiment agréable.

Answer 2

Si vous souhaitez modifier le comportement d'enregistrement par défaut, il suffit de créer un objet logger qui répondent à tous les Rails de l'enregistreur de méthode:

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

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

Parce que c'est votre enregistreur, vous pouvez décider de mettre en œuvre les personnels de votre logique. Vous pouvez écrire à la base de données, la sortie standard de chaque fois que vous le souhaitez.

Ensuite, remplacez la valeur par défaut de l'enregistreur de pour chaque classe de base que vous souhaitez personnaliser.

ActiveRecord::Base.logger = YouLogger.new

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

Answer 3

J'utilise les rails "logger", journal de tous les problèmes de ma base de données alors que 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 puis prendre un coup d'oeil à woopra

Answer 4

Chris,

Je pense que le Dima commentaire est important ici. Êtes-vous satisfait (1) ayant un journal d'accès à une base de données (en temps réel), ou (2) êtes-vous plus intéressé dans les Rails/app spécifiques à l'exploitation forestière?

Pour (1), avec Apache (au moins), vous pouvez vous connecter à une base de données à l'aide de canalisations d'enregistrement.

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

J'ai écrit un programme qui s'exécute dans le contexte d'attente pour l'entrée, il l'analyse et les journaux à une Postgres DB. Mon httpd.fichier conf de tuyaux à ce programme avec une directive CustomLog.

C'est relativement simple à mettre en place, et vous donne tous les avantages évidents d'être en mesure d'analyser vos logs dans une base de données. Il fonctionne très bien pour moi, surtout pour le traçage de ce que l'utilisateur était en train de faire juste avant une erreur. Cependant, vous devez vous protéger contre les injections sql, les dépassements de mémoire tampon et d'autres problèmes de sécurité dans le programme d'enregistrement.

Pour (2), je ne suis pas un développeur Rails et je ne peux donc parler d'approches générales. Si vous voulez enregistrer les variables d'environnement, ou les données d'application, ou très sélective de bits d'information, vous pourriez envisager la rédaction d'un serveur web module. En fonction de vos besoins personnels, vous pouvez également les obtenir par une combinaison de la journalisation conditionnelle directives et de filtrage dans le programme d'enregistrement.

Il s'agit vraiment de savoir si vous avez besoin d'un Rails de solution spécifique ou d'une manière plus générale de serveur web à l'échelle de la solution.

Answer 5

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

j'ai fait développer un plugin pour rsylog pour enregistrer les journaux pas dans les fichiers, mais à mongodb

le code source en entier, à partir de rsyslog + plugin est ici https://github.com/vpereira/rsyslogd-mongo

pour compiler, il suffit de l'exécuter ./configure --help et voir les options disponibles.